Utilisation is probably the most misused metric in professional services. Not because it is a bad metric, but because it gets used alone: someone looks at the percentage, compares it with someone else’s, and draws a conclusion about performance that the number does not support.
Used well it says something very specific and very useful: how much real capacity you have, and how much is left.
What it actually measures
utilisation = billable hours / available hoursAvailable hours are the period’s hours minus holidays, public days and absences. That is, the time the person was actually working.
Billable hours are those logged to a client project. Note: billable, not billed. If the project is fixed price and has overrun, those hours still count as billable for utilisation even though they translate into no extra revenue.
That distinction is why utilisation must never be read alone. A team at 85% burning hours on a project that blew its budget has excellent utilisation and a terrible result. Which is why it always travels alongside project profitability.
The healthy range, by role
There is no single number, and presenting one as if there were is the first mistake:
| Role | Reasonable range | Why |
|---|---|---|
| Delivery (dev, design, QA) | 70-80% | The rest goes to meetings, training and internal improvement |
| Tech lead | 55-70% | Part of the job is unblocking others, and that does not get logged |
| Project management | 50-65% | Coordination, client, follow-up |
| Pre-sales and commercial | 10-30% | Their value is precisely in the non-billable |
| Leadership | 0-20% | If it is high, nobody is leading |
What matters is not the absolute number but whether the role sits in its range. A senior at 95% is not a hero: they are a bottleneck who is neither training anyone nor improving anything, and who will come apart at the first incident.
Why 100% is an alarm, not a target
This is the most expensive misunderstanding. An agency with its team at 100% utilisation:
- Cannot absorb the unexpected. A sick day, a production incident or a client pulling a deadline forward forces something to give. And what gives is always whatever has nobody shouting about it: quality.
- Is not investing in itself. No training, no process improvement, no internal tooling, no documentation. Future capacity degrades while current capacity looks brilliant.
- Is doing no pre-sales. If nobody spends hours on proposals and estimates, the pipeline three months out will be empty. Today’s 100% utilisation is next quarter’s revenue trough.
- Is burning people out. And churn in a business whose asset is the team’s knowledge is one of the most expensive losses there is.
The goal is not to maximise utilisation. It is to keep it in the healthy range and stable.
The most common measurement errors
Measuring individuals instead of teams
The moment individual utilisation becomes a personal target, people learn to log in whatever way makes it look good. The data corrupts and you lose the only thing that made it useful.
Measure teams and trends. Use individual data to spot workload imbalance, never to appraise someone.
Confusing low utilisation with low productivity
Someone at 55% might be spending the rest mentoring two juniors, fixing the deployment pipeline and shipping three proposals. They are probably the highest-impact person in the company that month, and the metric punishes them.
Not subtracting absences properly
If you divide by calendar hours instead of available hours, someone who took half a week off shows up with artificially low utilisation. At that point nobody trusts the dashboard.
Looking at it at month end
At closure it only explains what happened. In real time it lets you decide: if you see the team sustained at 90% for three weeks, you know you need to hire or turn work down before something breaks.
How to track it without going mad
Utilisation is only reliable if time logging is reliable, and logging is only reliable if it is cheap. That is where the whole practical difficulty sits.
What works:
- Daily logging, not weekly. Reconstructing on Monday what you did last Wednesday produces fiction, not data.
- Few categories. Project and task type. The more granular, the less it gets filled in — and the worse.
- Visible to whoever logs. If people see their own number and understand what it is for, they cooperate. If only leadership sees it, it reads as surveillance and you get whatever makes it add up.
- Explain the real target. That the healthy range is 70-80% and that 100% is a problem, not a medal. It completely changes how people log.
From metric to decision
Utilisation is useful when it answers concrete questions:
- Can we take this project on, or do we have to say no?
- Do we hire now or hold out another quarter?
- Why is this team drowning and that one not?
- How much real capacity do we have next month?
None of those is answered by a percentage at year end. They are answered by a current number crossed with each project’s profitability.
That is what we do with Tenki: logging that stays out of the way, utilisation and team analytics in real time, and a link to finances so the percentage translates into money. We built it for our own agency before selling it to anyone.