Reporting automation for a small business, honestly scoped

The weekly report is one of the most reliable pieces of waste in a small business. It is not waste because reporting is useless. It is waste because the numbers already exist, in systems that already hold them, and a person is being paid to move them by hand into a shape somebody can read.

The instinct is to buy a business intelligence platform. That is usually the wrong first move, for reasons we set out in automating manual reporting without buying a BI platform. This note is the practical layer underneath that argument: which part to automate, in what order, and where the free tooling genuinely runs out.

Find the four hours before you automate them

Ask the person who builds the report to narrate one week of it while you write down each step. You are looking for three categories, and the split is almost always lopsided.

In practice collection and reshaping account for the great majority of the elapsed time, and interpretation for almost all of the value. If you automate the first two and leave the third alone, the four hours becomes a genuine twenty minutes and the report gets better rather than worse, because the person has time to think about it.

The failure mode is automating interpretation. A system that emails a red arrow when revenue drops has not saved anyone anything, because somebody still has to find out why, and now they are starting from an alert instead of from the data.

Start in the spreadsheet, because it is not the problem yet

The spreadsheet gets blamed early and usually does not deserve it at this stage. Google Sheets holds up to 10 million cells or 18,278 columns per spreadsheet, and cells over 50,000 characters are dropped when converting from Excel. A small business weekly report is nowhere near any of those limits, and will not be for years.

So the first automation is not a rebuild. It is removing the manual collection step while leaving the spreadsheet in place. Scheduled pulls into a sheet, the reshaping written as formulas or a script rather than performed by hand, and the output rendered from that. This is unglamorous and it is where most of the four hours go.

Where the free tooling actually stops

Google Apps Script is the usual first tool for this and it is genuinely capable, but its published quotas decide the shape of what you can build, and they are worth reading before you design rather than after.

The documented limits also cap simultaneous executions at 30 per user, and the page states plainly that quotas are subject to reduction or change at any time without notice. That last sentence is the one to take seriously if you are planning to run a business process on it.

The six minute execution limit is the one that bites first. It is generous for pulling a few thousand rows and completely inadequate for anything that walks a paginated API across a year of history. The standard workaround is to break the job into chunks that each finish inside the limit and checkpoint their progress, which works, and which is also the moment you should notice you are now maintaining software.

The point where a real build is cheaper

Three signals, and you want at least two of them before spending money:

• The script has broken in a way nobody could diagnose, more than once, and the report went out late or wrong
• More than one person now depends on the output for a decision that costs money
• The reshaping logic has become something only its author understands, and its author has other work

One signal on its own is usually fixable in place. Two together mean the thing has quietly become production software without ever being treated as such, and the honest options are to treat it that way or to replace it. The migration question is covered in what to keep, move and drop when going from Excel to a web app, and the general readiness test in signs you need custom software.

Decide what goes on it before you build it

Automating a bad report produces a bad report faster. Most weekly reports carry numbers nobody has acted on in a year, kept because removing them feels like a loss.

The discipline is easier to borrow than to invent. BDG Labs sets out a workable version for the sales case in six numbers that earn a place on a B2B sales dashboard, and the test it applies generalises: a number stays only if somebody can name the decision it would change. Run that test before you automate, not after, because every number you keep is a data source you now have to maintain.

If the output is a live screen rather than a weekly document, the design constraints change again, and what real time actually means for a sales dashboard covers the part that usually gets promised and not delivered.

Honest limits

Two things this note does not do. It does not give you a cost, because the range depends almost entirely on how many sources you are joining and how badly they identify the same customer, and a figure quoted without that would be misleading.

It also assumes your underlying data is broadly correct. If two systems disagree about revenue, automation will not resolve that. It will publish the disagreement weekly, on schedule, with more authority than it had before. Reconcile first.