The ticket waiting in second line for a password
A manufacturer measures its service desk. The median is two hours, one in four tickets takes longer than a day. The reason is a permission, not expertise.
Second line sees only 41 % of tickets and is the binding step in almost nine out of ten of them, at 93 % utilisation. Around 1,800 of those escalations a year fail not on first line's skill, but on first line's permissions.
0.2working days
In 8 of 10 cases between 0.1 and 2.0 days.
Erstqualifizierung
In 41 of 100 simulated runs this step was the hold-up.
€29,000
Per year. Estimated between €25,000 and €32,000.
€26,000
Per year. Estimated between €23,000 and €29,000.
IT incident handling
- Industry
- Manufacturer with in-house IT
- Size
- 310 Mitarbeitende
- Cases per year
- 7,400
- Fully loaded rate
- €64 / h
- Simulated runs
- 120,000
- Date
- July 2026
The service desk is considered slow, systems administration considered overloaded, and both sides cite the same statistics. On the table: a quote for a new ticketing system with a knowledge base and automation.
7,400 tickets a year, five steps, two roles, a €64 fully loaded rate. Before the decision, the process is modelled and simulated over 120,000 runs, with queues, user queries and escalations.
Six steps, four roles, one measurable path
The process modelled in FlowVisual. ↯ marks a media break — the point where data is retyped from one system into the next.
| Step | Role | System | Duration P10–P90 | Bottleneck |
|---|---|---|---|---|
| 01Ticket erfassen | Servicedesk | Ticketsystem | 2–6 min | 2 % |
| 02ErstqualifizierungBottleneck | Servicedesk | Ticketsystem | 6–24 min | 41 % |
| 03Rückfrage an den Anwender | Servicedesk | E-Mail↯ | 3–12 min | 17 % |
| 04Bearbeitung zweiter Level | Systemadministration | Admin-Konsolen↯ | 5–95 min | 36 % |
| 05Abschluss & Dokumentation | Servicedesk | Ticketsystem | 3–8 min | 4 % |
120,000 runs, one clear answer
Every chart below shows before against after. Values are labelled directly — the colour is a second signal, never the only one.
158
Tickets/Woche
42 %
0.1–2.0working days
Erstqualifizierung — 41 %
Start with the spread, because here it is the real story: the median is 0.2 working days, the P90 is 2.0. A factor of ten. Measure the service desk by its average and you measure the three quarters that were never a problem.
The highest bottleneck probability, at 41 %, belongs to initial triage. That is largely a volume effect: it touches every ticket. Second line touches only 41 % of tickets and still reaches 36 %. Among the tickets it actually sees, it is the binding step in almost nine out of ten cases.
The number behind that is its utilisation: 93 %. In that region the queue no longer grows in step with the load, it grows faster. Escalated tickets take a median of 1.1 days and a P90 of 2.8.
Around 1,775 escalations a year concern the same five routine actions: password, licence, VPN profile, group membership, printer. First line knows how. First line is not allowed to.
First line gets the permissions. Nothing else.
The ticketing system on offer would have answered a different question. The measurement says the bottleneck is not software, it is a permissions matrix.
The intervention would be one change: for five clearly defined routine actions, first line gets the rights it currently has to ask for. The work does not disappear, it moves one desk forward. Triage takes longer as a result, 6 to 29 minutes in the model instead of 6 to 24.
Nothing else would be touched: no new software, no extra headcount, no change to the user-query loop.
Median lead time down 54 %
- How long it takes
- 0.2 → 0.1 working days
- Throughput
- 158 → 200
- Days over capacity
- 42 % → 5 %
- Saving per year
- €26,000
The escalation rate would fall from 41 % to 17 %, second line utilisation from 93 % to 74 %. Because the queue reacts disproportionately in that region, the P90 of escalated tickets would fall from 2.8 to 1.4 days. A fifth off the load, half off the wait.
Across all tickets the median would be 0.1 instead of 0.2 working days, the P90 1.0 instead of 2.0. The share of tickets taking longer than a day would fall from 26 % to 10 %.
The bottleneck moves to where the work was added. Triage would rise from 41 % to 59 % bottleneck probability. Service desk utilisation would stay at 69 %. It absorbs the extra work because the handovers and most of the status chasing fall away at the same time.
Second line would get roughly 1.2 hours a day back. Whether that turns into project progress or just a quieter queue is not something the measurement decides.
What this analysis cannot tell you
Every measurement has limits. A measurement that hides them is advertising.
- 01
This is a sample analysis. Process, roles and timings are constructed, not collected at a client.
- 02
User downtime is not priced in euros. It is probably the largest item and the least evidenced one. Include it and any automation looks good. The figures shown contain only double handling and the status chasing caused by the wait.
- 03
Widening permissions is a security decision. This analysis calculates the time gained, not the risk taken. Five defined routine actions are not the same thing as an administrator account.
- 04
“Days over capacity” here means: on that share of working days, at least one role ends the day with more work outstanding than it can clear in a day.
- 05
“Throughput” is the ceiling the scarcest role allows, not the actual volume. That is 148 tickets a week, so before the change, 94 % of the ceiling.
- 06
The simulation serves every role in order of arrival. Priority handling is not modelled; a service desk with working triage priorities would have a better P90 and the same finding.
- 07
P10–P90 is not a worst case. In 10 % of cases it takes longer than the P90 value.
Your process will look different.
This analysis is a sample. Your numbers are not. With FlowVisual you model your own process and get the same evaluation — on your machine, with your values.