Automated client reporting works when the workflow gathers the figures, calculates them the same way every time and prepares a draft that a person checks before it reaches the client. The time goes out of copying numbers between tools. The judgement about what those numbers mean, and what the client should do next, stays with someone accountable.
This guide draws on the reporting controls in my own TomHow Search operating system, which manages search and AI-search evidence and the reports built from it. The worked example later in the guide is illustrative, not a client result.
What should an automated client report actually do?
A useful client report answers three questions: what happened in the period, why it probably happened and what should happen next. Automation is good at the first. It can help draft the second when the underlying comparison is sound. The third is a recommendation, and it should come from a person who understands the client's position.
Before building anything, write down the reporting period, every source, the definition of each figure and who signs the report off. If two people on your team would calculate the same number differently today, automation will make that disagreement faster, not resolve it.
Which steps should be automated, and which should not?
| Step | Automate? | Why |
|---|---|---|
| Collect figures from permitted sources | Yes | Scheduled, logged and repeatable |
| Check the period is complete | Yes | Missing days or late data are named, not filled |
| Calculate and compare | Yes, in formulas or code | The same definitions every period |
| Draft an explanation of changes | With review | Only from the comparison actually calculated |
| Recommend next actions | No | Needs knowledge of the client's situation |
| Send to the client | No | A person approves the exact version |
What went wrong in my own reporting system, and what changed?
The TomHow Search operating system case study records the failures that shaped it. Three apply directly to client reporting:
- Tool disagreement. Different sources reported different values for what looked like the same question. The fix was to preserve the source, date, market and method for each figure, and never merge unlike measures into one synthetic number.
- Report overreach. A recommendation could read like a proven business outcome. Reports now label observation, interpretation, action and expected effect separately.
- One-off answers presented as trends. A single AI answer could be shown as stable visibility. Measurement now repeats a defined set of queries, records the model and date, saves the cited sources and states the sampling limits.
None of these were model problems. They were reporting design problems, and they would have appeared in a manual report too. Automation simply produces them more often unless the rules are written down first.
How do you stop a report claiming more than the data shows?
Give every statement in the report a type. An observation is a measured figure with its source and period. An interpretation is a likely explanation, written as one. An action is something someone will do. An expected effect is a hypothesis to check next period. When those four are mixed in one sentence, a reader cannot tell which part is proven.
Name missing data rather than smoothing over it. If a source failed to update, the draft should say so and leave the figure blank. A plausible number generated to fill the gap is worse than no number, because the client will act on it.
Keep the arithmetic out of the language model. Calculations belong in spreadsheet formulas or code that gives the same answer every time. A model can then describe a change the code has already calculated, and the reviewer can check the description against the figures.
What does a monthly reporting workflow look like?
Illustrative example, not a client result: a small agency sends each client a monthly marketing report.
- On the first working day of the month, the workflow collects the previous month's figures from the agreed analytics, search and CRM sources.
- It checks the period is complete and the definitions match last month's. Anything missing or changed is listed at the top of the draft.
- Formulas calculate the month-on-month comparisons and flag movements beyond an agreed threshold.
- A draft summary describes the flagged movements, linking each sentence to the figure it describes.
- The account lead reviews the draft, writes the recommendations and approves the final version for sending.
Measure preparation time, the number of corrections the reviewer makes, how often a source is late and whether reports go out on the agreed date. Those measures tell you whether the workflow is working before anyone claims a saving.
How do you know the automation is worth keeping?
Record how the report is produced today before changing anything: who prepares it, how long it takes and how often figures are corrected after sending. Compare the same measures after the pilot, including the time the reviewer still spends checking. A workflow that saves preparation time but doubles review effort has moved the work, not removed it.
Include running costs: software subscriptions, API usage and the time needed to maintain source connections when a provider changes its data. The pilot cost guide lists what to include.
Where should you start?
Choose one report for one client type, with sources you are permitted to use and an account lead willing to review the drafts. Prove it on real periods, including a month where something went wrong, before extending it. The workflow examples guide shows how reporting compares with other first candidates, and an AI automation pilot is the engagement for building and testing it.