Breakdown: Automating the Weekly Report, from Data Sources to Final Draft

A familiar ending: the team spends two weeks automating the weekly report — data pulled automatically, AI drafting the text, delivery into the group chat at nine sharp every Monday. Three weeks later, the people who actually opened it can be counted on one hand. The pipeline was built correctly. What got automated was a report nobody read in the first place.

Which is why this breakdown runs in reverse. The title says "from data sources to final draft"; the building order starts at the draft and works backwards.

Step one is not connecting data — it is answering "who reads this"

Before anything is built, the report must survive one sentence: who, in what setting, uses it to decide what. Is it the owner setting priorities in Monday's stand-up, a department head watching project risk, or several teams syncing progress? Different answers change the content, the granularity and the delivery time. If the sentence cannot be completed, stop — automating a report with no decision behind it just makes the waste more punctual.

The deliverable here is humble: write the sentence down and confirm it with the actual reader. A report that cannot be confirmed is usually institutional habit, not a real need. For deciding which routine work deserves automation first, Digitise Repetitive Work First offers a framework — and the weekly report is its textbook case.

Work backwards from the draft: every number needs an output contract

Every number and every table in the final draft must be able to answer "where do I come from". Trace each one back and you get the data source list. For every source, three things need agreeing with whoever maintains it:

• Where and in what format: which report in which system, which tab of which shared file, what the fields look like — better than discovering a renamed column on extraction day.
• Who maintains it: whom to call when the data stops updating. That person should know they are depended on, not find out afterwards.
• When it is ready: updated by Friday close of business, or eight on Monday morning? The automated pull must run after that point, with buffer.

Starting before these three are settled is the number-one cause of rework in such projects. The failure boundary also needs writing in advance: if the deadline passes and the data has not been updated, the draft should plainly mark the item as missing — an honest gap beats last week's numbers dressed up as this week's. For mapping the whole flow before building, see What to Map Before You Automate.

Make metric definitions explicit: three departments, three "new customers"

The same word is rarely the same number across departments. "New customers": sales counts signed contracts, marketing counts captured leads, support counts activated accounts. "Response time": some clock it from the customer's message, others from ticket assignment. In the manual era, the person compiling the report reconciled these quietly in their head. Once automated, that mental ledger must become written text — otherwise the machine applies a definition it does not even know is wrong, week after week.

The deliverable is a definitions table: one row per metric — definition, scope, source, owner. Definitions may change, but a change needs an effective date, noted in that week's report. Otherwise two adjacent weeks stop being comparable, and the report's credibility resets to zero overnight.

AI's division of labour: touch the language, never the numbers

AI's responsibilities in this pipeline need sharp edges. What it should do: condense several sources into a narrative of what happened this week; flag anomalies — metrics that jumped against the previous period, missing data, trends moving the same direction for weeks; compress long detail into a conclusion-first structure. What it must not do: fill in missing figures, polish any number, or round the ugly ones into a nicer story. Every figure in the draft comes verbatim from its source — AI arranges the language, it does not manufacture facts.

This boundary is not distrust of AI; it is a promise to the reader, who must be able to assume the numbers were never processed. Break that assumption once and every future report gets re-checked line by line — at which point the automation has paid for nothing.

Template, schedule, and the new human role

Use a fixed template: a conclusions summary on top, detail in blocks below, anomalies marked separately. A stable format lets readers build a scanning habit and finish the relevant parts in five minutes. Delivery is scheduled — after the slowest data source is ready, before the meeting the report serves.

Then comes the most important role change in the chain: the person responsible stops being the report's writer and becomes its reviewer. Before it goes out: do any numbers look wrong? Did the AI's summary distort anything? Then add the one line no machine can write — "this week's dip is the expected fall-off after the promotion ended." That judgment was always the most valuable sentence in the report; it used to drown in three hours of table-wrangling. Now it is the only work left to the human, and the work most worth doing well.

The failure signal: if nobody reads it, the topic was wrong

When the automated report goes unopened for weeks and unquoted in meetings, do not start by polishing the layout. Return to step one: the decision this report supposedly supports may not exist. The correct move is to kill it, or fold it into a report people do read — not to keep optimising something nobody needs. Automation exists to free people from routine work; it owes no report immortality.