Suggested internal IT support workflow. Response targets and business hours must be agreed locally; this is not a universal SLA.
Stuart Kerr Spindlow has confirmed personal use and testing of the software covered by Happy SysAdm. The assessments here distinguish documented behaviour from measured results; worked scenarios are labelled and are not personal test records.Capture enough to begin
A short state model with one accountable owner is preferable to many status labels that do not change the next action. Keep incidents, access requests and planned changes distinguishable even if they share the same tool. An incident workflow prioritises restoration; an access workflow must preserve authorisation. The quickest closure is not the best outcome if it bypasses approval or prompts a reopen.
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 |
Keep ownership through every ticket state
- New → triaged
Record impact, urgency and one accountable owner.
- In progress
Record the next action and update time.
- Waiting, if needed
Record the dependency, responsible party and review date; return to active work when unblocked.
- Resolved → closed
Verify the outcome, then record acceptance or the agreed closure rule.
Response and restoration targets depend on locally agreed service commitments.
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.
Read response and resolution numbers together
In a hypothetical batch of 50 resolved tickets, five reopen, giving a 10% reopen rate for that defined cohort and observation window. If those five tickets reopen after the reporting cutoff, the rate changes; record the window rather than comparing differently aged cohorts.
For a ticket opened at 09:00, answered at 09:15 and accepted as resolved at 12:00, first response is 15 minutes and elapsed resolution is three hours. A one-hour waiting state may produce a two-hour SLA clock under a stated policy, but the requester still experienced three elapsed hours. These are worked examples, not results from this publication’s help desk.