Six dashboards, one table, every Monday at eight

What is the exact prompt?

"Every Monday at 8am, collect these numbers, each from its named source in my session: MRR from [billing dashboard]; new signups (last 7 days) from [analytics]; activation rate from [analytics view]; open support conversations from [support tool]; website sessions (last 7 days) from [web analytics]; [ad spend] from [ads console]. Build one table: metric, this week, last week, change %, and a four-week trend arrow. Below the table, at most three sentences, all about the single biggest mover: what moved and the most likely cause visible in the source. Flag any metric that changed more than 15% in either direction. If any dashboard fails to load or shows a date range you did not expect, write 'source unavailable' for that row. Never substitute last week's number, never estimate. Keep a history tab in [sheet] with one row per week. Post the digest to [channel]."

The never-substitute rule is the integrity of the whole system. A digest that carries a stale number forward converts "we do not know" into "everything is fine".

Why a companion instead of a script?

Access is the hard part of a metrics digest.

The numbers live in six differently-authenticated web apps, two with no API worth the name, one of which the team will replace by summer. A companion needs what you need: a logged-in browser and instructions about where to look.

A script wants credentials, endpoints and maintenance per source, and a BI tool wants connectors and a data model. The companion wins on setup time, on sources without APIs, and on surviving tool churn. The history lands in a sheet through the native Google Sheets integration, so the four-week trend is computed from data you own.

Cap the commentary at three sentences

Without the cap you get every row narrated ("signups grew modestly while sessions declined slightly"), and narrated tables train readers to skim. One table plus three sentences about the biggest mover is a document people read at 8:05, and the 15% flags catch what the prose does not.

Week one the digest is a convenience. Week twelve it is a dataset: the four-week arrows come from it, and "when did activation start slipping?" becomes a column scan. It feeds board reporting and the monthly board update, with deeper patterns in weekly reporting automation.

Verify it over two Mondays

Run it beside your manual ritual for two Mondays.

Same numbers both ways and calibration is done. Any mismatch is almost always a date-range definition, "last 7 days" versus "this week so far", which you fix by naming the exact range per source. Nail the ranges and the digest is as accurate as the dashboards.

After that, the only ongoing check is respecting the "source unavailable" rows. They mean a login expired or a dashboard changed shape, and the fix belongs in that week. Finished reporting runs are published on real runs.

Frequently asked questions