How to automate the weekly marketing report without trusting the wrong numbers

It's Monday, ten past nine. Someone on your team has three browser tabs open (ads, analytics, the CRM), last week's spreadsheet, and a leadership call at eleven. By half past ten the numbers are in the deck. Nobody has checked whether conversions dropped because the campaign died or because a tracking tag stopped firing on Thursday.

This is the job most teams hand to AI first, and it's a sensible pick. The report repeats, the structure barely changes, and the work is mostly copying and comparing. The tutorials make it look like an afternoon: connect your sources, write a prompt, schedule it to Slack. What they skip is the reason an automated report goes wrong.

Where an automated report actually goes wrong

A person pulling numbers by hand notices odd things, even if they don't always say so. An automated pipeline doesn't. It will report a broken tag as a collapse in conversions, in confident prose, every week, on time.

The failures we see most often aren't the model inventing numbers from nowhere. They're quieter:

• Stale data. A source didn't refresh, a cached query served last month's figures, or a connector's sign-in expired overnight. The report looks normal. It's just wrong.
• Shifting windows. One week compares Monday to Sunday, the next compares the last seven days, and a partial week slips in around a holiday.
• Changed definitions. Someone edited what counts as a lead in the CRM, and the trend line now compares two different things.
• Made-up causes. The model sees a drop and offers a reason. The reason sounds plausible, and nothing in the data supports it.

A better prompt fixes none of these. Deciding what the model is allowed to touch fixes all of them.

Give each part of the report one owner

The setup that holds up keeps the model away from arithmetic and away from raw data. Each part has one job.

The rule that matters most: every number in the report is calculated before the model sees it. Percentage changes, week-on-week movement, each channel's share of traffic. The model gets a finished table and writes sentences about it. If a number isn't in the table, the model doesn't get to mention it.

The checks that run before the draft

These are short, dull and specific to your data, which is why vendor templates leave them out. A starting set:

• Freshness. Each source reports the date its data runs to. If any source is behind the window, the report says so at the top, or doesn't send.
• Same window. The comparison period has the same number of days and the same weekday alignment as the current one.
• Volume floor. If a metric that is never zero comes back as zero, or a source returns far fewer rows than usual, the pipeline stops and flags instead of writing.
• Definition lock. The formula for each headline metric is written down once, and the pipeline uses that formula, not whatever the dashboard shows today.
• Big-mover flag. Anything that moves past a threshold you pick is marked for the reviewer, with the raw numbers next to it.

Set the threshold from your own history, not a template. Look at a few months of weekly swings for each metric and put the flag just outside the normal range. A channel that routinely jumps around needs a wider band than one that barely moves.

What we learned running our own

We run our own search performance reporting this way at Winvesta: a short weekly pulse, a fortnightly list of pages close to ranking well, and a fuller monthly review, each posted to a team channel on a schedule. A few problems only showed up once it ran unattended.

Credentials expire. A scheduled job can't complete a sign-in prompt, so when access lapsed, the dashboard stopped updating while the posts kept going out. Every report now prints the date its data runs to, so a stale one is obvious at a glance.

Caches lie politely. In one of our internal reports, a cached query handed back weeks-old figures that looked entirely plausible. The fix was the same freshness check: compare the date the data claims to cover with the date the report says it covers.

Schedulers are blunter than you'd expect. Our fortnightly report actually fires every week and checks whether it's an even-numbered week before doing anything, because the scheduler had no clean way to say every two weeks. A small detail, but the kind that silently doubles or halves a cadence if nobody writes it down.

Who signs off, and when to step back

Start with a named person reading every draft before it reaches leadership. Their job isn't to recheck arithmetic the code already did. It's to add the reason behind a movement, cut anything the model overstated, and catch what the checks didn't know to look for.

Once the report has gone out clean for a run of weeks and the reviewer is mostly approving without edits, move to review by exception: the report sends on its own when every check passes, and goes to the reviewer only when a check fails or a big mover is flagged. It's the same shift from approving everything to reviewing exceptions that we describe for finance approvals.

Keep a person on anything that leads to a decision. A report suggesting spend should move from one channel to another is a recommendation about money, and it needs someone who owns that budget, however clean the numbers are.

Where to start

1. Pick one report, the one someone rebuilds by hand every week. Leave the monthly board pack for later.
2. Write down the definitions of its five or six headline numbers before building anything.
3. Build the pull and the checks, and run them alongside the manual report for a few weeks. Compare the two.
4. Only then add the model to draft the sentences.

If you've already moved execution work in-house, as we cover in what AI can replace from your marketing agency, reporting is usually the next thing to come off someone's Monday.

What this does and doesn't solve

This setup takes the assembly out of reporting: the pulling, the comparing, the first draft. It won't tell you why a channel moved, and it won't catch a tracking problem that none of your checks describe. Winnit sets up this kind of pipeline inside the tools a team already uses, with the checks and the approval step written down, and hands it over so the team can run and change it. If your weekly report eats a morning someone would rather spend on the decisions it should inform, talk to us at Winnit.