The IT service desk as a ready-made computational model

Inflow: 24,000 tickets a year, about 96 on a working day, with a day-to-day variation of 28 % and a peak factor of 1.35 on 8 % of days. Mondays, rollouts, outages.

The "share" column is why this template reads differently from the others: second level only sees a third of the tickets. Measure its utilisation against the full volume and you get 155 %, and you call a step overloaded that is actually running at 57 %.

The decisive finding. Constraint probability per step, across 20,000 runs:

The column adds up to 100 %: each run counts exactly one binding step, the one carrying the highest load that day.

Second level, blamed in house for long turnaround, is the constraint in 14 % of runs. The service desk, the place where a ticket is merely taken down, for five to ten minutes, is the constraint in 75 %. The process loses its time before the work, not inside it.

And that is where a spreadsheet fails. Five minutes per ticket is unremarkable. Ninety-six times five to ten minutes is not.

1. Tickets per working day. Last year's tickets ÷ working days. The helpdesk report has it. Take the same definition of a ticket (duplicates, bulk incidents) that you will use when you measure again afterwards.
2. Peak factor. How many tickets arrive on the busiest day compared with a normal one? Monday, the day after a rollout, the day of an outage. A factor of 1.3 to 2 is common. Without it you are computing a service desk that is never under load, and load is a service desk's normal state.
3. People on the service desk and their hours for triage. Not the size of the team. Somebody taking calls alongside does not have eight hours for intake.
4. The processing range for triage. Low end and high end. Five minutes for a password, twenty for an incident report that has to be reconstructed first. That range is what drives the waiting time.
5. The share solved on the spot. 65 to 35 in the template. Every helpdesk report carries this as first-contact resolution, and it is the one number here you can genuinely measure. It shifts load between the branches, not before them.
6. Fully loaded rates per role. Gross salary × 1.5 to 1.8, divided by roughly 1,500 productive hours a year. At 24,000 cases a year every euro of rate difference matters; a naive rate from salary ÷ 2,080 hours makes the statement in money attackable later.

Cross-check before you compute: count the open tickets in the system and divide by the tickets you close in a day (Little's Law). If that lands near your known turnaround, the model is usable. A large deviation means a queue is missing, with tickets almost always the "waiting for the user" status.

What the template does not contain. Lead time here is processing plus queueing, in working days. Prioritisation is not modelled: the model works in arrival order. If you run real prioritisation, model it as a second branch with its own capacity; otherwise the model is too slow for urgent tickets and too fast for the rest. Also absent: the time a ticket spends waiting on the user.

Lever 1. A form at intake. Mandatory fields for device, application, symptom and urgency. Triage falls from 5–10 to 3–6 minutes because there is nothing to reconstruct. Effect: the P90 of lead time from 4.9 to 0.22 working days, busy-day load from 129 % to 77 %. The cheapest lever in the field, and the only one that needs no staff.

Lever 2. A third person on the service desk. Also works clearly (0.38 days), but costs a headcount. The ratio between this lever and lever 1 is the actual statement of the table.

Lever 3. A knowledge base that absorbs 20 % of tickets before they arrive. Fewer tickets is always better, but it does not solve the constraint: triage still binds in 75 % of runs, and its busy-day load only falls from 129 % to 103 %. A fifth less volume lifts a step barely over the line, no more.

Lever 4. Resolve more tickets at first level. The most interesting null result. Raising first-contact resolution from 65 % to 75 % is the standard recommendation in support, and it works: working time per ticket falls from €28.82 to €25.34, because expensive second-level minutes are replaced by cheaper first-level ones. Lead time does not follow; it even ticks up to 5.0 days. The lever saves money, not time. Sell it as a turnaround measure and you are selling the wrong thing about an otherwise correct measure.

Compute the four separately and rank by effect per effort. Lever 1 is a form, lever 2 is a headcount, and in the model they are 0.16 days apart.

How 20,000 runs turn into a percentage per step is covered in Monte Carlo simulation for processes; why 85 % utilisation is already too much, in How to calculate a bottleneck.

After saving the baseline, changing one lever and running a second time, the comparison produces:

• Lead time before/after as P50 and P90. A service commitment is made against the P90, not against the median. That is exactly what separates an SLA statement from an average: the median says 0.08 days, and the commitment still breaks on every tenth day.
• Utilisation per step on the busy day and the new constraint after the measure. In this model it moves to first level under two of the four levers.
• Throughput as tickets per week against tickets arriving: 455 of 480 as shipped. The difference is the backlog the service desk rebuilds every week.
• Working-time cost per ticket and per year, from volumes, durations and fully loaded rates. At 24,000 cases every cent counts, and the template computes €28.82 per ticket.
• The assumption list with every estimated input, stated. The sentence "prioritisation and user wait states are not modelled" takes the sting out of the sharpest question before it is asked.

That is exported as two PDFs: a proposal for the decision maker and documentation for traceability, with your letterhead if you have set one.

One model, two questions. This page answers the arithmetic one: where the 75 % comes from, and why a fifth fewer tickets does not solve the constraint. The other question (what would you recommend, and what does a ticket left sitting cost) belongs to the method rather than the tool. It lives next door in the Flowrefy analysis archive, alongside the approach these templates came out of. One dataset, two questions, two audiences.

• Order handling runs from the order to the confirmation. The case with a shared role: two steps that look comfortable on their own are one person's afternoon.
• Quotation process is the case where lead time acts on revenue rather than on cost.
• Invoice approval is the volatility case: under capacity on average, over it at month end.
• Complaint handling puts the constraint outside the company, so the honest recommendation is not "automate".
• Employee onboarding has low volume and many participants, with one step that binds 86 % of runs.
• IT ticket is this page.

Every template opens from the welcome window via Browse templates. The first time round it is worth opening one before starting your own model. Otherwise people build too finely.