IT help desk process map

A swimlane map of everything that arrives at a service desk (incidents and service requests both) from first contact to closure, across the user, the service desk, tier 2 support, asset and procurement, and problem management. The first real decision is the one that splits the two, and almost everything downstream depends on getting it right.

Open this map in the editor

Opens a copy in the editor and saves it in this browser. No account, nothing sent anywhere.

What is in this map

20 steps across 5 swimlanes and 5 phases, with 7 decision points.

Swimlanes (who does the work): User, Service desk, Tier 2 support, Asset and procurement and Problem management
Phases (left to right): Contact, Logging and triage, First line, Escalation and fulfilment and Resolution and closure

Why map this process

A help desk's biggest efficiency problem is that two unlike things share a queue. An incident needs restoring; a service request needs fulfilling. They have different clocks, different approvals and different owners, and treating them as one stream is why request fulfilment always feels slow: it is competing with things that are actually broken.

Mapping them together, then splitting them explicitly, is more useful than drawing two maps. Everyone sees the same intake, the same triage, and then the fork, which makes the fork a decision people can discuss rather than an inconsistency they work around.

Every step in the map

This is the spreadsheet behind the diagram. The numbers in “Goes to” are row numbers, which is exactly what the editor’s “Line to” column holds — so you can read the flow here and retype any part of it.

Every step in the IT help desk process (incidents and service requests) process map, in the order the editor numbers them.
#	Step	Shape	Swimlane	Phase	Goes to
1	User contacts the service desk	Start	User	Contact	2
2	Receive contact on any channel	Trigger	Service desk	Contact	3
3	Log and categorise the ticket	Process	Service desk	Logging and triage	4
4	Incident or service request?	Decision	Service desk	Logging and triage	5 (Incident), 11 (Request)
5	Set priority from impact and urgency	Process	Service desk	Logging and triage	6
6	Known fix in the knowledge base?	Decision	Service desk	First line	7 (Yes), 8 (No)
7	Apply the documented fix	Process	Service desk	First line	9
8	Attempt a first-line fix	Process	Service desk	First line	9
9	Resolved at first line?	Decision	Service desk	First line	16 (Yes), 10 (Escalate)
10	Investigate and resolve at tier 2	Process	Tier 2 support	Escalation and fulfilment	16
11	Line manager approves the request?	Decision	Service desk	Escalation and fulfilment	12 (Approved), 15 (Declined)
12	Item held in stock?	Decision	Asset and procurement	Escalation and fulfilment	14 (In stock), 13 (Order)
13	Raise a purchase order	Document	Asset and procurement	Escalation and fulfilment	14
14	Fulfil request and update asset record	Process	Asset and procurement	Escalation and fulfilment	16
15	Request declined and closed	Reject	Service desk	Escalation and fulfilment	End
16	Record resolution and notify the user	Process	Service desk	Resolution and closure	17
17	User confirms it is fixed?	Decision	User	Resolution and closure	18 (Confirmed), 8 (Reopen)
18	Recurring or known issue?	Decision	Service desk	Resolution and closure	19 (Recurring), 20 (One-off)
19	Raise a problem record	Stored data	Problem management	Resolution and closure	20
20	Ticket closed	End	Service desk	Resolution and closure	End

The decision points

Every branch in the map, with the label on each outgoing line. These are the questions the process has to be able to answer.

4. *Incident* or *service request*?

Owned by Service desk · Logging and triage
- Incident → step 5
- Request → step 11
6. Known fix in the **knowledge base?**

Owned by Service desk · First line
- Yes → step 7
- No → step 8
9. Resolved at first line?

Owned by Service desk · First line
- Yes → step 16
- Escalate → step 10
11. Line manager **approves the request?**

Owned by Service desk · Escalation and fulfilment
- Approved → step 12
- Declined → step 15
12. Item held in stock?

Owned by Asset and procurement · Escalation and fulfilment
- In stock → step 14
- Order → step 13
17. User confirms it is fixed?

Owned by User · Resolution and closure
- Confirmed → step 18
- Reopen → step 8
18. **Recurring** or known issue?

Owned by Service desk · Resolution and closure
- Recurring → step 19
- One-off → step 20

Notes on specific steps

These notes travel with the map. In the editor they live in the Notes column and appear when you open a box.

2. Receive contact on any channel: Phone, email, self-service portal, chat and walk-up all land in one queue. A channel that bypasses the queue is invisible to reporting, and the desk will underestimate its own workload.
4. *Incident* or *service request*?: An incident is something broken that should be working. A service request is standard, pre-agreed work such as new software, a licence or a replacement device. Getting this fork wrong is what puts routine requests on an outage clock.
5. Set priority from *impact* and *urgency*: Priority is derived, not negotiated: impact (how many people, or which service) on one axis, urgency (how fast it hurts the business) on the other. Publish the grid so agents and users read the same answer.
10. Investigate and resolve at tier 2: An escalation has to carry what first line already tried, the affected service and when the user is available. Escalations that arrive as a one-line title get sent back, and the clock keeps running.
11. Line manager **approves the request?**: Mark low-cost catalogue items as pre-approved so they skip this gate entirely. Reserve approval for spend, licences and anything that changes what a person can access.
18. **Recurring** or known issue?: Refer the pattern, not the ticket. The ticket still closes here; the problem record carries the root cause work on its own, much slower clock.

Making it yours

Adapt the triage phase and leave the rest alone at first. Your categorisation scheme, your first-line resolution scope and your escalation trigger all live in that one phase, and they are the three things that differ between service desks. The asset and procurement lane matters more than it looks: hardware requests leave IT entirely for a while, and that wait is invisible unless it has a lane.

What to watch out for

First-line resolution needs a time box in the branch label, not just a decision. 'Can first line fix it?' with no limit becomes a ticket that sits with tier 1 for a week before escalating.
Service requests that need approval are a branch, not a step. A new laptop needs a manager; a password reset does not. Without the branch the map either over-controls the trivial or under-controls the expensive.
Closure by timeout (the user never responded) is a real ending and needs its own path, or the map implies every ticket ends in a confirmed fix.

Frequently asked questions

Should incidents and service requests really share one map?

Up to triage, yes: they share the contact channels, the logging and the categorisation. After triage they should visibly diverge. Drawing it this way makes the split explicit and gives you one artefact to explain the desk with, instead of two that overlap for their first third.

How do I show multiple contact channels: phone, portal, email, walk-up?

As parallel entry rows in the user lane that all feed the same logging step. What matters is that they converge before triage: a channel that bypasses logging is a channel whose tickets do not exist, which is the most common reason desk statistics disagree with what the team experienced.

Where should the problem-management handoff sit?

After closure, as a decision asking whether this ticket is one of a recurring pattern. Putting it before closure delays the ticket for an analysis that is not about this user; putting it after keeps the ticket honest and still creates the link.

Open the map and start editing

The editor loads this chart with the spreadsheet underneath it. Change a cell and the diagram redraws — no drawing, no signup.

Open this map in the editor