Skip to main content

Ticket Lifecycle

Purpose

This document explains the full journey of a support ticket in simple, clear language. It is based on best practices from ITIL but avoids jargon so anyone on the team can follow it. The goal is to make sure every ticket is handled consistently, customers are kept informed, and we meet our service agreements.

Scope

This process applies to all tickets raised to Computerman’s Support Desk: when something is broken, when a client needs help, when they need access to something, or when there’s a security issue.

Roles

  • Client – The person asking for help.

  • Technician (Level 1) – First responder who picks up, checks, and fixes simple issues.

  • Technician (Level 2/3) – Handles more complex issues or escalations.

  • Security Analyst – Steps in if there is a security concern.

  • Service Desk Manager (SDM) – Keeps the queue healthy, checks SLAs, and supports the team.

  • Vendor/3rd Party – External software provider or carrier.

Ticket Types

  • Incident – Something is broken or not working as expected.

  • Service Request – A request for something new (e.g., new user, install software).

  • Access Request – A request for access (subtype of Service Request).

  • Security Incident – Possible or confirmed security issue.

  • Recurring Issue (Problem equivalent) – A parent ticket for something that keeps happening.

  • Change (Project/Request) – When we need to make a planned change to fix or improve something.

Service Levels

We have two types of performance targets:

  • Contractual SLAs – Must always be met (these are in client contracts).

  • Internal Targets (KPIs) – Stretch goals that help us work faster and better, your internal target.

Priority SLA – First Response SLA – Resolution Plan SLA – Full Resolution Internal Targets
Critical 1 hr 1.5 hrs 3 hrs Respond in 15 min, update every 30 min, restore ASAP
High 2 hrs 3 hrs 4 hrs Respond in 1 hr, update every 2 hrs, resolve same day
Normal 4 hrs 6 hrs 8 hrs Respond in 4 hrs, update daily, resolve in 3 business days
Low 8 hrs 15 hrs 32 hrs Respond in 1 business day, update every 2–3 days, resolve in 10 business days

Required Info When Logging a Ticket

  • Client name and contact details

  • How the ticket came in (portal, email, phone)

  • Short summary of the issue (one line BLUF: Bottom Line Up Front)

  • Full description (symptoms, who it affects, when it started)

  • Priority (Impact × Urgency)

  • Device/service affected (if known)

  • Category (e.g., email, printing, security)

  • Attachments/screenshots if available

Ticket Statuses

  • New – Just logged.

  • Triaged – Checked, categorized, and priority set.

  • Assigned – Technician takes ownership and responds.

  • In Progress – Work is being done.

  • Awaiting Customer – Waiting on the client to reply or test.

  • Awaiting Vendor – Waiting on a third party.

  • Scheduled – Work is booked for a specific time.

  • On Hold – Change – Waiting for a planned change or project.

  • Resolved – Fix applied, waiting for confirmation.

  • Completed – Confirmed and finished.

Important Rules:

  • Tickets cannot stay in New or Triage longer than the SLA for first response.

  • If a ticket is waiting on someone (client, vendor, change), it must have a clear follow-up time.

  • Every status change must include a short BLUF note.

Step by Step Ticket Journey

  1. Log the ticket – Enter all required details. Confirm how the client wants to be contacted.

  2. Triage – Decide what type of ticket it is, set priority, and note why.

  3. Assign & Respond – Technician takes ownership and sends the first response:

    • Critical/High: phone call + email.

    • Normal/Low: email or portal update.

    • Always set expectations for the next update.

  4. Work on the issue – Add notes every time you take an action. Keep notes simple: what you did, why, what happened.

  5. Escalate if needed – If the issue is too complex or urgent, pass it to the right person (L2/L3, Manager, or Vendor).

  6. Resolution – Apply the fix or a workaround. Confirm the service is working again.

  7. Verification – Check with the client. If they confirm, move to closure. If not, continue work.

  8. Closure – Record a clear resolution summary, pick the right resolution code, and make sure all time is entered. If the issue is recurring, ask SDM to create a parent ticket. If it required a planned change, reference the related Project/Request.

Communication Standards

  • Tone – Friendly, clear, professional.

  • Update frequency –

    • Critical: every 30 min

    • High: every 2 hrs

    • Normal: daily

    • Low: every 2–3 days

  • Templates –

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

    • Awaiting Customer: “We need . 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.”

Quality Checks

  • Every ticket must have the required info filled in.

  • Every ticket must have an owner.

  • Every update must have a BLUF note.

  • No tickets should be left “hanging” without next steps.

Knowledge & Improvement

  • If you fix something more than once, create a Knowledge Base article.

  • If an issue keeps coming back, flag it as a recurring issue so SDM can track the root cause.

  • Big issues or projects should be raised as Projects/Requests.

Quick Checklists

When you open a ticket

  • BLUF summary + description

  • Type, Category, Priority, Device/Service

  • Contact details confirmed

  • First response target set

When you change status

  • Add BLUF note

  • Ensure ticket owner is clear

  • Add follow-up time if waiting on someone

Before closure

  • Confirm with client (or document attempts)

  • Add resolution summary + code

  • Reference parent ticket (if recurring issue) or Project/Request (if change)

  • Add KB link if created

  • Time entries complete

Back to top