Automate a weekly report without automating the thinking

Weekly reports are a good automation candidate because the schedule repeats. They are a poor candidate for “let AI tell us what happened” because the numbers, definitions, and business context change underneath the prose.

Build a reporting packet in two layers: a deterministic data layer that produces the numbers, and a reviewable narrative layer that helps a person explain what deserves attention.

Define the report contract

Before connecting anything, write down each metric's source, owner, time window, calculation, and acceptable freshness. Include what the metric does not mean. This small contract prevents a polished paragraph from hiding a changed definition.

Separate facts from commentary

Query the approved sources and store the extraction timestamp.
Run checks for missing data, unexpected nulls, and comparison periods.
Calculate changes with code or spreadsheet formulas—not prose generation.
Ask AI to draft plain-language observations from the checked data.
Have the metric owner approve the packet before distribution.

Never let prose repair bad data. If a source is late or a number looks surprising, show the problem clearly and pause the narrative.

Give the model a narrow job

Draft prompt · describe checked dataYou are writing a draft for an internal weekly report. Use only the verified table below. For each notable change: - state the metric and period comparison; - give the exact values and percentage change provided; - suggest one question for the metric owner; - mark any result that may be affected by missing or late data. Do not invent causes, benchmarks, targets, customer stories, or recommendations. If the table does not support an explanation, say that the cause is unknown. Verified table: {{metrics}}

Make approval part of the template

Put a small sign-off block at the top: source refresh time, data owner, narrative reviewer, and approved date. Keep a changelog when definitions or sources change. A report people can audit is more valuable than one that arrives a few minutes earlier.

What to measure

Track preparation time, number of manual corrections, late-source incidents, and how often readers ask a question the report should have answered. The objective is not to produce more commentary. It is to make the recurring packet easier to trust.

Every number has a named source and time window.
Data validation happens before narrative generation.
Unexpected changes are flagged, not explained away.
A person who understands the metric approves the final report.

The blueprint: query trusted sources → validate → calculate → draft context → owner signs off. Automation prepares the meeting; people do the thinking.

Back to all articlesBuild thoughtfully · Review often