IT help desk process flowchart (incidents and requests)
IT help desk process flowchart: one queue for incidents and service requests, with triage, priority, first-line fix, tier 2 escalation, fulfilment and closure.
How it works
Rename the lanes to your real roles
Replace User, Service desk, Tier 2 support, Asset and procurement, and Problem management with the teams you have. Small organisations often merge asset and procurement into the service desk lane, and problem management may be a named person rather than a team. Keep one lane per decision-maker rather than per individual, so the chart survives someone changing job.
Write down the incident versus service request test
The "Incident or service request?" fork only works if agents can apply it in seconds. Write the test next to the decision: is something that should be working broken, or is the user asking for standard, pre-agreed work? List your genuine borderline cases, such as a slow laptop against a request for a new one, and say which way each goes.
Publish your priority matrix
Attach your impact and urgency definitions to "Set priority from impact and urgency", stating what each priority level means in terms of users affected and business consequence. Publishing the grid where users can read it is what turns priority into something derived rather than argued over per ticket.
Set the first-line boundary and what an escalation carries
Define what first line is allowed and equipped to fix, and what an escalation must contain before tier 2 accepts it: steps already tried, affected service, evidence and the user's availability. Decide whether you also want a time-based backstop that escalates a ticket that has made no progress, and say who owns it after the handoff.
Decide what needs approval and what is pre-approved
Mark low-cost, low-risk catalogue items as pre-approved so they bypass "Line manager approves the request?" entirely, and reserve the gate for spend, licences and anything that changes what a person can access. Where the request is for system access, hand off to your access request process rather than approving it here.
Agree closure, reopen and problem referral, then publish one version
State what counts as user confirmation, how long a resolved ticket waits before auto-closing, and the criteria on "Recurring or known issue?" that raise a problem record. Then walk the chart with each lane, correct the steps they actually perform, and publish it as the current version with a recorded sign-off so everyone is reading the same revision.
Frequently asked questions
What is the difference between an IT help desk process and incident management?
The help desk process is the operating flow of the desk itself: every contact that arrives, on any channel, routed to the right kind of handling. Incident management is one strand inside it, dealing only with unplanned interruptions to a service. ITIL 4 treats service desk, incident management, service request management and problem management as separate practices for exactly this reason, though a small team usually runs all of them from one queue with the same people. This chart is the desk-level view that shows how the strands share an intake and a closure, and hands the deep incident detail, such as major incident declaration and SLA breach escalation, to the incident management process.
What is the difference between an incident and a service request?
An incident is something that should be working and is not: a failed login, a printer offline, an application throwing errors. A service request is standard, pre-agreed work with no fault involved: new software, a licence, a replacement device, a mailbox for a new starter. The distinction matters because it changes almost everything downstream. Incidents get a priority from impact and urgency and are measured on restoration; requests get an approval and a fulfilment path and are measured on delivery. Mixing them means either routine requests sit on an outage clock, or genuine outages queue behind laptop orders.
When should a help desk ticket be escalated to tier 2?
Escalate when the work has passed the boundary of first line's skills, tooling or access, which is a functional escalation. That is a different thing from a hierarchic escalation, where a manager is pulled in because the impact or the delay has become a business issue rather than a technical one. Many desks add a time-based backstop so a ticket that has made no progress is escalated automatically, which is useful as a safety net but a poor primary rule on its own. Whatever triggers it, the handoff needs to carry what has already been tried, or tier 2 spends its first hour repeating first line's work.
Should a ticket be closed before the user confirms the fix?
Resolved and closed are two different states, and this chart keeps them apart. An agent marks a ticket resolved when the fix is applied; it is closed only after "User confirms it is fixed?" returns a yes. If the user says the problem is still there, the ticket reopens to first line rather than starting a fresh one, which keeps the history and the original clock together. Because some users never reply, most desks set an auto-close window of a few working days with a reminder first, and state that period in the service description so closure is not a surprise.
How do service requests that involve buying something fit into the process?
They follow the fulfilment branch: approval where the catalogue requires it, then "Item held in stock?" which either issues from existing stock or raises a purchase order before fulfilment. The step people skip is updating the asset record, which is why it sits in the same node as fulfilment here. If the asset register is not updated at the point of issue, licence counts and hardware refresh planning drift out of date within months. For larger or non-catalogue purchases the desk raises the need and the wider purchase order process takes over, with its own sourcing and invoice matching.