Ticket Lifecycle

Purpose

Provide a visualclear, simple, and step-by-stepITIL‑aligned lifecycle process for serviceevery support ticket so technicians deliver consistent results, managers can enforce accountability, and reporting stays accurate.

Scope

All client‑facing tickets from triageraised to closure.Computerman’s ThisSupport ensuresDesk: promptIncidents, communication,Service SLARequests, compliance,Access properRequests, documentation,Questions, and technician(when accountability.applicable) tickets related to recurring issues (Problem equivalent) or environment modifications (Change equivalent).

1. Ticket Received, Created & Triggered 

Roles

• Source: Email, Portal, or Phone Call

All tickets are entered into Autotask with a timestamp and source for tracking SLA.

2. Initial Response Email – SLA (within 15 minutes)

• Action:

  • Acknowledge the request

  • Introduce yourself as the technician assigned

  • Provide initial troubleshooting (if possible)

  • Set time expectations

Example Template:

Subject: First Response

Hi [Client Name],

Thanks for reaching out. We've received your request regarding [brief summary].
I’ll be handling this for you and will provide an update by [timeframe].

[Optional: troubleshooting steps if possible]

If urgent, please call our service desk on 1300 530 000.

Kind regards,

3. User Responds (within 2 hours)

• If Yes:

  • Move to resolution or schedule work.

• If No:

  • Call the client within 2 hours of the first response.

  • If still no response, send a 'Call Back notice' (templated in CRM)

Ticket > New Note > [top right-hand corner] 'Enter Speed Code or Choose Template > Select 'CBN - (EX) Call Back Notice' 

• • • After 24 hours, follow up with a 'Follow-Up on your support request' 

Example Template:

• • Subject: Follow-up on your support request

     

    Hi [Client Name],

     

    Just following up on your service request regarding [brief summary of the issue]. We attempted to contact you by phone and are awaiting your response to proceed.

     

    Please let us know how you’d like to move forward, or if the issue has been resolved on your end.

     

    If we don’t hear back, the ticket will be closed after 48 hours from our last contact.

     

    Kind regards,

  • If still no response within 48 hours of the ticket being raised, email to advise closure.

Example Template:

• • Subject: Pending closure of your support request

     

    Hi [Client Name],

     

    We haven’t received a response regarding your service request for [brief summary of issue], and our last follow-up was over 48 hours ago.

     

    As there’s been no further contact, we’ll be closing this ticket today. If the issue persists or you need further assistance, feel free to reply to this email or contact us on 1300 530 000—our team is here to help.

     

    Kind regards,

  • Close the ticket after 72 hours (pending client response).

4. Attempt Resolution or Schedule with Client

• Action:

  • Resolve on first contact if possible (goal = <30 mins)

  • If not, schedule a resolution window

• Time Entry Logging Must Include:

  • Time spent

  • Steps taken

  • If resolved or pending

  • Confidence of resolution (e.g. “will be resolved in the next 15 minutes)

Example Template:

Time Entry Example:
Time Spent: 30 minutes

Steps Taken:

• Created user account in Microsoft 365 admin portal

• Assigned appropriate licences (Business Premium)

• Added user to appropriate distribution groups and shared mailboxes

• Configured Autotask user account and standard permissions

• Tested mailbox access and login to Autotask – successful

• Provided temporary password and key login links to [Client Name] 

Resolution Status:

Confidence: Confident issue will be fully resolved within 15 minutes once user confirms successful login. Awaiting user confirmation before marking as resolved.

5. Ticket Resolved

• Tasks:

  • Enter final notes: what was done, how it was tested, and preventative advice

  • Log accurate time

  • Set ticket to "Completed"

Example Template:

Closing Note Example: 

User setup completed for [Full Name] 

Actions Taken:

• Created Microsoft 365 account and assigne licences

• Added user to:

  • Shared mailboxes: accounts@, support@
    

• Provisioned account with Standard User permissions

• Set up multi-factor authentication and issued temporary password

• Confirmed successful login to email, Teams, and Autotask

• Sent key credentials and login steps

• No issues reported during testing

Resolution Status: Resolved

Testing: Verified login to all platforms; client confirmed access is working

6. Escalate if Needed

• When to Escalate:

  • No resolution within 30 minutes

  • No clear path to resolution within an additional 15 minutes after that

  Action:

  • Escalate internally

  • Add detailed context for the next technician:

    • What’s the issue

    • What was attempted

    • Why it’s urgent

    • Expected outcome

YOU remain fully accountable for any tickets you were originally assigned — even if the ticket is escalated. Escalation does not transfer ownership. You are expected to actively follow through, support the resolution process, and ensure the ticket is completed to standard.

Add Time & Ticket Notes

• • All time must be logged. All notes must be:

    • Clear, concise, client-appropriate

    • Avoid internal shorthand or placeholders

    • Use complete sentences where possible

    • Include context for next steps or follow-up if required

Ticket Closure

When does a ticket close?
A ticket is eligible for closure three business days after being received, provided the following internal process has been followed in full.

⚠️ This process is not optional but a strict service consistency and accountability requirement.

Required Closure Sequence:

1. First Response EmailRequester – acknowledgingClient andend owninguser theor requestchampion.

2. Follow-UpL1 Phone CallTechnician – withinFirst 2contact hoursresolution, iftriage, no replycomms.

3. CallL2 Back EmailTechnician – summarisingSpecialized theresolver attempt(apps, andendpoints, nextM365, stepsnetworking).

4. Pending Closure EmailL3/Engineer – issuedComplex/Systemic afterfixes, 24–48design hours of no contact

Final Checks:

• A clear, final resolution note must be entered

Ticket Resolution Note Example – No Response from Client

Initial request received regarding [brief summary, e.g. access issues to shared mailbox].

Actions Taken:

• Responded within SLA and acknowledged the request

• Attempted phone call to client 2 hours after initial response — no answer

• Sent follow-up email after missed call

• Sent pending closure notice after 48 hours of no reply

• No response received after a total of 3 business days

Status: Unresolved – client non-response
Testing/Resolution: No resolution possible without further client input

• The reminder email must be logged against the ticketchanges.

• NoSecOps loose endsAnalyst – Security investigations & containment.

• Service Desk Manager (unloggedSDM) time,– unclearQueue outcome,health, unresolvedSLA, escalations)escalations, quality.

• Vendor/3rd Party – Line‑of‑business software, carriers, etc.

At ManyComputerman, workflowsthe canservice bedesk automated,is butresponsible technicianfor accountabilityall service levels. Although we reference levels in this document, an L3 is not partimmune from taking an L1 ticket.

Ticket Types

• Incident – Unplanned interruption or degradation.

• Service Request – Standard request (add user, install software).

• Access Request – Subtype of thatService Request with approvals.

• Security Incident (SecOps). If– Potential or confirmed threat activity.

• Recurring Issue (Problem equivalent) – Parent ticket used to track the processroot isn’tcause followed,of themultiple closureincidents.

  is
invalid

• Change Request – A Project or Service Request raised to cover environmental modifications (standard, normal, or emergency changes).

SLA vs KPI Framework

We distinguish between contractual SLAs (compulsory) and reflectsinternal poorKPIs documentation and client service.(targets):

---

Expectations

SLA must always be met. KPI targets are stretch goals for internal performance management and continuous improvement.

Required Fields at Creation

• Client, Site/Department, Requester (name/email/phone)

• Channel (portal/email/phone), Time Opened

• Short BLUF Summary (e.g., “Cannot print invoices – all staff – Warehouse”)

• Detailed Description (symptoms, when started, scope, error text)

• Impact & Urgency (who/how many affected, business process blocked?)

• CI/Asset (device, server, service) where known

• Category → Subcategory (include SecOps as a top‑level category for reporting)

• Attachments/Screenshots, Error IDs

• Related Ticket references (parent/child for recurring issues, or related Project/Request for changes)

Status Model & Transitions

• New → just logged; auto‑triaged within SLA. Ready for triage by AI or Human

• Assigned → owner set (L1/L2/L3). First response sent.

• In Progress → diagnosis/remediation underway.

• Awaiting Customer → need info/testing; must set a Follow‑Up time.

• Awaiting Vendor → external dependency; must set a Follow‑Up time and vendor case #.

• Scheduled / Dispatched → work booked; calendar/event link in ticket.

• On Hold – Change → requires an associated Project or Service Request (change equivalent).

• Resolved → fix applied; customer to verify.

• Completed → verified, coded, documented.

Rules

• No ticket remains in New or Triage past the acknowledgement SLA.

• Any Awaiting or On Hold status must include: next action, owner, and next follow‑up timestamp (aligns with 11:00, 14:00, 16:00 checkpoints when applicable).

• Status changes always include a BLUF note.

Lifecycle – Step by Step

1. Intake & Logging (per SLA targets)

   • Capture required fields. Create on behalf if via phone. Confirm preferred contact method.

   • If Critical (P1) or Security, SDM declares Major Incident/SecOps workflow; initiate bridge/call.

2. Triage & Categorization

   • Validate Type (Incident vs Request). Apply Category/Subcategory (include SecOps when security‑related). Map CI/Asset.

   • Set Priority using Impact×Urgency; record justification in first work note.

   • Apply Ticket Difficulty Score (1–3) to align with technician level and reporting.

3. Assignment & First Response

   • Assign owner (L1 by default). If difficulty>skill or SLA risk, escalate to L2/L3 or SDM.

   • First Response (client‑facing):

     • Critical/High: phone call + ticket note + email summary.

     • Normal/Low: email/portal update. Use BLUF, set expectations (next update time).

4. Diagnosis & Work Notes (Iterative)

   • Follow ABC format in notes: Action taken, Because (hypothesis), Checkpoint (result/next step). Log timestamps.

   • Use standard playbooks (M365, EDR, DNS, Mail filtering, Print, etc.).

   • For SecOps: contain → eradicate → recover; avoid sending sensitive data over email; use approved secure channels.

5. Escalation

   • Functional: to L2/L3/Vendor for expertise.

   • Hierarchical: to SDM if SLA risk, client impact growing, or comms issues.

   • Always include what’s been tried and relevant artifacts.

6. Resolution & Recovery

   • Implement fix or approved workaround. Validate service restored with the requester.

   • For Critical/Major/SecOps: capture timeline of events and remediation steps.

7. Verification & Client Communication

   • Confirm with requester (phone for Critical/High; email acceptable for Normal/Low if agreed).

   • Record user confirmation or attempted confirmation attempts.

8. Closure (Same Day after Verification)

   • Set Resolution Code (e.g., Hardware, Software, Config, User Education, Vendor, SecOps, Change Implemented).

   • Enter Resolution Summary (BLUF + root cause if known + steps taken + prevention/KB link).

   • If recurring/systemic: flag to SDM to create a parent ticket (Problem equivalent).

   • If environment modification/change is required: raise a Project or Service Request and reference the ticket.

   • If the requester does not respond after two follow‑ups over two business days, close with the note “No client response—service confirmed working from logs/tests.”

Communication Standards (Client‑Facing)

• Tone: Friendly, concise, professional; avoid deep technical detail unless requested.

• Cadence (minimums):

  • Critical: every 30 min

  • High: every 2 hrs

  • Normal: daily

  • Low: every 2–3 days

• Templates

  • First Response (BLUF):
    “BLUF: We’ve taken ownership and are investigating. Impact: <who/what>. Next update by . Ref: <ticket#>.”

  • Awaiting Customer:
    “We need <specific info/test>. Once received, we expect to proceed to . We’ll follow up by if we don’t hear back.”

  • Resolution:
    “Resolved: . Cause: <root cause/likely>. Please confirm by . We’ll close once confirmed.”

SLA & KPI Anchors

• Acknowledgement SLA meets the contractual table above.

• Resolution Targets: contractual SLA must be achieved; internal KPI targets are stretch goals.

• Quality: 100% of tickets include required fields, proper status, and closure coding; 0 “orphan” tickets (no owner).

• Update Timeliness: ≥95% tickets meet cadence; exceptions justified in notes.

Guardrails

• Do not provide full technical fixes over email by default; use email to acknowledge, set expectations, and arrange support.

• On Hold without next action/time is non‑compliant.

• Security: escalate to SecOps category; avoid sending credentials/logs via email; follow SecOps playbook.

Knowledge & Continuous Improvement

• Convert repeated fixes into KB articles; link KB at closure.

• For Critical/Major or recurring issues, raise a parent ticket.

• Raise a Project or Service Request for environment modifications.

• Feed insights into weekly review and monthly executive reporting.

Handoffs to Other Processes

• Standup Meetings: ticket commitments and blockers surfaced daily (ties to 11:00 / 14:00 / 16:00 checkpoints).

• Ticket Reviews: SDM audits open tickets daily for status hygiene and SLA risk.

• Intra‑Day Accountability: owners set targets and managers follow up at checkpoints.

• Weekly Review: KPIs, aged tickets, root‑cause themes, and improvements.

Quick Checklists

When you open a ticket

•  Summary (BLUF) + description

•  Type, Category (incl. SecOps if relevant), Priority, CI/Asset

•  Requester contact confirmed

•  First response time set

When you change status

•  BLUF note (what changed, next step, next update time)

•  Owner remains clear

•  Follow‑up timestamp (if Awaiting/On Hold)

Before closure

•  User verification (or documented attempts)

•  Resolution summary + code

•  Reference parent ticket (Problem equivalent) or Project/Request (Change equivalent) if applicable

•  Links to KB if created

•  Time entries complete