Monday morning. Somebody exports three files, opens a spreadsheet, does the joining by hand, fixes the two rows that never match, and produces the numbers you look at.
They have done this every Monday for two years. It takes most of the morning. Nobody has ever put it on a job description and nobody could stop doing it without you noticing immediately.
The gap nobody names
Your systems hold enormous amounts of data. Your accounting package knows what was invoiced. Your scheduler knows what was booked. Your job system knows what got done. Your inbox knows what customers asked for.
None of them hold the answer, because the answer needs two or three of them at once. What did we actually earn per job last month, by type? Which customers are slower to pay than they used to be? How many jobs went out without being invoiced?
Every one of those questions is a joining problem across systems that were never introduced. So a person becomes the join. Every recurring report in your business is somebody doing by hand what the systems could not do to each other.
Four costs, and the last one is the real one
The morning. Obvious, measurable, and the smallest of the four. Count the hours and multiply.
The staleness. A report built weekly is a picture of last week. You are steering on a delay, and the delay is invisible because the numbers still look current when you read them.
The single point of failure. One person knows which files, which columns, which two rows always need fixing, and which number is wrong in a way you have all agreed to ignore. When they are away, the report does not happen or happens badly.
The questions nobody asks. This is the expensive one. When getting an answer costs half a day of someone’s time, you stop asking the interesting questions. You only ask for the standard report — so the one-off question that would have shown you something useful never gets asked at all. The cost of a manual report is not the morning. It is every question that was not worth the morning.
The dangerous version: when the spreadsheet becomes the system
There is a stage past this that is worth naming, because it creeps up.
The report starts as a summary. Then someone adds a column that is not in any system — a status, a note, a manual correction. Then somebody else starts reading that column to make decisions. Now the spreadsheet is not reporting on your business. It is holding part of your business, and it lives in one file, on one machine, with no record of who changed what.
If any recurring spreadsheet in your business contains information that exists nowhere else, that is not a reporting problem any more. That is an operational system with no backup and no audit trail, and it deserves to be treated as one.
What a Report Engine does differently
The shape: Monday’s numbers, already assembled, nobody built them.
Instead of a person gathering from three systems on a schedule, the engine keeps the join up to date continuously. The report is not produced on Monday — it is simply always current, and Monday is just when you happen to look.
Two things follow that are worth more than the saved morning. Asking a new question becomes cheap, so you start asking them. And the numbers stop depending on one person’s undocumented process, which means they survive holidays and resignations.
What I learned watching systems get monitored properly
At Pantheon I worked on platform operations for sites that could not go down, which meant a lot of time around monitoring — the discipline of knowing what is true right now rather than what was true when somebody last looked.
Here is the transferable part, and it took me longer to internalise than it should have. The value of monitoring was almost never the dashboard. It was that questions became cheap. When finding out costs nothing, you check things you would never have bothered to check, and that is where the useful surprises came from — not from the metric somebody thought to put on the wall.
Your Monday report is the opposite arrangement. It answers one fixed question expensively, which guarantees you only ever ask that one.
Find out what yours costs
- List every recurring report somebody produces by hand — weekly, monthly, for you, for the accountant, for a customer.
- For each, write who makes it and how long it takes. Ask them; do not estimate on their behalf.
- Ask each one what breaks in their process — the rows that never match, the manual fix, the column that lives nowhere else. Write those down. That list is the actual specification.
- Count the systems each report joins. One system is a reporting feature you may already own. Three systems is a joining problem.
- Ask yourself the honest one: what would you check weekly if checking cost nothing? If you have a list, you have already found the value.
If your reports come out of one system, take ten minutes, and nobody would miss anything if they stopped — leave this alone entirely. Not every business has this problem.
What to do next
List your recurring manual reports and ask each person what breaks in their process. That list of quiet fixes is the specification, and it is the thing nobody ever writes down.
Then ask what you would check weekly if checking cost nothing. If the dashboard you already own is not being opened, the reason is worth understanding.
If you want the whole picture instead of one workflow: tell us what’s still manual. You get a map of every point where your business stops and waits for a person, what that costs you in hours, and which of those an engine would take over first. Free, yours to keep, and useful even if you never hire us — including on the days the honest answer is that you should not build anything yet.
Common questions
Couldn’t we fix this with a reporting tool bolted onto our systems?
Sometimes, and it is the cheaper thing to try first. If your data is mostly in one system and it has decent reporting, use that. Reporting tools struggle in exactly the place manual reports exist — where the join is across systems, and where the joining requires business rules like which job counts as which type. The rules are the hard part, not the chart.
Our data is messy. Doesn’t that have to be fixed first?
It has to be faced, not necessarily fixed first, and the distinction saves a lot of stalled projects. The manual report already handles the mess — someone fixes the same two rows every week. Those fixes are the rules, and writing them down is most of the work. What you should refuse is a system that silently guesses; the mess should be visible and flagged, not smoothed over.
How do we know the automated numbers are right?
Run both for a while and compare, which is the only answer that should satisfy you. Keep the manual report going alongside the automated one for a few cycles and check them against each other. Where they disagree, one of them is wrong and finding out which teaches you something either way — frequently that the manual one had a quiet error nobody had caught.
What if the person who builds the report is worried about their job?
That is a reasonable worry and worth answering directly rather than reassuring vaguely. The honest framing is that the half-day is being removed, not the person — and the interesting work, which is interpreting the numbers and acting on them, is what they have never had time for. If the real answer is that the role was only the report, say so honestly rather than discovering it later.