Suggested internal IT support workflow. Response targets and business hours must be agreed locally; this is not a universal SLA.
Research-based; no hands-on test claim.Capture enough to begin
Ask for the affected service, symptoms, start time, scope and a safe way to contact the requester. Record business impact and any workaround. Do not ask users to paste passwords or sensitive datasets into a ticket. A screenshot can help, but check what it exposes.
Distinguish an incident from an access request or a planned change. A broken service needs restoration; a new permission needs authorisation. Sending both through the same unqualified fast-resolution path can bypass the controls each requires.
Triage and assign one accountable owner
Use impact and urgency to establish priority, with a documented override for exceptional cases. Check for duplicates and a wider incident before treating every report as unrelated. Link reports to the parent incident while preserving affected-user communication.
Assign an owner who remains accountable when work moves between teams. A queue name alone is not an acknowledgement. Set the next update time and make the escalation path visible before the first response deadline is missed.
Use states that explain the next action
Keep states few and meaningful: new, triaged, in progress, waiting, resolved and closed. Waiting needs a reason, the party being waited on and a review date. Define which waiting conditions pause an SLA and disclose them to stakeholders.
Record diagnostics, changes and results as the work happens. Separate private operational notes from messages sent to the requester. For privileged changes, link the approval and change record rather than treating possession of a ticket as authorisation.
| State | Required record |
|---|---|
| Triaged | Impact, urgency, category and owner |
| In progress | Current action and next update |
| Waiting | Dependency, responsible party and review date |
| Resolved | Outcome and verification |
| Closed | Acceptance or documented closure rule |
Resolve, verify and learn
Explain the fix in user terms and verify the original task. Record known limitations, follow-up work and the conditions for reopening. A ticket marked resolved should not imply that an underlying recurring problem has been eliminated.
Review reopened tickets, transfers and ageing work alongside response times. A team can improve a metric by closing prematurely while making the user experience worse. Convert reusable solutions into controlled documentation and create a problem investigation for patterns that need deeper work.