How to Measure Technician Utilisation Correctly
Push utilisation too hard and you burn people out; ignore it and you bleed margin. Here's how to measure it correctly and read it without doing damage.

How to Measure Technician Utilisation Correctly
Utilisation is one of the most useful metrics on a service desk and one of the most dangerous. Measured and used well, it tells you whether your capacity matches your workload and where your margin is leaking. Measured or used badly, it burns out your best people, encourages dishonest timekeeping, and points you at exactly the wrong decisions. The difference is entirely in how you handle it.
What utilisation is actually for
Start with the purpose, because it's often lost. Utilisation is meant to answer a simple business question: how much of the time you're paying for is going into productive, ideally billable, work? It's a bridge between the service desk and the P&L. A technician who's fully occupied but whose time isn't being captured or billed is an invisible margin leak, and utilisation is the metric that surfaces it.
That's the legitimate use - a capacity and profitability signal for the business. The trouble starts when it gets repurposed as a performance stick to beat individuals with, because that changes the incentives in destructive ways.
The measurement mistakes
Before you can use utilisation well, you have to measure it honestly, and there are four common ways it goes wrong.
The first is measuring against the wrong denominator. Utilisation is productive hours over available hours - and "available" is not the same as "hours in the day." Holiday, training, admin, internal work and genuine slack all belong in the calculation. Measure against raw clock hours and every technician looks under-utilised, and you'll chase a number that was never achievable.
The second is confusing busy with billable. A technician can be flat out all week on internal projects, rework and non-billable tasks and show high activity but low billable utilisation. Those are different numbers that answer different questions, and blurring them hides the margin problem you were trying to find.
The third is chasing an impossible target. Nobody bills 100% of their time, and setting that as the goal doesn't produce 100% utilisation - it produces padded time entries and burnout. Realistic targets depend on role, but they always leave room for the non-billable work that keeps a desk functioning.
The fourth is reading one number without context. A single technician's utilisation means little on its own. High compared to what? The team, the target, last quarter? Utilisation is only interpretable relative to a sensible benchmark and the rest of the desk.
Reading the number without doing damage
Even measured correctly, utilisation has to be read with care, because it's a two-sided signal. Consistently high utilisation isn't automatically good news - it can mean a technician is overloaded and heading for burnout, and a whole desk running hot means you have no slack to absorb a spike or a departure. Consistently low utilisation isn't automatically bad - it can mean overcapacity you should address, but it can also mean time that isn't being captured, or someone carrying important non-billable load.
So utilisation should never be looked at alone. Next to capacity, it tells you whether the desk is correctly sized. Next to aged tickets and workload, it tells you whether high utilisation is healthy productivity or someone drowning. Next to billable split, it tells you whether the issue is too little work or work that isn't being billed. The number is a prompt to look closer, not a verdict on a person.
Measuring it properly
All of this depends on getting the raw measurement right and seeing it in context - which is more than a simple time-entry export gives you. Autotask captures the time entries, the billable flags and the ticket and project work behind them, but turning that into an honest utilisation figure, set against realistic available hours and next to capacity and workload, is a calculation that has to be done consistently to mean anything.
That's what Canopy's performance and capacity views are built to do: read your Autotask time and ticket data and present utilisation and billable percentage alongside reactive-hour capacity and per-technician load, so you're seeing whether the desk is correctly sized and whether a high number means productive or overloaded - not just a raw percentage with no context. Autotask records where every hour went; Canopy is what turns that into a number you can actually make decisions with. Used this way, utilisation stops being a stick and becomes what it was meant to be: an honest read on whether your capacity and your margin are where they should be.
Stop guessing. See it in Canopy.
Canopy turns your Autotask data into the answers this article is about — technician scorecards, backlog, CSAT, pipeline and MRR, in one place.
Measure utilisation and capacity together