The weekly report that writes itself

A weekly sales report should be assembled by the system, not by a person: a scheduled job pulls the numbers from the CRM, compares them to last week and to target, flags the exceptions, and delivers a one-page summary before Monday morning. Once the pipeline data is structured, this takes a day or two to build and removes two to four hours of compilation a week, permanently. The report also gets more honest, because no human editor sits between the database and the reader.

Why automate a report someone can do in two hours?

Because the two hours are the smallest cost involved. A hand-compiled report is late — it describes the week after the week can be influenced. It is fragile — it stops existing when the compiler is on holiday. And it is quietly editorial — every manual assembly involves judgement calls about what to include and how to frame it, which is one of the routes by which sales reports learn to lie. A report that writes itself is punctual, permanent and unedited.

There is a strategic reason too. If the weekly numbers only exist because one person compiles them, the firm's visibility depends on that person — usually the founder or their PA. A reporting layer that runs without anyone is a small instalment of the larger project described in The MD Dashboard Blueprint: management numbers that tell the truth without being asked. If the numbers stop arriving the moment you stop chasing them, that is one of the five signs your growth depends entirely on you.

What belongs in the weekly report?

Less than the current version, almost certainly. A workable weekly page for a 5–50-staff service firm:

• New deals created — count and value, versus last week.
• Deals won and lost — count, value, and loss reasons where recorded.
• Pipeline movement — deals that changed stage, and total weighted pipeline versus last week.
• Revenue by source, month to date — the coarse channel view described in attribution for small firms.
• Exceptions — stale deals, overdue close dates, incomplete records; the short list a human should act on.

Ten to fifteen numbers, each with its prior-week comparison. Anything the reader cannot act on within a week belongs in a monthly review, not here.

How do you build it?

The mechanism has four moving parts, and it is worth building them in this order:

1. Fix the definitions first. When a report is automated on top of vague stages and immortal deals, then it produces wrong numbers faster and with more authority. Stage definitions and hygiene rules come first — automation only amplifies whatever the data already is.
2. Build the queries. Each number on the page becomes a saved query or report inside the CRM: deals created this week, deals won this week, stage transitions, exceptions. If the CRM cannot answer a question, that is a data-model problem to fix, not a gap to bridge in a spreadsheet.
3. Schedule the assembly. When Monday 7am arrives, then an automation runs the queries, drops the results into a fixed template — same numbers, same order, every week — and computes the week-on-week deltas. Consistency of format matters more than design polish; readers learn to scan a stable page in thirty seconds.
4. Deliver it where people already look. Email or the team chat channel, not a dashboard nobody visits. When a number breaches a threshold — pipeline down materially, no deals created, exceptions above a set count — then the report says so in the first line rather than burying it in a table.

When the job runs on schedule, then the Monday meeting starts from a shared page nobody spent Sunday evening producing — and the meeting itself shortens, because narration is no longer required.

What tools does this need?

Fewer than expected. Most mid-market CRMs can schedule report emails natively, which covers a plain version. A more useful version — deltas, thresholds, a formatted summary — typically takes a lightweight automation layer between the CRM and email or chat, the kind of build measured in days. What it does not need is a BI platform or a data warehouse; at this scale those are answers to questions nobody asked. The honest boundary is data location: when the pipeline still lives in a spreadsheet, automation has nothing reliable to pull from — the point at which that stops being workable is covered in when a spreadsheet stops being enough.

What changes once it runs?

Three things, quickly. The numbers arrive whether or not anyone is busy, which turns out to matter most in exactly the weeks everyone is busy. Comparisons become trustworthy, because the same definitions run every week without drift. And attention shifts from producing the report to acting on it — the exceptions list becomes the week's to-do list. A daily version of the same idea, six numbers glanced at each morning, is described in six numbers to check daily; the weekly page is where those daily glances get their context.

The end state is unglamorous and valuable: reporting as plumbing. Numbers flow from the CRM to the people who steer by them, on schedule, with no one carrying buckets.

---

Next step: the Growth System Audit — £450, seven days, credited against any build — maps where your growth system leaks, including how much of your reporting still runs on manual effort, and what to build first.