The Utilization You Cannot See: Why a Services Firm Cannot Tell Which Work Is Profitable.
Updated: 2 days ago
Ask the leadership team of a consultancy, an agency or an engineering firm what their utilization is and you will get a number, usually to one decimal place. Ask which of last quarter's engagements made money and the answer is a pause, then a story about the one that obviously did not.
We run a services firm, so we say this with some sympathy. The firm knows its revenue, its payroll and its utilization, and still cannot say which work was profitable. That is not a reporting gap. It is a definition gap, and no professional services automation software closes it, because software computes what you define, and the number has never been defined once.
The enemy is a number with three denominators.
Utilization looks like one number. In most firms it is three, and they disagree.
Sales computes it from what was sold: hours in the proposal, at the rate in the proposal, divided by the capacity the team was assumed to have when the deal was priced. Delivery computes it from what was planned: hours assigned in the project plan, divided by the hours people were available that week. Finance computes it from what was billed: hours that reached an invoice, divided by the hours people were paid for.
Each of those is a reasonable number. Each lives in a different system, the CRM, the project tool and the books. Each has a different numerator and a different denominator, and the difference between them is exactly the information that would tell you which work made money. Sold minus planned is the scope you gave away in the estimate. Planned minus billed is the work you did and never invoiced. Nobody owns either gap, because each department's number is correct in its own system.
Then there is the fourth number, which nobody computes at all.
The work that is not logged anywhere.
The utilization you cannot see is the work that never became a time entry. The proposal that took three senior days and did not close. The account call that turned into an hour of unpaid diagnosis. The rework after a handoff went wrong, coded to the project because there was nowhere else to put it. The internal tooling somebody built on a Friday afternoon.
Every firm has this work. Very few log it, because the time system was set up to bill clients, not to describe the firm. So the denominator in every utilization calculation is smaller than the truth, the number looks better than it is, and the engagements that consumed the unlogged work look more profitable than they were.
This is why the firm cannot tell which work is profitable. The profitable-looking engagements are often the ones that quietly absorbed the work nobody wrote down.
Why the tool is not the missing piece.
The pitch for PSA software is that it puts pipeline, projects, time and invoicing in one place, so utilization becomes one number. The pitch is true as far as it goes. What it leaves out is that the tool needs to be told what utilization means, and if three departments walk in with three definitions, the tool will faithfully implement whichever one the administrator picked, and the other two departments will keep their spreadsheets.
We have watched this happen. A firm buys the platform, migrates the time entries, and six months later has a fourth utilization number alongside the original three. The disagreement was automated, not resolved.
The missing piece is upstream of any tool. It is a decision, made once and written down, with four parts.
One definition of capacity. Which hours count as available, for whom, and who decides when someone is on leave, on the bench or on internal work.
One definition of billable. Which hours count as delivered to a client, whether or not they were invoiced, and how fixed-fee work is converted into hours.
One home for the work that is not client work. A place to log proposals, unpaid diagnosis, rework and internal build, so the denominator is honest and the cost lands where it was caused.
One record of truth per object. The proposal owns the sold hours. The project owns the planned and delivered hours. The books own the billed hours. Each writes its own and reads the others, and none of them re-keys another's number.
Once those four are settled, utilization is one calculation with inputs from three systems, and the gaps between sold, delivered and billed become the management report instead of an argument.
What you get when the number is defined and connected.
You can say which engagements made money, because the delivered hours include the unlogged work and the billed hours are reconciled to them.
You can price the next proposal from the last one's actuals, rather than from the rate card and hope.
You can see the scope you give away, as the gap between sold and delivered, by client and by practice.
You can tell the difference between a busy team and a profitable one, which is the distinction that decides whether to hire.
We have written before about connecting CRM, projects and books for a services firm. This post is the step before it. Connection makes one number possible. Definition makes it true.
When not to do this.
If the firm is eight people and the founder can name every engagement's margin from memory, do not build a system to tell you what you know. Write the four definitions down anyway, because the memory does not scale and the next hire will need them.
If you are about to buy a PSA platform because the current tools are genuinely broken, buy it, but agree the four definitions before the implementation starts, and make them the acceptance test. A platform configured to an undefined number is the fourth spreadsheet.
If your work is almost entirely fixed-fee and the firm does not track time at all, the question is different: it is delivered scope against sold scope, not hours. The same discipline applies, with a different unit.
How we know this.
We are a services firm, and the three-denominator problem is one we have had ourselves, which is why the version of it we build for clients starts with the definitions rather than the configuration. The systems work is business systems integration with Zoho Books as the record of billed hours, and the ongoing part, keeping the definitions true as the firm changes, is what managed technical operations exists for. The commercial terms are the same as always: discovery is no-risk, so you pay only if you proceed, and the estimate is guaranteed, so if the reconciliation is uglier than we scoped, the difference is ours.
Where this goes.
Utilization is the first number a services firm discovers it cannot define. Margin by engagement, revenue per head and pipeline coverage have the same shape, each computed in a different system with a different denominator, each looking like a fact. A firm that has defined utilization once has learned how to define the rest, and the systems that hold them start to agree.
That is what a services business run as a connected system looks like: not more dashboards, but fewer arguments about which number is real. If you want to know how far apart your three utilization numbers are, a no-risk discovery is the place to start. We will pull the three and show you the gaps, before anyone talks about software.
Find out what one connected Zoho system would change in the way you run.
In a no-risk discovery we look at your CRM, finance and operations systems and who owns each part, and show what a connected system would do differently. You pay only if you proceed. Or see how we approach it.
More on the same problem:
Comments