When the problem isn't the data — it's the person rebuilding it every Friday
Every Friday afternoon. Same task. Pull the data, stack the numbers, reassemble the report that was assembled the week before.
Not reviewing it — building it. From scratch. Again.
This was a senior person's time.
What was actually happening
The underlying data existed. It sat in whatever system it always sits in, updated, accurate, ready. The report wasn't hard to produce because the information was missing or unreliable. It was hard to produce because someone had to manually touch it every single week.
And when that someone had a bad week — got pulled into something else, was out sick, or just ran out of Friday — the founders got nothing. No summary. No numbers. No visibility into where receivables stood.
That's not a reporting problem. That's a dependency problem disguised as a reporting problem.
The three-number problem
The output wasn't complicated either. Receivables as three numbers across all months — not just the current one. An end-of-week summary, one line.
The kind of thing that takes a founder thirty seconds to read and gives them enough to know whether anything needs attention. But getting to those thirty seconds cost someone several hours every week, reliably, without exception, indefinitely.
That ratio — hours of production for seconds of consumption — is the exact shape of a task that shouldn't be manual.
Why this sits on the too-hard pile for so long
It's not that nobody noticed it was wasteful. It's that fixing it requires a specific kind of effort that's easy to defer.
The task itself is mechanical, so it doesn't feel urgent. It gets done every week, so it doesn't look broken. The person doing it absorbs the cost quietly, and that cost never shows up anywhere visible.
So it stays. Week after week. On someone's calendar, labeled something reasonable, while four hours of a senior person's time get fed into it.
What the fix actually looks like
A script that runs automatically and builds the report without anyone touching it. End of week: summary appears. Three numbers across all months. Done.
Two hours to build the script. Not two hours every week from that point forward — two hours once.
The data didn't change. The process didn't change. The only thing that changed is that a human stopped being the mechanism that connected the data to the output.
What changes after
The founder stops flying blind on weeks when the person who usually does this is stretched thin. The report shows up because it runs on a schedule, not because someone remembered to do it.
The person who was spending Friday afternoons on this gets those hours back. Not to do something more strategic — just to do literally anything else. That's enough.
No transformation. No initiative. A tedious mechanical task got automated, and the situation quietly improved for everyone involved.
The pattern worth recognizing
The report in this story isn't special. It's one instance of a pattern that shows up constantly: a recurring task, a fixed output, a human in the middle doing work that a script could do, and nobody fixing it because it's always been that way.
The diagnostic question is simple: is this output produced by someone pulling and assembling, or by something running automatically? If it's the former, and it happens more than once, that's worth looking at.
Not glamorous work. Exactly as glamorous as watching paint dry. But the Friday afternoon gets freed, the founder gets consistent visibility, and the problem — which was always mechanical — gets a mechanical solution.