Automated report generation: which reports are worth it
Deciding what to automate: separating reports people act on from reports nobody opens, choosing cadence and audience, and retiring the ones that outlived their question.
Rebecca Pearson10 min read
On this page
Automating a report that nobody reads produces an unread report more reliably and at lower cost. That sounds like a joke and it is the most common outcome, because the decision about what to automate is usually skipped in favour of automating whatever currently takes the longest.
This page is about that decision: which reports earn automation, what separates one that changes behaviour from one that gets archived unopened, and how to choose cadence, format, and audience so the answer arrives when it can still be acted on. For how to build the pipeline once you know what you want, see the reporting workflow build.
What we'll cover
The test a report has to pass
One question settles most cases: what decision does this report inform, and who makes it?
A report that cannot answer that is a habit rather than a tool. It exists because someone asked for it during a project that finished, or because a previous manager liked seeing the numbers, and it has continued by inertia ever since. Automating it preserves the habit and removes the one useful signal that it had stopped being read, which was that producing it was annoying enough for somebody to eventually ask why.
Reports that pass the test share three characteristics.
Somebody acts differently depending on what it says. Not "finds it interesting" or "likes to be aware" but genuinely changes a decision: reallocating spend, chasing an account, escalating a fault, adjusting a forecast.
The action has a deadline that the report beats. A weekly report supporting a decision made on Mondays is useful. The same report arriving Tuesday is archaeology.
Somebody would notice if it stopped. The cleanest test available, and you can run it: stop sending it and see who asks. This feels reckless and takes about three weeks to produce a definitive answer.
Which reports are worth automating
Five categories reliably earn their build.
Exception reports. Anything listing what needs attention rather than what happened: overdue invoices, stalled deals, failed payments, stock below reorder level, tickets past their response time. These are the strongest candidates, because the output is a list of things to do and its value is obvious to whoever receives it.
Reconciliations. Comparing two systems that should agree and reporting where they do not. Payments against the ledger, inventory against the warehouse, CRM against billing. Tedious for a person, trivial for software, and the discrepancies found often pay for the whole thing.
Time-sensitive operational summaries. Yesterday's numbers on a desk before the morning meeting. The value is entirely in the timing, and it is the category where manual production fails most often, because it depends on somebody being available early.
Compliance and audit extracts. Required by somebody external, on a fixed schedule, in a fixed format. Nobody enjoys producing them, the format rarely changes, and the cost of being late is externally imposed.
Client-facing reports. Reports sent to customers, particularly where each needs the same treatment with different data. These have the additional benefit of being visibly more professional when generated consistently.
The pattern across all five is that the output is either a list of actions or a fixed obligation. Neither requires interpretation to be useful.
Which are not
Three categories look like good candidates and disappoint.
Exploratory analysis. Where the question changes each time, automation produces the answer to last month's question. What helps here is making the underlying data easy to query, rather than fixing one view of it in place.
Reports nobody has ever acted on. Covered above and worth repeating, because these are the ones most likely to be nominated, precisely because producing them is tedious and nobody defends them.
Anything requiring judgement to assemble. A board pack where someone decides each month which three things matter is not a reporting task wearing a disguise. The gathering underneath it automates well; the selection does not, and automating the gathering while leaving the judgement is the right split.
There is also a category worth pausing on: reports that exist because the underlying system is difficult to use. A weekly export that people rely on because nobody can find anything in the CRM is a symptom. Automating it is a reasonable short-term fix and it entrenches the actual problem, so it is worth at least naming.
Choosing the cadence
Cadence should follow from the decision the report supports, and it usually follows from habit instead.
Match the decision cycle. If stock is ordered on Thursdays, the stock report arrives Wednesday evening. Working backward from when the decision is made produces a different and better answer than picking a day that feels tidy.
Prefer triggers to schedules where you can. Much of what gets reported weekly is really a set of conditions: an account gone quiet, a margin below threshold, a job overdue. Sending it when the condition occurs beats a weekly summary in which it might be noticed. This converts a report into an alert, which is usually an improvement.
Resist daily by default. Daily reports are read for about two weeks and then filtered. Unless the decision is genuinely daily, weekly is read more carefully and acted on more often.
Match the frequency to the rate of change. Reporting monthly on something that moves hourly gives a misleading picture. Reporting hourly on something that moves quarterly is noise that trains people to ignore the channel.
Allow for the exception. A monthly report with a rule that escalates immediately if a number crosses a threshold gets both properties right, and is more useful than either alone.
Writing for the person receiving it
The distinction between a report that changes something and one that does not is mostly about presentation.
Lead with what changed. Not the full figures, which belong below, but the two or three things that are different from last time. This is the part people read, and frequently the only part.
Say what is outside expectations. A number without a reference point requires the reader to remember what normal looks like. Comparing against target, against last period, or against a baseline does that work for them.
Put the actions at the top, with owners. A report ending in a list of things to do, each with a name against it, is acted on. The same content presented as a table is filed.
Keep it short enough to read on a phone. Most of these are read on a phone between other things. A one-screen summary with detail available on request is read; a twelve-page attachment is not.
Link to the detail rather than including it. The people who want the full figures will click. Everyone else is spared them.
Say when there is nothing to report. A message confirming the checks ran and found nothing is what makes silence trustworthy. Without it, nobody can distinguish a quiet week from a broken report, and the whole thing loses credibility the first time it fails quietly.
Who should own a report
An automated report with no owner becomes furniture, and the ownership question is worth settling when it is built rather than when it breaks.
Someone owns the question. The person whose decision the report supports. They decide whether it is still needed, what belongs in it, and when it should stop. Without this, reports acquire columns from everyone who ever glanced at one and lose their shape.
Someone owns the mechanism. Whoever fixes it when a source system changes its format. Frequently a different person from the one above, and the failure mode when it is nobody is a report that quietly stops and is missed for a month.
The recipients are named, not a group. A report sent to a distribution list is read with precisely the diligence that implies. Named recipients, ideally with a named action each, are read.
A useful discipline is to put the owner's name on the report itself. It looks slightly odd for a week and it means that when somebody questions a figure, they know who to ask, and when the numbers look wrong, somebody feels responsible for finding out why.
Retiring reports
Reports accumulate and almost never get removed, so a working system needs a way of taking them out.
Review them annually. For each, ask who reads it and what they do differently as a result. The reports nobody can answer for are the ones to stop.
Stop rather than ask. Asking whether a report is still needed reliably produces yes, because agreeing is easier than thinking about it. Stopping it and waiting produces the real answer within a fortnight.
Track opens where the tool allows. Imperfect and directionally honest. A report nobody has opened in four months is a report nobody needs.
Treat a request to change a report as a chance to re-ask the question. When someone wants a column added, it is worth asking what decision the new column informs. Occasionally the answer reveals that a different report entirely is what they wanted.
The reason this matters more with automation than without is that manual reports have a natural death: eventually the person producing them leaves or objects. An automated report will continue indefinitely, correctly and pointlessly, until somebody deliberately stops it.
Once you have decided what is worth building, describing it is the next step rather than specifying it technically. On CodeWords you describe the report you want in plain language, including where the data comes from, when it should run, and who receives it. Cody, the automation builder, builds it, connects it to your systems, and deploys it. Automations connect to more than 3,000 integrations. The free plan covers light use, with Pro at $39 per month and Business at $100 per month as usage grows; details are on the pricing page.
Frequently asked questions
What should I automate first?
An exception report, because the output is a list of things needing attention and its value is immediately obvious to whoever receives it. Overdue invoices or stalled deals are the usual starting points, and both tend to pay for themselves quickly.
How do I tell whether a report is being read?
Stop sending it. This is the only reliable test, it takes about two weeks, and it is considerably more accurate than asking. Where the tooling reports opens, that is a useful supplement rather than a substitute.
Should reports go to email or a chat channel?
A channel for anything a team acts on together, since it is visible and discussable in place. Email for anything individual, formal, or external. Sending to both usually means it is read in neither.
How much detail belongs in an automated report?
Enough to act on, with the rest a click away. A summary with the two or three things that changed, an exception list with owners, and a link to the full data covers nearly every case.
Is it worth automating a monthly report?
Often yes, because monthly reports are the ones most likely to be produced under time pressure by someone who has forgotten the steps since last time. The infrequency that makes automation look unnecessary is exactly what makes the manual version error-prone.
What if the report needs commentary?
Automate the assembly and leave the commentary to a person. A draft arriving with the figures already in place, waiting for two paragraphs of interpretation, is a better arrangement than either extreme and is how most good reporting actually works.
Can a report be too automated?
Yes, in one specific way: when nobody looks at the underlying data any more. Automated reports show you the questions you decided to ask last year, and a periodic look at the raw numbers by a person who knows the business catches things no fixed report was built to notice.