We simulated the same service desk week with seven ways of assigning tickets: 200 tickets and 5 technicians. One of them had the shortest wait in 46 of the 50 simulated weeks: sending the ticket to the specialist, with AI-based triage and an overflow when the specialist is swamped. The average wait dropped to 33 minutes, versus 94 with round robin. And the method many teams use without realizing it, the open queue, only works if someone watches the queue all the time.
This article uses the 200 fictitious tickets and Jev's real triage from the test Ticket triage without an LLM: we tested Jev.
The assignment methods
| Method | How it works | What usually goes wrong |
|---|---|---|
| Open queue | The ticket lands in a queue and a free technician picks it up | Depends on someone watching the queue; each person picks what they know how to do |
| Round robin | One each, in order | Ignores who is busy and who knows how to solve it |
| Least load | Goes to whoever has the least work in the queue | Ignores who knows how to solve it |
| Skills-based | Goes to the category specialist | Overloads whoever covers the heaviest categories; depends on triage |
| Skills-based with AI | The AI classifies the ticket when it is opened and sends it to the specialist | Same load problem; the AI sometimes gets it wrong |
| Skills-based + overflow | Specialist first; if they can only start after 1 hour, it goes to whoever is free | Needs a clear rule and technicians who cover the basics of other areas |
How we built the simulation
- Tickets: the 200 from the Jev test (25 from each category: network, access, ERP, email, printer, hardware, software and telephony), arriving at random over 5 working days of 8 hours.
- Technicians: 5, each a specialist in one or two categories. Ana covers network and hardware, the most time-consuming ones.
- Handling time: from 15 minutes (access) to 60 (ERP) for the specialist, with variation. A non-specialist takes 1.6 times longer.
- Triage: in skills-based assignment without AI, a dispatcher takes 20 minutes on average to classify. In skills-based assignment with AI, the category is the one Jev actually predicted in the test, with its 6 errors out of 200; each error costs 15 minutes of reassignment.
- Open queue: tested in two ways, with the technician checking the queue the moment they become free (ideal) and every 30 minutes (what usually happens).
- Repetition: 50 different weeks, with randomly drawn arrivals and durations. The figures below are the average.
The parameters and results are in the simulation spreadsheet, with a tab for estimating your team's hours under each method.
The result
| Method | Average wait until start | Worst 10% wait more than | Average resolution | Handled by a specialist | Work hours in the week | Workload gap between technicians |
|---|---|---|---|---|---|---|
| Open queue, checking the queue every 30 min | 77 min | 164 min | 122 min | 73% | 150 h | 5.8 h |
| Round robin | 94 min | 240 min | 151 min | 19% | 191 h | 8.5 h |
| Least load | 54 min | 120 min | 111 min | 20% | 190 h | 3.7 h |
| Skills-based (human triage) | 85 min | 241 min | 124 min | 100% | 128 h | 28.7 h |
| Skills-based with AI triage | 66 min | 221 min | 104 min | 100% | 128 h | 28.7 h |
| Skills-based with AI + overflow | 33 min | 78 min | 79 min | 69% | 154 h | 8.9 h |
| Ideal open queue (checks the queue immediately) | 20 min | 55 min | 72 min | 41% | 174 h | 5.3 h |
What the numbers show
1. Round robin and least load look fair, but they are costly. Both balance the volume, but only 1 in 5 tickets lands with someone who knows how to solve it. Result: the team works 190 hours to deliver what the skills-based model delivers in 128. That is almost 50% more effort for the same 200 tickets.
2. Pure skills-based assignment saves hours and creates a bottleneck. Every ticket goes to the specialist, but the load becomes lopsided: in the first simulated week, Ana (network and hardware) worked 43 hours and Eva (telephony), 12. The worst 10% of tickets wait more than 4 hours. Anyone who opened a network ticket on a Thursday afternoon feels it.
3. AI triage removes the wait for the dispatcher. Even with 6 errors out of 200, classifying at opening cut the average wait from 85 to 66 minutes. The gain is not about intelligence: it comes from not waiting for someone to read the ticket.
4. Overflow is what solves the bottleneck. When the specialist can only start after an hour, the ticket goes to whoever is free. The team works a little more (154 h), but the average wait drops to 33 minutes and the load is balanced. It was the best method in 46 of the 50 weeks (not counting the ideal open queue, which nobody can sustain).
5. The open queue is great on paper and poor in real life. If each technician checks the queue the moment they finish a ticket, it is the best of all (20 minutes of wait). If they check every 30 minutes, the wait nearly quadruples (77 minutes). And the open queue does not show who is holding what.
How to do this in GLPI
What GLPI does on its own: each category can have a Technician in charge and a Group in charge. In the entity, Automatic assignment of tickets, changes and problems uses this information ("Based on the category then the item", or the other way around). This is pure skills-based assignment: always the same person or the same group, without looking at the load.
Business rules let you assign by category, location, requester or a word in the title, but also without looking at who is free. See business rules in GLPI.
To balance the load within the group, the free Smart Assign module distributes each category's tickets among the group's technicians, by round robin or by least load.
For triage at opening, the category has to arrive correct without anyone reading the ticket: automatic categorization and mandatory fields and the AI triage test.
The design we recommend: 1. One group per specialty, with the category pointing to the group in charge. 2. Least-load distribution within the group. 3. Triage at opening (a well-built form or AI), so the ticket is created with the right category from the start. 4. A support group that receives whatever exceeds the specialist's wait limit. Agree on the limit with the team and track it through the time to first response.
Before changing your method
- Measure the wait until first response by category. If one category waits much longer than the others, the bottleneck is one of skills, not volume.
- Look at the workload gap between technicians over the month. More than 2 times between the most and the least loaded is a sign of skills-based assignment without overflow.
- Review the categories before automating. In the Jev test, the errors common to all three models came from categories with two possible readings.
- Put your own numbers into the spreadsheet (tickets per category, handling time, technicians and how much longer a non-specialist takes) and see how many hours each method consumes.
NexTool simulation on October 3, 2026: 200 fictitious tickets, 5 fictitious technicians, 50 randomly drawn weeks, AI triage using Jev's real answers in the October 1, 2026 test. It is a model: the numbers are meant for comparing methods, not for predicting your queue. Full parameters in the spreadsheet.
