If you asked a partner or a department head how many hours their team spends on manual reporting each week, most would guess low. Not because they are wrong on purpose — because the time is spread across dozens of small tasks that never individually look like “the project”, so nobody adds them up.

01. The arithmetic, done simply

Take three numbers you already know, roughly: how many fee-earning people touch a given recurring deliverable, how many hours each loses weekly to the parts of it that are not analysis or judgement, and what an hour of their time is worth to you. Multiply by 52 weeks and you have an annual estimate.

It is not precise, and it is not meant to be. It is meant to answer one question: is this worth measuring properly? The calculator on our homepage walks through the same arithmetic if you want to try your own numbers before reading further.

02. Why it is easy to miss

Three reasons this cost hides in plain sight:

  • It is distributed, not concentrated. Ten minutes here, twenty there — copying a figure, chasing a file, reformatting a table. No single instance looks worth fixing.
  • It looks like normal work. A senior person assembling a report does not look idle or inefficient. They look busy. The fact that half of what they are doing is structure a system could produce is invisible from the outside.
  • Nobody owns the number. It is not a line item on anyone’s P&L. It is an opportunity cost — the analysis that did not happen, the client work that got pushed a day, and the margin that quietly narrowed.

03. What actually counts as leakage

Not all manual work is leakage. Judgement, client conversations, and the analysis a client is actually paying for are not the problem — they are the point. The leakage is specifically the work around that: retyping the same fact into a second system, hunting for a source document someone else filed, assembling a report structure that is identical every month before getting to the part that needed a real decision.

04. From an estimate to a measurement

A rough number is useful for a decision — is this worth looking at closely — but it is not precise enough to build anything against. That is a deliberate limitation, not an oversight: any number built on assumptions should say so, and should not be the basis for a fixed price.

The next step, if the estimate is large enough to matter, is a Workflow Diagnostic: one workflow mapped end to end, the actual hours quantified against your own data and assumptions agreed with you in advance, and a baseline established that any build is later measured against. It is a paid, standalone piece of work with its own output — a decision document you own, whether or not you build with us afterwards. Full scope and pricing is on Pricing.

05. What to do with the estimate

If the number your team lands on is small, that is useful information too — it tells you this particular workflow is not the one to prioritise. If it is large, the next right step is not a build. It is a measured baseline, so that whatever gets fixed can be judged against something real rather than a feeling that things should be faster.

Bring the one workflow that is costing you the most, and we will tell you honestly whether it is worth a Diagnostic — discuss one workflow →