Skip to main content

Ticket Lifecycle

Purpose

Provide a clear, simple, and ITIL‑aligned lifecycle for every support ticket so technicians deliver consistent results, managers can enforce accountability, and reporting stays accurate.

Scope

All client‑facing tickets raised to Computerman’s Support Desk: Incidents, Service Requests, Access Requests, Questions, and (when applicable) tickets related to recurring issues (Problem equivalent) or environment modifications (Change equivalent).

Roles

  • Requester – Client end user or champion.

  • L1 Technician – First contact resolution, triage, comms.

  • L2 Technician – Specialized resolver (apps, endpoints, M365, networking).

  • L3/Engineer – Complex/Systemic fixes, design changes.

  • SecOps Analyst – Security investigations & containment.

  • Service Desk Manager (SDM) – Queue health, SLA, escalations, quality.

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

At Computerman, the service desk is responsible for all service levels. Although we reference levels in this document, an L3 is not immune from taking an L1 ticket.

Ticket Types

  • Incident – Unplanned interruption or degradation.

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

  • Access Request – Subtype of Service Request with approvals.

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

  • Recurring Issue (Problem equivalent) – Parent ticket used to track the root cause of multiple incidents.

  • 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 internal KPIs (targets):

Priority First Response (SLA) Resolution Plan (SLA) Resolved (SLA) Internal KPI Targets
Critical 1 hr 1.5 hrs 3 hrs Acknowledge 15 min, updates every 30 min, restore ASAP; PIR if security/major incident
High 2 hrs 3 hrs 4 hrs Acknowledge 1 hr, updates every 2 hrs, resolve same day
Normal 4 hrs 6 hrs 8 hrs Acknowledge 4 hrs, daily updates, resolve within 3 business days
Low 8 hrs 15 hrs 32 hrs Acknowledge 1 business day, updates every 2–3 days, resolve within 10 business days

Rule: 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

Back to top