GuidesContact
Guides

The report somebody rebuilds every Monday

CloudBuilder AI · 2 min read

Someone exports three files, pastes them into a spreadsheet, refreshes the formulas, and emails a PDF to the same six people. It happens every week, it takes most of a morning, and it is the highest automatable share of any task in our calculator, at 70 to 95 percent.

Why the share is so high

Because almost every step is deterministic. The same reports, pulled from the same places, joined the same way, formatted the same way, sent to the same list, on the same schedule. There is no judgement anywhere in the assembly, which is precisely why a person doing it is such a poor use of a morning. When the source systems have APIs, the whole chain from pull to delivery can run without anybody touching it, which is where the 95 percent end of the range comes from.

What does not automate

Reading the report. The five percent to thirty percent that stays is the part where somebody looks at the numbers, notices that one region is down, and does something about it. Automating the assembly does not automate the noticing, and it is worth being blunt about that, because a report nobody reads is not made valuable by arriving faster. If the honest answer is that nobody acts on the report, the better project is deleting it, and an audit should be willing to say so.

The failure mode is silence

A person assembling a report notices when a source file is missing, because they go looking for it. An automation does not, unless it was built to. The single most important feature of an automated report is what it does when a source is unavailable or returns nothing: it must say so loudly, in the report itself and to whoever owns it, rather than quietly sending a report with a zero in it. A wrong number that looks confident is worse than no number, and this is the most common way automated reporting goes wrong in practice.

Where the time actually goes

Most of the recurring effort in these tasks is not the assembly, it is the waiting and the switching: exporting from one system, waiting for it, opening the next, remembering the filter that has to be set each time. This is why the hours people report for a weekly report are usually higher than the task sounds. The calculator asks for hours a week rather than minutes of work, deliberately, because that is the number that reflects what the morning actually costs.

What to check before automating one

Who reads it and what they do differently because of it. Whether every source has an API or an exportable, stable format. And whether the report definition has changed in the last year, because a definition that keeps moving needs a person until it settles. A report that is stable, widely read and acted on is close to the best automation candidate a small business has.

Related

Common questions

Can it send the report straight to customers?
Yes, and it is worth being careful about. Anything going outside the business should fail loudly rather than send an incomplete report, and most businesses want a person confirming the first few sends.
What if the numbers come out of a system with no API?
A scheduled export to a fixed location is usually enough, if the format is stable. If the only way to get the numbers is a person clicking through a screen, the automatable share drops sharply.
Is it worth automating a monthly report?
Often not. A report that takes two hours once a month is about 24 hours a year, which the calculator will usually price below the point where a build pays for itself. Weekly is where these become worth doing.