Playbook
Revenue per billable person: where a consultancy's money leaks
One number that reconciles from the board pack down to a single team, a target set from your own cost base, and the four places the money leaks.
The methodRevenue per billable person, and the four leaks
This playbook uses one number, revenue per billable person, to show where a consultancy's money leaks. It sets a target from your own cost base rather than a borrowed benchmark, sizes the gap between what your billable capacity should have earned and what it did, and breaks that gap into four leaks you can name and fix. It is for founders and leadership teams of consultancies, agencies and engineering services firms of roughly ten to two hundred people, and for anyone managing delivery on utilisation (utilization) who suspects utilisation is not the whole story. The same arithmetic runs at company, division, team and deal level, so one number reconciles from the board pack down to a single team.
Utilisation is the number most services firms manage on, and it measures how busy people are, not what the business earned from them. A team can be fully booked on discounted work, on a fixed-price job that has overrun, on a customer who pays late, or on internal work that was coded billable because it made the report look better. Utilisation reports all of that as good news. Revenue per employee, the other common measure, divides by everyone including the people who never bill, and gets compared to industry benchmarks that describe somebody else's cost base and somebody else's mix. Neither number tells you where your money went.
Revenue per billable person is revenue divided by the billable people in a unit over a period. That is the whole definition, and its plainness is the point: the same sum works for the company, a division, a team and a single engagement, so every level can be checked against the one above it. The playbook sets the target from your own numbers: the fully loaded cost of a billable person, the overhead they carry, the margin the business needs, and the days a year they can realistically bill. That target is what your capacity should have earned. The gap between it and what the capacity did earn is then decomposed into the four leaks. Rate, where the day was sold below the card. Utilisation, where the day was not sold at all. Realisation, where the day was sold and worked but not invoiced in full. Collection, where it was invoiced and not paid on time. The playbook is careful about one confusion that runs both ways: a margin on salary cost is not company gross margin, and mistaking one for the other flatters some teams and condemns others.
There are no industry benchmarks in it and no suggested figure for what revenue per billable person should be. The target comes from your cost base, or it is somebody else's target. It does not replace utilisation, which remains one of the four leaks and still needs measuring every month. And it is not a time-tracking method; it works from what you already have in the ledger and the staff list, which is why it can be run on last year's numbers this afternoon.
In the business that became DevOpsGroup, a services company helping other businesses build and run software, we planned in billable heads. I knew the utilisation figure and the margin every month. There was a period when utilisation was as high as it had ever been and gross margin was as low as it had ever been, and the two reports sat next to each other in the same pack without explaining one another. Working the leaks was how I made them agree. Some of the gap was rate: days sold below the card to keep a team busy. Some was realisation: fixed-price work that took longer than the price allowed. Some was that a whole team was fully utilised on a line of business that earned a thin margin by design. Utilisation had told me that everyone was busy. Revenue per billable person told me what busy was worth, team by team, and which teams the company figure had been hiding.
The playbook is in development, alongside an interactive revenue per billable person model and a worksheet for running the arithmetic at company, division, team and deal level. Joining the waitlist means you hear when it is ready, and tells me who is waiting. Nothing is for sale yet and there is no date.
What you will get
Who it is for
Questions
- How do you size the rate leak?
- Take every day sold in the period, multiply by the card rate for the grade that worked it, and subtract what was actually invoiced per day. The difference is the rate leak: days sold below the card. The playbook runs the sum from the ledger and the staff list, team by team, so you can see which teams discounted to stay busy.
- What is realisation?
- The share of days worked that were invoiced in full. A fixed-price job that overran, a write-off to keep a customer happy, or hours coded billable and never billed all show as work done and revenue not earned. Realisation sits between utilisation and collection in the four leaks, and it is the one utilisation reports hide best.
- Why reconcile from the board pack down?
- Because the same sum works at every level. Revenue divided by billable people at company level must equal the weighted result of the same sum for each division, team and deal. When it does not, something is being counted differently somewhere, and the playbook treats that as the first finding rather than a rounding error.
- What are the four leaks?
- Rate (days sold below the card), utilisation (days not sold), realisation (days worked but not fully invoiced) and collection (days invoiced but not paid on time). Together they account for the gap between what your billable capacity should have earned and what it did.