Your PSA tells you the cost to resolve tickets. What it often fails to show is what each ticket costs before anyone touches it, and that gap is where margin starts to leak.
Most MSP MDs look at their cost per ticket and see a staff cost based on engineer time, hourly rate and monthly ticket volume. That is a reasonable starting point, but it usually only counts the visible resolution work. It starts from the moment a technician opens a ticket and stops when the ticket is closed. It rarely shows the reading, assessing, routing, chasing, re-routing and duplicated thinking that happens before the ticket reaches the right person.
That work is ticket triage. In many MSPs, it happens in the gaps between proper work. That work sits in queues, side conversations, Slack messages, Teams channels, service desk judgement and senior engineer memory. Your PSA may record the ticket but it doesn’t always record the cost of getting the ticket into a usable state.
For an MSP running on tight service desk margins, that matters.
MSP ticket triage cost is the hidden labour cost created before a ticket reaches the right engineer. It includes reading the ticket, understanding the client context, assessing priority, checking SLA impact, routing the work, correcting misroutes and recovering focus after interruptions.
Your true cost per ticket is therefore higher than the PSA figure if the PSA only measures resolution labour. The real number includes resolution labour, triage labour, interruption cost, misrouting cost and the opportunity cost of work that did not happen while someone was sorting the queue.
The PSA cost per ticket is lower than the true cost per ticket because it captures delivery once a ticket is being worked on, not the labour consumed before that point begins. If triage labour never appears in a margin report, the MD has no lever to pull. The measurement step creates the lever.
The PSA figure can therefore look reasonable while the desk is absorbing real cost before any technical work starts.
When a ticket arrives, the PSA records the event. That does not mean the service desk has started useful work.
In a manual triage environment, the ticket sits in a queue until someone reviews it. They read the request, decide what it is, judge urgency, think about the client, check who is available and assign the ticket. Only then does the receiving engineer open it, read the same context again, form their own view and begin technical work.
The sorting step is often treated as admin because it doesn’t look like delivery. In reality, good triage requires technical judgement and operational memory. The person assigning the ticket needs to understand the client’s environment, the agreed SLA, ticket history, current engineer workload, possible related issues and the likely resolver group.
Whether the desk runs on Autotask, ConnectWise or HaloPSA, the reporting structure is built around logged resolution time, not pre-assignment labour. This creates a reporting bias. Resolution work looks measurable, while pre-assignment work disappears into the rhythm of the desk.
Manual ticket triage can feel manageable when the service desk is small. There are fewer clients, fewer engineers, fewer tools and fewer assignment paths. The person sorting the queue knows most of the context by memory.
As the MSP grows, the same process becomes less reliable.
More clients means more environments to understand. More engineers means more routing options. More service tiers means more SLA variation. More tools means more context switching. More recurring issues means more need to recognise patterns across tickets.
As your MSP grows, ticket volume is the visible pressure. The less visible pressure is complexity. More clients, more environments, more SLA tiers and more possible resolver paths mean each routing decision carries more risk of being wrong. Most PSA reporting does not separate those two pressures, which means the service manager sees queue depth but not routing difficulty.
The ticket may look like a single unit of work, but routing it correctly means choosing from a growing number of possible resolver paths. That is the operational reality most cost-per-ticket reports do not reflect.
That problem gets harder as the desk becomes more mature. ACM KDD research into IT ticket routing frames ticket routing as the challenge of getting a ticket to the right resolver group when that resolver is not known at the start. That sounds obvious, but it matters. The first person who reads the ticket is making a decision with incomplete information.
In MSP terms, every extra client, queue, contract type and engineer skillset increases the number of ways that decision can go wrong. A mature service desk may have better people, better tooling and better processes, yet still lose more time to routing decisions than it did when the team was smaller. The routing decision involves more variables, not more effort from the same person. That distinction matters when justifying investment in tooling.
The visible cost of triage is the time spent reading and assigning tickets. The hidden cost is the interruption caused by doing it.
An engineer may be diagnosing a Microsoft 365 issue, reviewing a firewall fault, preparing a change or working through a tricky escalation. When that engineer stops to sort a queue, they don’t lose only the two or three minutes spent on the new ticket, they lose the thread of the task they were doing.
That loss is not just a service desk anecdote. Research by Gloria Mark and colleagues on interruption recovery time in knowledge work found that interruptions increased the time needed to complete cognitive tasks and produced more errors in skill-based tasks.
That matters because ticket sorting often interrupts exactly the kind of work where concentration has commercial value. Engineers may need to re-read notes, repeat checks, rebuild context or slow down because their attention has been split.
In a busy service desk, these interruptions are not occasional. They are part of the normal operating pattern. One interruption is easy to dismiss, several interruptions across one shift are not. Across a whole team, repeated pre-assignment interruptions reduce throughput, increase queue depth and make the desk feel permanently stretched. This is why manual sorting creates a cost structure that is hard to escape: as ticket volume grows, the pre-assignment workload grows with it; as the queue gets busier, interruptions increase; as interruptions increase, engineers resolve fewer tickets in the same day; and the only obvious way to maintain service levels is to add people. Automation changes that relationship because the first sorting decision no longer depends on someone stopping what they are doing.
ITJobsWatch currently lists the median UK First Line Support salary at around £27,500 per year. For a broader IT Technician role, the median is closer to £29,000.
That salary figure is useful because it gives the calculation a floor, but it is not the full cost of employing the person.
Once employer National Insurance, pension contributions, software, equipment, management time, office costs, training and general overhead are included, the real hourly cost is materially higher than the salary-based figure.
Every hour spent on ticket classification rather than technical delivery has a cost. That cost may not be charged to a client. It may not appear as waste in a margin report. It may simply show up as a desk that needs more headcount than expected, engineers staying late, tickets waiting longer or service managers spending too much of the day keeping the queue moving.
The accounting treatment of pre-assignment labour is the reason MSP ticket triage cost remains hidden in most reporting. Because triage happens between tasks, inside queue reviews and through informal conversation, it is absorbed into general service desk time rather than attributed to individual tickets. The work is real and the hours are consumed, but they do not appear as a discrete line in any margin report. That invisibility is the problem. When the cost has no name in the reporting, it cannot be targeted for reduction. Senior engineers spending time on classification work, service managers manually nudging the queue and L1 staff interrupting L2 colleagues all represent cost the business is paying without measuring. The gap between what the PSA records and what the desk actually spends is where MSP margin erodes without a clear cause appearing on any report.
The £7 ticket is a useful mental model because it makes the hidden cost easier to discuss, but it is not a fixed benchmark.
The more useful starting point is the definition of the metric itself. HDI defines cost per ticket as total monthly service desk operating expense divided by monthly ticket volume. That matters because the metric is meant to capture the operating cost of the desk, not just the minutes an engineer logs after opening a ticket.
The benchmark range is also wider than most MSPs track in their own reporting. Service desk cost per ticket spans a wide range, from around $6 to more than $40. That spread makes sense when you look at how different desks operate. A ticket handled through clean routing, good knowledge and limited rework costs less than a ticket that bounces between people before anyone fixes it.
The true cost per ticket depends on how the desk works: ticket volume, triage time, engineer cost, routing accuracy, SLA pressure and how often technical staff are interrupted to manage the queue all feed into the final number.
For some MSPs, the loaded cost of low-level ticket handling may sit below £7. For others, especially those with manual sorting, repeated reassignments and senior people managing the queue, it may already be higher.
The trap is believing that the PSA number gives the whole answer.
A ticket can look cheap because the engineer only logged a few minutes of resolution time. That same ticket may have already consumed several minutes of queue review, a routing decision, a second read by the assigned engineer and part of the SLA window. That is not shown cleanly in most reports. It still hits the business.
| Cost component | Visible in PSA? | Typical source |
|---|---|---|
| Resolution labour | Yes | Engineer time logs |
| Triage labour | Rarely | Queue management, assignment |
| Misrouting cost | Sometimes | Reassignment records |
| Interruption cost | No | Context switching, recovery time |
| SLA delay before assignment | No | Time-to-assign vs time-to-respond gap |
There is one operational consequence of manual triage that makes the cost easier to feel, and that is SLA burn.
The SLA clock starts when the ticket arrives. It doesn’t wait for someone to read the ticket, for it to be assigned, or for the right engineer to open it.
In a manual triage model, tickets that arrive during peak periods can sit unassigned while the desk catches up. The usual windows are familiar to most MSPs: the post-login rush, the pre-lunch spike, the end-of-day cluster and the Monday morning backlog. That waiting time is consumed by the SLA before useful work begins. The client sees no activity, the PSA records only that the ticket exists. The service desk has already started spending SLA time it cannot recover.
This is why the pre-assignment gap is not only an internal efficiency issue, it affects response time, breach risk, client confidence and the perceived quality of the service.
The calculation does not need to be complicated. The hardest part is being honest about the work that currently goes unmeasured. Follow these steps to build an accurate picture:
The useful formula is:
True cost per ticket = (resolution labour + triage labour + misrouting cost + interruption cost) / monthly ticket volume
In plain terms, take every cost component the desk absorbs before and during resolution, sum them, and divide by the number of tickets that month. The resulting figure is the true cost per ticket, and it will be higher than the PSA resolution figure for any desk where pre-assignment work is not tracked.
In our modelling of a typical 800-ticket desk, the direct triage labour figure is consistently higher than service managers expect when they have previously assumed the sorting work was negligible. The worked example below shows why.
Take an MSP handling 800 tickets per month.
If each ticket takes four minutes to read, classify and route, that creates 3,200 minutes of pre-assignment time per month, just over 53 hours.
If the loaded cost of the person doing that work is £20 per hour, direct triage labour is more than £1,000 per month before you count misroutes, repeated reading, SLA delay or context switching.
At 1,500 tickets per month, the same process consumes around 100 hours.
This is the point at which manual sorting starts to damage the economics of the desk. The work feels small at ticket level, then becomes material at monthly volume.
Manual sorting ties cost to volume. More tickets means more human classification, more interruptions and more handoffs.
Automated triage changes the first step of the workflow. Tickets can be classified, prioritised and routed at arrival, using rules, client context, historic patterns and the content of the request.
Automated triage reduces the time engineers spend before work starts. Technical judgement, exceptions and client escalations stay with the team.
A good automated triage layer routes tickets to the right place before the first human touch, protects SLA time during peak periods and gives engineers cleaner context when they open the work. Engineers open tickets with context already in place and spend the working day on technical resolution rather than queue management. Over time it should also make the cost of pre-assignment sorting visible, which is the part most desks currently cannot see.
The best version of this is a controlled workflow where the MSP can review, adjust and improve routing logic over time, not a black box that throws tickets around the business.
DaemonLayer handles the classification and routing step so the first sort happens before an engineer needs to look at the queue. That means the pre-assignment labour cost drops, SLA time is protected and engineers open tickets with context already in place rather than rebuilding it from scratch each time.
If a quarter of the working day is absorbed by queue management, interruptions and repeated ticket interpretation, the desk will need more headcount before the ticket volume alone justifies it.
That does not always show up as idle time. In fact, the opposite is usually true. The team looks busy, everyone is active, and the queue is moving.
Skilled engineers spend time on classification and assignment work that doesn’t require their level of technical knowledge once the pattern is understood. This is why engineer utilisation can look acceptable at a headline level while the business still feels under capacity. Automated ticket routing improves the equation by removing friction before work starts, giving engineers more time for technical work, giving clients faster movement and giving the MSP more capacity from the same team.
For a related breakdown, read How Do Ticket Triage Savings Fund Two New Engineers, or for more on how DaemonLayer automates PSA ticket routing, see our ticket triage feature.
Measurement should come before any change to the triage process, because otherwise the business case will be built on a feeling rather than an operating number. Establishing the true MSP ticket triage cost in concrete figures is what makes the automation case credible. Without that number, any investment in tooling is hard to justify.
Before automating triage, start with the time between ticket arrival and first assignment. Then compare that with the time between arrival and first meaningful response. The gap between those two points will usually show how much time is being lost before delivery begins.
You should also review reassignment rate, the clients and categories with the highest routing uncertainty, peak time queue depth and the number of tickets touched by senior engineers before someone else resolves them.
SLA breaches deserve the same treatment. For each breach, ask how much of the SLA window was lost before the right person started work. In some cases, the technical resolution may have been quick, while the pre-assignment delay caused most of the damage.
This gives the MD and service manager a better conversation. Instead of debating whether the team feels busy, they can discuss where time is being consumed before delivery begins. Once those numbers are in place, the automation case follows directly from them.
Your PSA is still useful, but it has a defined scope. It is strong at recording service delivery once the ticket is being worked. It is weaker at exposing the cost of preparing the ticket for that work, especially when the classification step happens through queue scanning, side conversations, manual judgement and informal reassignment.
The PSA can tell you what happened to the ticket, but it may not tell you how much effort went into deciding what should happen next.
That distinction matters for MSPs because margin loss often begins before visible resolution work starts. By the time the ticket appears as active technical work in Autotask, ConnectWise or HaloPSA, part of the cost has already been absorbed by the desk. If triage labour never appears in a margin report, the MD has no lever to pull.
For many MSPs, the £7 ticket is not a benchmark they are beating. It is a floor they may already be sitting on, and in some cases they may already be above it without realising.
The better question is whether the PSA cost per ticket includes the cost of getting the ticket to the right person in the first place. If it does not, the true MSP ticket triage cost is higher than the report suggests.
DaemonLayer is built to make that cost visible and then remove as much of it as possible. It helps MSPs classify, prioritise and route tickets so engineers spend the working day on technical resolution rather than queue management.
At 800 tickets per month, the triage labour cost alone typically exceeds £1,000 per month. That is the number to start with. Once it is visible, the business case for changing the process writes itself.
MSP ticket triage cost is the labour, delay and productivity cost created before a ticket reaches the right engineer. It includes reading, classification, priority setting, routing, reassignments, SLA delay and interruption cost. Most PSA platforms do not surface this figure because they record resolution time, not pre-assignment activity. The true cost per ticket is higher than the PSA figure for any desk where sorting and routing happen manually.
PSA platforms such as Autotask, ConnectWise and HaloPSA are built to track resolution activity. Pre-assignment labour, the time spent reading, classifying and routing tickets before they reach an engineer, does not appear in most PSA time logs. That gap means the PSA understates the true cost. The measurement step described above is what closes the gap.
Add resolution labour, triage labour, misrouting cost and interruption cost. Then divide the total by monthly ticket volume. In plain terms: sum every cost the desk absorbs before and during resolution, then divide by ticket count. This gives a more accurate view of cost per ticket than engineer resolution time alone.
Manual sorting reduces margin because skilled people spend time classifying work instead of resolving it. It also creates repeated reading, misroutes, context switching and SLA delay. Each of those adds cost that does not appear as a named line in the margin report, which means it accumulates without a clear trigger to address it.
Based on the worked example in this post, an MSP handling 800 tickets per month and spending four minutes per ticket on pre-assignment work absorbs more than £1,000 per month in direct triage labour at a £20 per hour loaded rate. Automated triage removes most of that pre-assignment time. At 1,500 tickets per month, the same model produces around £2,000 per month in recoverable triage labour. Actual savings depend on current misrouting rate, interruption frequency and the loaded cost of the staff doing the sorting.
Measure time from ticket arrival to first assignment, time to first meaningful response, average pre-assignment time, reassignment rate, misrouting rate, SLA time lost before assignment and how often engineers are interrupted to manage the queue.
Kevin Wright
Co-founder & CEO, DaemonLayer
Kevin built and exited an IT services business before working in M&A and then as Operations Director at an MSP. He holds an MBA from the University of Manchester. He founded DaemonLayer to fix the coordination problems he watched erode engineer capacity firsthand.
Connect on LinkedIn →