Capture a clear starting record
Ask for a short summary, description, affected service, location, requester and preferred contact method. Add device or asset details automatically when possible. The request channel and time received should be recorded without asking the user.
Offer categories that match how the team works, such as classroom technology, accounts, network, printing, safeguarding systems and facilities. Keep the list short enough that staff can choose confidently.
Separate impact from urgency
A senior colleague asking quickly does not automatically make a ticket critical. Priority should combine impact and urgency. A projector fault in one classroom differs from an identity-service outage affecting the whole school.
- Impact: one person, one class, a department, a campus or the whole school
- Urgency: workaround available, lesson affected, safeguarding risk or service unavailable
- Priority: calculated from the agreed impact and urgency rules
- Target: response and resolution expectations appropriate to that priority
Preserve ownership and decisions
Every open ticket needs a current owner, status and next action. Record internal notes separately from messages visible to the requester. When ownership changes, the history should explain why and what the receiving person needs to do.
Use pending only when the team is waiting for something specific. Record whether that is the requester, a supplier, a purchasing decision or a scheduled change.
Connect tickets to assets and recurring problems
Link a ticket to the affected laptop, printer, access point or room. Over time this reveals repeated failures, warranty issues and the true support cost of equipment. Keep serial numbers and assignment data in the asset register rather than copying them into each ticket.
Use problem labels or related-ticket links for repeated symptoms. A good knowledge article should emerge from a resolved pattern, with its owner and review date recorded.
Measure service without gaming it
Track measures that help the team improve. A low closure time is meaningless if tickets are closed before users confirm the fix. Review trends by service and cause, then pair numbers with a sample of real conversations.
- Time to first useful response
- Time waiting on the support team versus others
- Reopened tickets and repeat incidents
- Backlog age by priority
- Demand by service, department and location
- Requester feedback after resolution