What utilisation is supposed to mean
Utilisation rate, at its most useful, answers a simple question: out of the hours your team is paid for, how many produced billable client work?
The math is straightforward. If an engineer is paid for 40 hours a week and logs 32 hours against client projects, their utilisation is 32 / 40 = 80%. Average it across the team and you get the team utilisation rate.
That number is meant to be a health signal. If utilisation is too low, you're carrying excess capacity. If it's too high, you have no slack — which sounds great until you realise that slack is what absorbs sales work, internal initiatives, and the inevitable client crisis.
Why "78%" alone tells you almost nothing
Here's the trap. Two services teams can report the exact same 78% utilisation rate and be in completely different shapes:
- Team A. 78% utilised = 60% billable client work + 18% internal product R&D. Healthy split. The 22% non-billable is investment in next-quarter capability.
- Team B. 78% utilised = 50% billable + 14% "fixing things from last month" + 14% reactive client support not on retainer. Same 78%. Very different P&L story.
One team is making money and investing. The other is busy and bleeding. The headline number doesn't tell you which is which.
The split that matters
The useful version of utilisation breaks the percentage into four buckets:
- Billable. Hours logged against a client SOW, retainer, or ticket that's covered by a paid agreement. These hours generate revenue.
- Internal. Sales work, R&D, internal product, training, deliberate skill investment. Non-billable but strategic.
- Admin. Timesheets, status meetings, ops overhead. Non-billable, not strategic, ideally minimised.
- Slack. Time not accounted for — gaps, lulls, switching cost. Includes unlogged hours, which is its own problem.
When somebody asks "how's our utilisation?", the right answer is four numbers, not one.
What "good" actually looks like
Industry benchmarks for utilisation vary widely by team type. Roughly:
- Agencies / consultancies. Billable utilisation in the 60-75% range is healthy. Above 80% sustained, the team has no recovery slack and burns out fast. Below 55%, you're carrying too much bench.
- MSPs. Higher mix of billable support means 65-80% sustained is common. The risk is that "support hours" creep above what the retainer covers (see our piece on effort leakage).
- Internal services teams. "Billable" is replaced by "delivered against the team OKR". Targets are softer and more about throughput.
Important caveat — these are rules of thumb, not laws. If you're a 4-person studio with a single retainer, your numbers will look very different from a 40-person consultancy with 30 projects. Use the ranges as conversation starters, not as targets to hit.
The three follow-up questions
Once you have the four-bucket split, the actionable next step is three questions. Run these on your team's number monthly.
1. Is the billable bucket too high or too low?
Too low (under 55%): you're carrying capacity that's not generating revenue. Is the pipeline soft, or are people stuck on non-billable internal work that should be a smaller share? Either way, surface it.
Too high (above 80% sustained): you're running with no slack. The first client crisis will tip the team into overtime. Plan to either ease the load (push pipeline back), expand the team, or accept that burnout is now a delivery risk.
2. Is the admin bucket above 10%?
Admin time — status meetings, timesheets, ops paperwork — should be small. If your team is spending 12% of their week on admin, that's three full days a month per person, lost to overhead. Worth examining what could be automated, eliminated, or batched.
3. Is the slack bucket honest?
"Slack" is the dangerous bucket because it's often just unlogged time. If your team's slack is 20%, that's either real idle capacity (worth knowing) or a time-tracking discipline problem (also worth knowing — they're different actions). Sit with the team and figure out which one it is.
What kills utilisation accuracy
Three patterns to watch for, because they make the number lie to you:
- Untracked support. Engineers reply to client emails without logging time. Those hours don't show up in billable, so utilisation looks lower than it is — and the support cost looks invisible.
- "All projects on" rounding. An engineer assigned 30% to three projects logs exactly 12 hours / 12 hours / 16 hours to make the math clean. The real split was 18 / 8 / 14. The per-project margin numbers downstream are wrong.
- Capacity inflation. Counting freelancer days at full FTE-equivalent without netting out the part-time reality. A team of 8 "full" + 4 freelancers at 50% capacity is really 10 FTE, not 12. Your denominator matters.
What a healthy utilisation system looks like
Three properties:
- Live, not month-end. Utilisation is on a dashboard your delivery lead sees every Monday morning, not a report finance produces three weeks late.
- Per-person AND per-team. A team average of 75% can hide one person at 95% and one at 55%. Both are problems. Look at the distribution, not just the mean.
- Tied to capacity planning. Utilisation feeds the staffing decision. If utilisation has been 85% for two months, the next project either gets pushed or gets a hire.
BrioSync's capacity and utilisation views handle this split natively — billable hours roll up against bill rates, internal hours go into a separate bucket, target utilisation per role is configurable. The features page covers it. The Free plan lets you put your team in and see the four buckets without a card.
The honest bottom line
Utilisation isn't a single number — it's a profile. A team that hits "78% utilisation" without anyone asking what's underneath is fooling itself. The teams that get this right ask the four-bucket question every month, and use the answer to make the next staffing decision faster than the competition.