Stop 6 of 9 · Weekly
Client reporting pipeline
Twenty monthly reports built from exports by Claude Code, each with three evidenced fixes, a QA file Dany reads first, and one priced line at the bottom.
Twenty reports in the first week
The retainer is bought once and re-bought every month, quietly, when the client decides whether the invoice felt fair. The monthly report is where that decision happens, and it used to be Dany's whole first Friday.
Same sections, same arithmetic, same file shapes, twenty times over. That is not a chat job. It is a small pipeline Claude Code writes once and the studio runs on the first working day.
What goes in
| Input | What it gives the report |
|---|---|
| Search Console export, this month and last | Clicks, impressions, the pages that moved |
| Analytics export, this month and last | Sessions, the pages people land on, form completions |
| Last month's check log from the weekly walk | What broke, and what the studio fixed |
| The ticket log from the retainer queue | What the studio actually did with their hours |
No form inbox, no CMS export, no customer names or email addresses. The pipeline reads traffic and work, and nothing about the client's customers.
The report shape
Five sections, the same on every client: what happened this month in one sentence, the three numbers with last month beside them, what we did, three fixes we recommend with the page and the hours each, and one line at the bottom about anything that sits outside the retainer.
exports/ has one folder per client slug, each with search-console.csv and analytics.csv for last month, and exports-prev/ has the same shape for the month before. checks/ has the weekly walk tables per client and tickets.csv has the month's closed tickets. template.md has our five section order. Write report.js. For each client, produce reports/<slug>.md following template.md exactly: clicks, sessions and form completions against last month, the three pages with the largest change, the work done from tickets.csv, and the three worst pages by impressions with a low click rate. Where a file is missing, write [missing: source] into that section and keep going. Run it on peak-roofing and northgate-vets only, and print both so I can check them against Search Console.
Add qa.md to every run. Flag: any client whose clicks changed by more than 40 percent, any figure that does not reconcile between the two exports, any client with no tickets closed this month, any missing input file, and any report where a recommended fix names a page that does not exist on the site. Print the QA file first, before the reports.
Read reports/peak-roofing.md and rewrite the fixes section. Each fix names the page, the number from the export that justifies it, what changes on the page, the hours, and whether it is inside the retainer or a change request. Drop any fix you cannot attach a number to, and say which ones you dropped.
What the report never says
No ranking promise. No cause that is not either in the logs or clearly labelled as a guess. No number the studio cannot show rows for. A client who catches one invented figure re-reads every report they have ever had from you.
The measurable
Three numbers, every month. Minutes from exports to twenty drafts. How many QA flags were real. And the one that pays: how many of the priced lines at the bottom of the reports were accepted. Two or three a month out of twenty is a healthy studio, and none for two months means the fixes are not specific enough to say yes to.