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.
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 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.
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.
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.
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.
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.
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.
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:
Before and After: A Real Zoho Implementation at an IT Services Firm (article)
CRM for Professional Services: From Pipeline to Paid, in One System (article)
Professional services automation software combines the tools a services firm uses to sell, staff, deliver and bill work: pipeline, resource planning, project management, time tracking, expenses and invoicing, usually with reporting across all of them. The pitch is one record for an engagement from proposal to payment. What it includes varies by vendor; what it never includes is the definition of utilization, billable and capacity, which the buyer has to supply.
Hours counted as productive divided by hours counted as available, over a period. The formula is simple and every term in it is a choice. Productive can mean billed, billable or delivered. Available can mean paid hours, contracted hours or paid hours less leave and training. A firm that computes it three ways gets three numbers. Fix the definitions once, write them down, and the rate becomes comparable across teams and months.
It depends entirely on the definition. Firms commonly target somewhere between seventy and eighty-five percent billable against available hours for delivery staff, lower for leads who sell and manage. The benchmark matters less than the trend and the gaps: between hours sold and hours delivered, and between hours delivered and hours billed. A firm at seventy percent with those gaps understood is in better shape than one reporting eighty-five without knowing what it counts.
Connect first if the existing CRM, project tool and accounting system are each doing their job. The integration work to carry a proposal's hours into the project and the project's hours into invoicing is smaller than a platform migration, and it forces the definitions to be agreed. Buy a platform when the tools are genuinely failing, and then make the written definitions the acceptance test for the implementation. A platform configured to an undefined number reproduces the old argument.
Give it a home in the time system with the same discipline as client work: proposals, unpaid diagnosis, rework, internal tooling and training each get a code. The point is not to bill it but to make the denominator honest, so engagements that absorbed unlogged work stop looking profitable. Once it is logged, the firm can see how much senior time goes into proposals that do not close, which is usually the first surprise.
"Something isn't working." "We're outgrowing our tools." "We're afraid to make the wrong move." No-Risk Discovery is a short, practical conversation that gets you clarity before you commit to anything big. We'll tell you if we're a fit. If we're not, we'll tell you that too.
Say who you are and ask. A person replies within one business day.
