Ticket Lifecycle

Purpose

ProvideThis document explains the full journey of a clear, simple, and ITIL‑aligned lifecycle for every support ticket in simple, clear language. It is based on best practices from ITIL but avoids jargon so techniciansanyone deliveron consistentthe results, managersteam can enforcefollow accountability,it. The goal is to make sure every ticket is handled consistently, customers are kept informed, and reportingwe staysmeet accurate.our service agreements.

Scope

AllThis client‑facingprocess applies to all tickets raised to Computerman’s Support Desk: Incidents, Service Requests, Access Requests, Questions, and (when applicable)something ticketsis relatedbroken, when a client needs help, when they need access to recurring issues (Problem equivalent)something, or environmentwhen modificationsthere’s (Changea equivalent).security issue.

Roles

• RequesterClient – ClientThe endperson userasking orfor champion.help.

• L1Technician Technician(Level 1) – First contactresponder resolution,who triage,picks comms.up, checks, and fixes simple issues.

• L2Technician Technician(Level 2/3) – SpecializedHandles resolvermore (apps,complex endpoints,issues M365,or networking).escalations.

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

• SecOpsSecurity Analyst – SecuritySteps investigationsin &if containment.there is a security concern.

• Service Desk Manager (SDM) – QueueKeeps health,the SLA,queue escalations,healthy, quality.checks SLAs, and supports the team.

• Vendor/3rd Party – Line‑of‑businessExternal software,software carriers,provider etc.or carrier.

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 – UnplannedSomething interruptionis broken or degradation.not working as expected.

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

• Access Request – SubtypeA request for access (subtype of Service Request with approvals.Request).

• Security Incident (SecOps) – PotentialPossible or confirmed threatsecurity activity.issue.

• Recurring Issue (Problem equivalent) – ParentA parent ticket usedfor tosomething trackthat thekeeps root cause of multiple incidents.happening.

• Change Request(Project/Request) – AWhen Projectwe need to make a planned change to fix or Serviceimprove Request raised to cover environmental modifications (standard, normal, or emergency changes).something.

SLAService vs KPI FrameworkLevels

We distinguishhave betweentwo types of performance targets:

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

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

  (targets):

Priority	SLA – First Response (SLA)	SLA – Resolution Plan (SLA)	ResolvedSLA (SLA)– Full Resolution	Internal KPI Targets
Critical	1 hr	1.5 hrs	3 hrs	AcknowledgeRespond in 15 min, updatesupdate every 30 min, restore ASAP; PIR if security/major incidentASAP
High	2 hrs	3 hrs	4 hrs	AcknowledgeRespond in 1 hr, updatesupdate every 2 hrs, resolve same day
Normal	4 hrs	6 hrs	8 hrs	AcknowledgeRespond in 4 hrs, dailyupdate updates,daily, resolve withinin 3 business days
Low	8 hrs	15 hrs	32 hrs	AcknowledgeRespond in 1 business day, updatesupdate every 2–3 days, resolve withinin 10 business days

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

Required FieldsInfo atWhen CreationLogging a Ticket

• Client,Client Site/Department,name Requesterand contact details

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

• ChannelShort summary of the issue (portal/email/phone),one Timeline OpenedBLUF: Bottom Line Up Front)

• ShortFull BLUF Summarydescription (e.g.,symptoms, “Cannotwho printit invoicesaffects, –when allit staff – Warehouse”)started)

• Detailed DescriptionPriority (symptoms,Impact when× started, scope, error text)Urgency)

• ImpactDevice/service & Urgencyaffected (who/howif many affected, business process blocked?)

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

• Category →(e.g., Subcategoryemail, (includeprinting, SecOps as a top‑level category for reporting)security)

• Attachments/Screenshots,screenshots Errorif IDs

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

StatusTicket Model & TransitionsStatuses

• New →– justJust logged;logged.

  auto‑triaged
within
• SLA.

  Triaged Ready– forChecked, triagecategorized, byand AIpriority or Humanset.

• Assigned →– ownerTechnician settakes (L1/L2/L3).ownership Firstand response sent.responds.

• In Progress →– diagnosis/remediationWork underway.is being done.

• Awaiting Customer →– needWaiting info/testing;on mustthe setclient ato Follow‑Upreply time.or test.

• Awaiting Vendor →– externalWaiting dependency; must seton a Follow‑Upthird time and vendor case #.party.

• Scheduled /– DispatchedWork →is workbooked booked;for calendar/eventa linkspecific in ticket.time.

• On Hold – Change →– requiresWaiting anfor associateda Projectplanned change or Service Request (change equivalent).project.

• Resolved →– fixFix applied;applied, customerwaiting tofor verify.confirmation.

• Completed →– verified,Confirmed coded,and documented.finished.

RulesImportant Rules:

• NoTickets ticketcannot remainsstay in New or Triage pastlonger than the acknowledgementSLA SLA.for first response.

• AnyIf Awaitinga orticket Onis Holdwaiting statuson someone (client, vendor, change), it must include:have nexta action,clear owner, and next follow‑follow-up timestamp (aligns with 11:00, 14:00, 16:00 checkpoints when applicable).time.

• StatusEvery changesstatus alwayschange must include a short BLUF note.

Lifecycle – Step by Step Ticket Journey

1. IntakeLog &the Loggingticket (per– SLAEnter targets)

   • Captureall required fields. Create on behalf if via phone.details. Confirm preferredhow contactthe method.client wants to be contacted.

   • 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).Decide Mapwhat CI/Asset.

     type
   of
   • ticket

     Setit Priorityis, usingset Impact×Urgency; record justification in first work note.

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

     note

3. Assignment & First Response

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

   • FirstAssign Response& Respond (client‑facing):– Technician takes ownership and sends the first response:

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

     • Normal/Low: email/email or 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.

   • UseAlways standardset playbooksexpectations (M365,for EDR,the DNS,next Mail filtering, Print, etc.).

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

5. EscalationWork on the issue

   –
   • Add

     Functional:notes toevery L2/L3/Vendortime foryou expertise.take an action. Keep notes simple: what you did, why, what happened.

   • HierarchicalEscalate if needed: – If the issue is too complex or urgent, pass it to SDMthe ifright SLAperson risk,(L2/L3, client impact growing,Manager, or comms issues.Vendor).

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

6. Resolution &– Recovery

   Apply

   • Implementthe fix or approveda workaround. ValidateConfirm the service restoredis withworking the requester.again.

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

7. Verification &– Client Communication

   • ConfirmCheck with requesterthe (phoneclient. forIf Critical/High;they emailconfirm, acceptablemove forto Normal/Lowclosure. ifIf agreed).not, continue work.

   • Record user confirmation or attempted confirmation attempts.

8. Closure (Same Day after Verification)

   • Set Resolution Code (e.g.,– Hardware,Record Software,a Config,clear Userresolution Education,summary, Vendor,pick SecOps,the Changeright Implemented).

     resolution
   code,
   • and

     Entermake Resolutionsure Summaryall (BLUFtime +is rootentered. cause if known + steps taken + prevention/KB link).

   • If recurring/systemic:the flagissue tois recurring, ask SDM to create a parent ticketticket. (Problem equivalent).

   • If environmentit modification/change is required: raiserequired a Projectplanned or Service Request andchange, reference the ticket.related Project/Request.

   • 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,clear, professional; avoid deep technical detail unless requested.professional.

• CadenceUpdate frequency (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.”

SLAQuality & KPI AnchorsChecks

• AcknowledgementEvery SLAticket meetsmust have the contractualrequired tableinfo above.filled in.

• ResolutionEvery Targets: contractual SLAticket must behave achieved;an internal KPI targets are stretch goals.owner.

• Quality:Every 100%update ofmust ticketshave includea requiredBLUF fields, proper status, and closure coding; 0 “orphan” tickets (no owner).note.

• Update Timeliness: ≥95%No tickets meetshould cadence;be exceptionsleft 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“hanging” without next action/time is non‑compliant.

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

Knowledge & Continuous Improvement

• ConvertIf repeatedyou fixesfix intosomething KBmore articles;than linkonce, KBcreate ata closure.Knowledge Base article.

• ForIf Critical/Majoran orissue recurringkeeps issues,coming raiseback, flag it as a parentrecurring ticketissue. so SDM can track the root cause.

• RaiseBig a Projectissues or Serviceprojects Requestshould forbe environmentraised modifications.

  as

• Feed insights into weekly review and monthly executive reporting.

Handoffs to Other Processes

• Standup MeetingsProjects/Requests: 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

• SummaryBLUF (BLUF)summary + description

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

• RequesterContact contactdetails confirmed

• First response timetarget set

When you change status

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

• OwnerEnsure remainsticket owner is clear

• Follow‑Add follow-up timestamptime (if Awaiting/Onwaiting Hold)on someone

Before closure

• UserConfirm verificationwith client (or documenteddocument attempts)

• ResolutionAdd resolution summary + code

• Reference parent ticket (Problemif equivalent)recurring issue) or Project/Request (Change equivalent) if applicablechange)

• Links toAdd KB link if created

• Time entries complete