How is this different from the recurring analysis report playbook?

The recurring report produces one repeatable deliverable — this month's numbers, the same way as last month's. The analytics system is the infrastructure underneath many such deliverables: the shared dictionary, query library, data contracts, CLAUDE.md, and monitors that any report, dashboard, or ad-hoc question draws on. A recurring report is a consumer of the system; the system is what makes every report, and every self-serve question, consistent and trustworthy. Build the reports first, then graduate the shared parts into the system.

Doesn't letting non-analysts self-serve risk wrong numbers everywhere?

Only if you skip the guardrails — which is exactly why they're baked into the system rather than left to discipline. The CLAUDE.md forces every answer to use the dictionary's definitions and reconcile against a known total, the query library gives vetted answers to the common questions, and sensitive work still routes to analysts. Self-serve is safe because the guardrails are in the folder, not in someone's memory; a non-analyst gets the agreed definition and the reconciliation habit automatically, not generic guesses.

What do I need before standing this up?

The foundation pieces from the earlier playbooks: a metric dictionary, a handful of explained and reconciled queries, data-quality contracts for your key sources, and ideally a report runbook. This capstone assembles them — so if you don't have them yet, build those first rather than starting here. You also need your team's conventions (where data lives, how fresh it is) and, critically, a named person who will own and maintain the system.

Who should own the analytics system?

One named custodian — usually the analytics lead — who owns the dictionary, the data contracts, and the query library, and runs the change process when a definition or contract needs updating. The whole system's value is that it's a single, consistent source of truth; without an owner it drifts back into inconsistency within a quarter. The owner doesn't do all the analysis — they keep the shared foundation current so everyone else can self-serve on it safely.

Stand up the team's self-serve analytics system

when to reach for this

Your team's analytics live in one analyst's head and a folder of one-off queries nobody else can read. Every question is a bespoke ask, the same metric gets recomputed five slightly-different ways, and when that one analyst is on leave the team goes blind. This is the orchestration capstone: it strings the other Data playbooks into one standing system — the metric dictionary, a library of saved and reconciled queries, the data-quality contracts, a CLAUDE.md that teaches Claude your conventions, and scheduled monitors on the numbers that matter. The payoff isn't a faster query; it's that a non-analyst can get a trustworthy answer themselves, the recurring numbers come out the same way every time, and your analysts spend their hours on judgment instead of re-deriving 'active users' for the hundredth time.

gather this first

The pieces you've already built: your metrics.md (from the metric-dictionary playbook), the explained and reconciled queries (from Write the query and learn the SQL), the data contracts (from Audit a dataset's quality before you trust it), and any report runbook (from Build a recurring analysis report). This capstone assembles them — build the foundations first.
The questions your team asks over and over — "how many active users," "what's revenue by region," "how's churn" — because the recurring ones are exactly what self-serve should answer without an analyst.
Your team's conventions (where data lives, naming, how fresh sources are) and who will own and maintain the system, since an analytics system with no owner rots into the mess it replaced.

the workflow

Assemble the foundation — the dictionary and the data contracts

Open your analysis folder in Claude Desktop and ask in the chat — no terminal needed. Start by making the two governing documents the spine of the system, in one place, so everything else references them. Definitions and data quality are the foundation everything self-serve stands on; without them, 'self-serve' just means 'wrong faster.'

you ask

Here's our metrics.md and our data-quality rules. Help me organize them into the foundation of a team analytics system: a clear folder structure with the metric dictionary and the data contracts at the root, a short README explaining how the two relate and how to use them, and a flag for any gap — a metric we report but haven't defined, or a key source with no quality contract. Don't build queries yet; get the foundation clean and complete first.

what you get back A clean foundation: metrics.md and the data contracts at the root, a README tying them together, and a gap list — "'engaged account' is reported but undefined; the events source has no freshness contract." The governing layer is solid before anything is built on it.

Definitions and data contracts are the spine. A self-serve system built without them just lets more people compute inconsistent, unvalidated numbers faster — the foundation is what makes self-serve safe, not just fast.
Build the query library — saved, explained, reconciled, named

Turn the recurring questions into a library of trustworthy, reusable queries — each one already explained and reconciled, each tied to a dictionary definition. This is what a teammate reaches for instead of writing SQL from scratch or asking you.

you ask

For each recurring question on our list — active users by plan, revenue by region, new vs returning, churn — turn the explained query into a library entry: a clear name, a one-line description of the question it answers, the metric-dictionary definition it uses, the query with a comment per clause, and the known total it reconciles against. Organize them so a teammate can find the right one by the question they have, not by knowing SQL. Flag any recurring question we don't yet have a trustworthy query for.

what you get back A query library: active-users.sql, revenue-by-region.sql, each named for its question, definition-linked, commented, and reconciled — plus a flag for the recurring questions still missing a vetted query. The answers to the common asks, ready to reuse instead of rebuild.
Write the CLAUDE.md that teaches Claude your conventions

Capture the team's context into a CLAUDE.md at the folder root so Claude answers every question — including the ad-hoc ones the library doesn't cover — using your definitions, your sources, and your guardrails, not generic defaults. This is what makes self-serve trustworthy for questions you didn't pre-build.

you ask

Draft a CLAUDE.md for this analysis folder so anyone — analyst or not — gets answers that follow our conventions. Include: where each data source lives and how fresh it is, the rule to always use metric definitions from metrics.md (never invent one), the rule to always reconcile a result against a known total and show the working, what data is sensitive and must stay local, and a pointer to the query library for common questions. Write it so Claude treats these as standing instructions for every request in this folder.

what you get back A CLAUDE.md that bakes the guardrails into every interaction — Claude now reaches for metrics.md definitions, reconciles by default, keeps sensitive data local, and points at the library — so even an unplanned question gets answered the team's way, not a generic one.

The CLAUDE.md is what extends self-serve past the pre-built queries. A teammate's novel question still gets the agreed definitions and the reconciliation habit, because the folder itself instructs Claude to work that way.
Stand up the monitors on the numbers that matter (Power Track)

Put the always-on layer in place: scheduled agents that profile new loads, reconcile the key metrics, and alert a human only when something breaks — so the system catches a data problem before it reaches a report, instead of after a stakeholder does.

you ask

Design the monitoring layer: for our 3–4 most important sources and metrics, a scheduled agent that on each new load runs the data-quality contract, recomputes the key metric, reconciles it against the prior period, and pings a named person only when a blocker fires or a number moves outside its normal range. Specify what each monitor checks, the alert threshold, and who it notifies. Keep it to the few numbers whose breakage actually matters.

what you get back A monitoring spec: "events source — audit on arrival, alert the data lead on any blocker; active-users — recompute weekly, alert if it moves >15% vs the 4-week norm." The recurring report and the dashboards now run on watched data, with a human looped in on exceptions, not surprises. (Scheduling agents is the Power Track — see the Features tab.)

Monitor the few numbers whose breakage is expensive, not everything. An alert on every wobble gets muted within a week; an alert that only fires on a real blocker gets trusted and acted on.
Make it self-serve and name the owner

Give the system a front door and a custodian. A short guide so a non-analyst knows how to ask, and a named owner with a change process for definitions — because the difference between a system and a graveyard of files is whether someone keeps it alive.

you ask

Write the front door: a short 'how to get an answer' guide for non-analysts (how to ask, which library query fits common questions, when to escalate to an analyst), and a governance note naming the system's owner, how a metric definition or data contract gets changed (proposed, reviewed, logged in the changelog), and how often the whole thing is reviewed. Make self-serve the default for common questions and analysts the path for genuinely new ones.

what you get back A how-to-self-serve.md plus a governance note: a non-analyst can get the common numbers themselves with the guardrails baked in, analysts own the novel and the sensitive work, and one named person keeps the dictionary, contracts, and library from drifting. A living system, not a folder that quietly goes stale.

The owner and the change process are what keep it alive. A self-serve system without a custodian decays into exactly the inconsistent mess it replaced — within a quarter, by the same drift the metric dictionary exists to prevent.

make it your own

Start with one workstream, not the whole team: stand the system up for a single area first — say, growth metrics — prove it, then widen. A system that tries to cover everything on day one covers nothing well; one solid workstream is the template for the rest.
The manager/team view is the successor: the local, file-based system here is the honest first version. The natural next step is a shared team-progress and metric-health dashboard — who's self-serving, which numbers are watched, where the gaps are — which the operating guide covers as the deferred backend layer.
Bilingual self-serve: if part of your team works in Arabic, author the self-serve guide and the metric dictionary's definitions in Arabic too, so a non-analyst gets the same trustworthy answer in either language — authored in Arabic, not translated after.
Recurring reports plug straight in: every Build a recurring analysis report pipeline becomes a consumer of this system — it pulls definitions from the dictionary, queries from the library, and trust from the monitors, so the monthly report stops being a rebuild and becomes a rerun.

watch out for

A system with no owner rots into the mess it replaced. The single point of failure isn't the tech — it's that nobody is responsible for keeping the dictionary, contracts, and library current. Name a custodian and a change process before you build, or in a quarter you'll have two sources of truth and a folder of stale queries again.
Self-serve still needs the guardrails baked in, or it's just faster wrong answers. The whole reason a non-analyst can be trusted to pull a number is that the definitions, the reconciliation habit, and the data contracts are in the CLAUDE.md and the library — not in an analyst's head. Don't open the doors before the guardrails are wired in.
Don't automate a pipeline you haven't verified by hand first. A scheduled monitor on an unreconciled metric just broadcasts a wrong number on a schedule. Each query goes into the library only after it's been explained and reconciled manually — automation amplifies whatever it's pointed at, including errors.
The CLAUDE.md and the dictionary are living documents, not a one-time setup. Conventions change, sources move, definitions get refined — a system reviewed once and never again drifts out of date silently. Build the review cadence in, and treat the changelog as part of the system, not paperwork.

you'll end up with A self-serve analytics system — the metric dictionary and data contracts as its spine, a library of named, explained, reconciled queries, a CLAUDE.md that makes every answer follow your conventions, scheduled monitors on the numbers that matter, and a named owner — so a non-analyst gets a trustworthy answer themselves, the recurring numbers stay consistent, and your analysts spend their time on judgment instead of re-deriving the same metrics.

Questions people ask

How is this different from the recurring analysis report playbook?: The recurring report produces one repeatable deliverable — this month's numbers, the same way as last month's. The analytics system is the infrastructure underneath many such deliverables: the shared dictionary, query library, data contracts, CLAUDE.md, and monitors that any report, dashboard, or ad-hoc question draws on. A recurring report is a consumer of the system; the system is what makes every report, and every self-serve question, consistent and trustworthy. Build the reports first, then graduate the shared parts into the system.
Doesn't letting non-analysts self-serve risk wrong numbers everywhere?: Only if you skip the guardrails — which is exactly why they're baked into the system rather than left to discipline. The CLAUDE.md forces every answer to use the dictionary's definitions and reconcile against a known total, the query library gives vetted answers to the common questions, and sensitive work still routes to analysts. Self-serve is safe because the guardrails are in the folder, not in someone's memory; a non-analyst gets the agreed definition and the reconciliation habit automatically, not generic guesses.
What do I need before standing this up?: The foundation pieces from the earlier playbooks: a metric dictionary, a handful of explained and reconciled queries, data-quality contracts for your key sources, and ideally a report runbook. This capstone assembles them — so if you don't have them yet, build those first rather than starting here. You also need your team's conventions (where data lives, how fresh it is) and, critically, a named person who will own and maintain the system.
Who should own the analytics system?: One named custodian — usually the analytics lead — who owns the dictionary, the data contracts, and the query library, and runs the change process when a definition or contract needs updating. The whole system's value is that it's a single, consistent source of truth; without an owner it drifts back into inconsistency within a quarter. The owner doesn't do all the analysis — they keep the shared foundation current so everyone else can self-serve on it safely.