Weekly operations reporting pack
Four systems get reconciled into one model and one pack, with the numbers computed once instead of rebuilt by hand every Friday.
This is a reference design we build from — one of a set that are not delivered client projects, and the figures are estimates rather than measured results.
Trigger
Schedule — Monday 06:00, or on demand
Timeline
1 wk audit → 2-3 wks build → 1 wk parallel run
Stack
Scheduled Cloud Run job · BigQuery or Postgres warehouse · dbt-style transformations · Looker Studio or a rendered PDF · LLM used only for narrative commentary, never for the numbers
Outcome
Friday afternoon comes back. The numbers stop being arguable because the definitions live in one versioned place.
The process today
Someone spends most of Friday exporting CSVs from four systems, pasting them into a master spreadsheet, and rebuilding the same charts.
What the automation does
Pulls from CRM, finance, project system and support tool. Reconciles to a single model. Computes the agreed metric definitions once, in one place. Renders the pack and distributes it to the distribution list. Flags metrics that moved beyond a threshold with a short written note on what changed. The model is used only for that narrative commentary — it never touches or recalculates the numbers themselves, which come solely from the deterministic transformation layer.
Where a human stays in the loop
The metric definitions are agreed and signed off during the audit, not invented by the pipeline. Anyone can trace a number back to its transformation, and the written commentary is reviewed before wide distribution during the parallel-run phase.
What you end up owning
The warehouse schema, the transformation layer, the scheduled job, and the report template — a single versioned source of truth for the metric definitions.