Note
Reading Utilisation Without Turning It Into Surveillance
Utilisation is one of the most useful numbers a field service operation can track. It tells you what proportion of available technician-days are assigned to work during a given period. For a contractor with fifteen technicians and eight to ten projects a month, a utilisation rate sitting at 55% means roughly half of all available capacity is unassigned.
That is a useful number to know. The problem is that the moment a business owner starts tracking it, the technicians notice. And once they notice, the question they ask themselves is: is this going to be used against me?
The answer to that question determines whether the number functions as a management tool or as something that drives the team to update the board dishonestly.
What does utilisation actually measure?
Utilisation, in a field service context, is the ratio of assigned technician-days to available technician-days over a period. If a team of ten technicians works twenty days in a month, the available pool is 200 technician-days. If 130 of those days carry a job assignment on the schedule, utilisation is 65%.
The number does not measure effort. A technician on a full-day factory job might spend six hours on skilled electrical work and two hours waiting for a site manager to unlock a cabinet. The utilisation figure records that day as assigned. It does not know about the wait, the drive time, or what actually happened on site.
What it measures is scheduling efficiency: how well the business matched its available people to available work. The denominator is the same technician-day count you schedule and commit against. A gap in utilisation is almost always a scheduling gap first, and a workforce problem second, if at all.
Why does tracking utilisation make technicians uncomfortable?
Most technicians have worked somewhere that tracked their time and then used the data to question them. The utilisation figure appears on a screen, someone looks at it, and the next conversation is: “Why weren’t you on a job on Tuesday?”
That framing is surveillance. The technician is being asked to account for time the business failed to fill.
The discomfort is rational. If a job is cancelled without a system update, the technician loses a day and the figure drops. If the owner looks at the number without scheduling context, the technician appears underperforming when the coordination failed.
Any system that makes technicians feel responsible for low utilisation they did not cause will meet resistance. The board stops being updated honestly, and the number becomes noise.
How do you read the number at team level instead of individual level?
The most useful approach is to start at the team picture and work backward, not forward from individual records.
The question is: across the full month, what percentage of available technician-days carried a job assignment? If that number is below what the business considers healthy, the follow-up is: where were the unassigned days, and was there work available that could have filled them?
Team-level utilisation points at the scheduling system, not the people. If 40% of days had no assignment, the first question is whether the jobs existed but were not dispatched, or whether the work genuinely had not arrived yet. Both are operational questions, not questions about any specific technician’s conduct.
Individual-level data matters, but for a different purpose and at a different time. If one technician’s assigned days are consistently lower over multiple months, that may reflect skills that do not match the current project mix, a scheduling preference the coordinator does not know about, or a capability gap worth addressing. That is a conversation worth having separately, with full context, not as a reaction to a single number.
What does low utilisation usually mean in a factory installation business?
In a contractor operation handling commercial solar or industrial LED projects, low utilisation most often reflects one of three things.
- Unassigned work exists but was not dispatched. The jobs are on the schedule but no technician is named against them. This is a coordination failure, not a workforce failure. The fix is in the dispatch process, not in the team.
- Work arrived late in the month. Factory project cycles tend to cluster approvals and kickoffs at certain points in the calendar. A month where most projects started in the final two weeks will show low utilisation for the first two weeks regardless of how the team performed.
- The project pipeline is ahead of the schedule. Work is confirmed but not yet broken into job orders. Utilisation is low because the scheduling step has not happened, not because the people are unavailable.
None of these are problems a technician can solve. They are visible in the scheduling data when you look at the right level: what was assigned, when, and whether work existed to assign.
Take a concrete example. Twelve technicians, eight projects in a month: 240 available technician-days, 140 assigned. Utilisation: 58%. Before drawing any conclusion, the coordinator checks: were all eight Job Orders in the system by the first working week? If four were not entered until the second week, the gap in those first days is a setup problem, not a people problem. The number looks the same either way, but the conversation it leads to is completely different.
FAQ
What should utilisation look like for a healthy contractor at this scale?
There is no universal number, but a contractor with a stable pipeline running eight to ten jobs a month across ten to twenty-five technicians should expect 65 to 75% of available technician-days assigned in a typical month. Below 60% over multiple months suggests a persistent dispatch gap. Above 85% sustained may mean the business carries no buffer for urgent or reactive work.
When does it make sense to look at individual numbers?
After reviewing the team picture and finding a pattern that individual data can help explain. If one technician’s assigned days are consistently lower and the team’s overall utilisation is healthy, individual data helps you understand why. If the team picture already shows a month-wide gap, individual data is unlikely to add clarity and is more likely to produce an unfair conversation.
How do you show the team this is not surveillance?
By making the team-level number visible and explaining what drives it. If the coordinator reviews utilisation in a monthly check-in with the framing “we were at 58% in July and fourteen of those unassigned days were in the first two weeks before projects kicked off,” the team understands it as a scheduling observation. The same number delivered as “only 58%: who was sitting idle?” produces the opposite reaction. The number is neutral. The framing is not.
Where this sits in a well-run field operation
A well-structured field service board gives whoever owns the screen day to day a view of unassigned days alongside the jobs in the schedule. That is enough to see whether a utilisation gap is a dispatch failure or a work-availability problem, without opening individual technician records. The team-level question resolves first. Individual questions come later, if at all.
The program overview at /program/ explains how the owner’s screen is structured, and you can book a call at /schedule-a-call/ to walk through it with numbers from your own operation.