toolkit

Scenario · The bigger jobs

The monthly client report is due

The first week of the month, for every client on a retainer.

The monthly report to a retainer client is unavoidable and repetitive, which is exactly the kind of work that gets rushed under deadline pressure into a data dump with no actual argument in it. This pulls the same comparison window every month — search visibility, site behavior, and real visitor experience — so the numbers are actually comparable month to month; the two or three sentences explaining what happened and what's being done about it are still the part only a person can write.

What to ask for

See it work

A real run of Chrome UX Report field series:

Chrome UX Report field series · chrome-ux-report-field-series
verdict: INFO   2 device(s) · field-data report_date
origin:  https://example.com/   captured: <timestamp>

── MOBILE (report_date <date>) ──
  overall: fast
  LCP <n>ms — good
  INP <n>ms — good
  CLS 0.02 — good

── DESKTOP (report_date <date>) ──
  overall: fast
  LCP <n>ms — good
  INP <n>ms — good
  CLS 0.01 — good

The captured report, exactly as a run hands it to a client —open the full report ↗

Recurring, unavoidable, and the work most improved by doing it the same way every time. The trap is that it is assembly work, so it gets done under time pressure and becomes a data dump with no argument in it.

  1. Fix the window and use the same one every month. Calendar month against the previous month, and the same month last year where seasonality matters — a cosmetic practice’s January is not its June, and month-on-month alone will misreport that as a collapse.
  2. Pull search performance. Search Console for impressions, clicks and position by page and by query. This is the layer that shows whether visibility moved, independently of whether traffic did.
  3. Pull behaviour. The analytics series for sessions, engagement and conversions. Where the two disagree — visibility up, conversions flat — that gap is the most interesting thing in the report and the thing worth leading with.
  4. Include the experience numbers, at origin level. Real-user field data over time, and a current performance check. These are the metrics that change slowly and are worth a trend line rather than a monthly figure.
  5. [manual] Find the story before assembling anything. One thing that improved, one thing that did not, one thing being done next. If the numbers do not support three sentences, the report is a table and nobody will read it.
  6. Assemble the document. The client report rolls up the outputs already generated into one branded deliverable with a scorecard and a card per area. Confirm the underlying runs are from this month — a report assembled from stale output is the standard failure and it announces itself to nobody.
  7. [manual] Write the covering note and send it. Three sentences from step 5. Keep the PDF with the client record so the version they received is recoverable when they ask about it.

Same window, every month

Changing the comparison window between months makes the series meaningless and is the easiest way to accidentally report growth that is not there. Step 1 is boring and it is the one that makes the other six worth doing.

What this does not cover

The narrative. Numbers do not explain themselves, and the difference between a report that renews a retainer and one that does not is the two sentences saying what happened and what we are doing about it — written by a person who knows what happened. It also cannot make a bad month look good, and should not: a report that never reports a decline stops being read as information.

← All scenarios