A ticket arrives, goes to the wrong team, gets reassigned, goes to the wrong team again, and reaches the right person on the third attempt. Everybody involved did their job. The ticket was resolved. The dashboard is green.
That ticket cost several times what it should have, and almost no service desk reports it.
Why it stays invisible
Dashboards count tickets, and a reassigned ticket is still one ticket. It appears once in the volume, once in the resolution rate, and its extra cost appears nowhere.
Where reassignment is reported at all it is usually a count: "1,240 reassignments this quarter". A count is not a cost, and nobody has ever acted on one.
Counting it
Every ticket system records assignment history. Take ninety days of it.
Count the reassignments. Per ticket, how many times did it move between teams? Ignore moves within a team: that is normal work allocation.
Price one. A reassignment is not free even when it takes a minute to press the button. Somebody read the ticket, decided it was not theirs, and wrote a note. Somebody in the next team read it again from nothing. Fifteen to twenty minutes of attention across both is a fair estimate for anything that is not obviously misrouted.
Multiply by your engineer hourly cost. Salary plus employer costs over working hours.
Show the arithmetic beside the answer. Anybody who is going to act on this figure will first want to argue with it, and they should be able to.
Worked example
3,000 tickets a quarter, averaging 0.7 reassignments each:
- 2,100 reassignments
- at 18 minutes of combined attention: 630 hours
- at £38 an hour: £23,940 a quarter, about £96,000 a year
Now the useful part: reassignments are never spread evenly. Group them by the category the ticket arrived as. Two or three categories will account for most of it, and each one is a routing rule, a form field or a training gap with a price on it.
The part people miss
Re-triage is a symptom, not a cause. A ticket that bounces three times is usually telling you one of four things:
- The person raising it cannot describe what is wrong, so the form is asking the wrong question.
- Two teams both could own it and neither wants to, which is a service boundary that has never been settled.
- The routing rules were written for an organisation that has since been reorganised.
- The first team has no way to resolve it and no authority to say so.
Only the third is fixed by better routing. The other three are fixed by changing something about the service, which is why a reassignment report alone rarely changes anything.
Internal IT without penalty clauses
Most internal IT has no contractual SLAs, and that is usually taken to mean inefficiency is free. It is not. Every reassignment burns an engineer's time, and that time has a rate, whether or not anybody is invoiced for it.
Setting that rate is the whole move. Once friction has a price, it competes for attention with everything else that has a price, and it stops being an operational grumble.
This is the thinking behind the [ITSM Financial Command Center](https://itsmdashboard.dev), which does this arithmetic against a live queue and prints it beside the figure so it can be checked rather than trusted.
This is part of what we do under Software development. See the services, or tell us what is not working.