Skip to content
FlowioLab

Automate the weekly report nobody wants to build

The report itself is rarely the value; the decision it supports is. Moving collection and the first draft out of the calendar leaves only the judgement for a person, which is the part most people enjoy anyway.

By FlowioLabPublished 21 Sept 20263 min read

Key takeaways

  • A weekly report can be reduced to three questions: what moved, what broke, what changes next week.
  • Collection belongs in a scheduled job with a fixed schema, not in a manual tour of dashboards.
  • Automation is well suited to drafting descriptions of change; the interpretation stays with a person.

Automating a weekly report means moving collection and the first draft out of the working week, so that only the decision is left for a person. Done well, it replaces a few hours of copy-paste with a short review. Done badly, it produces a longer document nobody trusts, which is why the first step is not technical.

Step one: decide what the report is for

Many recurring reports exist because they have always existed. They are assembled from several dashboards and read closely by nobody, and that is rarely anyone’s fault. Before automating anything, it helps to name the decision the report is supposed to support.

A weekly report can usually answer exactly three questions. What moved? What broke? What changes next week? Content that does not serve one of those three is decoration, and removing it is what turns a nine-section document into a three-section one.

Step two: collect once, automatically

Collection should not require anyone to open a dashboard. A scheduled job pulls the handful of metrics that matter into one table with a fixed schema: date, channel, sessions, signups, revenue. Five columns, one row per day, appended weekly.

  • Keep the schema fixed. Changing columns weekly destroys comparability.
  • Store raw numbers rather than screenshots. Text can be compared, images cannot.
  • Let the automation fail loudly. A silent empty row is worse than a visible error, and much harder to forgive later.

Step three: let a model write the first draft

Once the numbers sit in one table, a language model can handle the tedious part: describing the deltas in plain language and flagging anything that moved more than a set threshold. Giving it the current table plus last week’s numbers and asking for one short paragraph per question produces a usable draft, which is then edited.

Automate the collection and the first draft. Keep the judgement with a person.

The fifteen minutes that remain

What is left is the part only a person can do: deciding whether a spike was a real signal or a tracking artefact, and choosing the one change for next week. That is a short block of thinking instead of a long block of assembling, and it is the part most people find interesting once the copy-paste is gone.

Frequently asked questions

What should a weekly marketing report contain?
Three short sections: what moved against last week, what broke or looks like a tracking artefact, and the one change for next week. Additional sections tend to lengthen the report without changing a decision.
Should AI write the whole report?
It is not reliable for the whole job. A model describes deltas and flags outliers from a table well, but it cannot tell whether a spike was a real signal or a broken tag. Collection and drafting can be automated; the judgement is better kept with a person.
How are numbers kept comparable week to week?
By fixing the schema: the same columns, one row per day, appended weekly. Changing columns destroys comparability, which is the main thing a recurring report provides.

Start here

Read a guide, or open a tool and try it.

Every guide is tested on a live project before it is published, and every tool runs in your browser without an account.

Browse the archiveOpen the tools

Keep reading