Twice a year at minimum, more likely every quarter, you stop doing product work and start doing archaeology: what did we ship, what did the metrics do, which customers escalated, what did we promise last time, and how do I get all of that into a deck by Thursday. Productboard's enterprise survey of 379 product professionals found that creating presentations is the single biggest AI time-saver for product teams, around four hours saved per task (the report), which tells you two things: this is where the hours go, and teams are already reaching for AI to get them back. PMs themselves describe the job as being stuck "pulling the data that we have and doing presentations" instead of doing discovery.

Can you build a QBR pipeline with Claude Code where every number is pulled live from its source system, every claim carries a citation, and the narrative arrives assembled for you to edit rather than write? Yes. This playbook is the complete build, and it covers two variants with one set of machinery: the internal product QBR (exec audience) and the per-account QBR (CS and enterprise audience). Same repo, same skill, same judge; different template and different data slice.

What you're building

Two weeks before the review date, without prompting from you:

A draft review document following your committed template: metric trends vs. targets, shipped vs. planned with a stated reason for every slip, top customer evidence (verbatim quotes, escalations, wins), risks with named owners, and asks.
A claims registry (claims.json) alongside the draft, mapping every stated number and claim to the query or record that produced it. Receipts, not vibes.
A "what we said last time" section: every commitment and ask from the previous quarter explicitly addressed as done, slipped with a reason, or dropped with a reason. This is the single thing execs notice most, and the thing manual prep most often drops.
A deck file generated from the draft, ready for a human layout pass.
For the account variant: the same structure scoped to one customer, with their usage, their tickets, their calls, their renewal risks.

Why the chatbot version underdelivers

Paste your metrics dashboard screenshot into a chat and ask for "a QBR draft" and you get something that reads fine and survives zero scrutiny. Three specific failures:

Numbers typed from memory. The model fills gaps with plausible figures, or you fill them yourself from recollection. Either way, the first exec who cross-checks a number against the dashboard and finds a mismatch discounts the entire deck. One wrong number costs you the other forty right ones.

No receipts. When someone asks "where does that 12% come from," the answer in a chatbot workflow is "let me get back to you." In this build the answer is a claims.json entry with the query, the source system, and the timestamp.

No continuity. A fresh chat has no idea what you committed to in April. Continuity here is not a model feature you wait for; it is an engineering artifact you build. Last quarter's review, commitments, and asks are committed to the repo, and reading them is step one of the skill. The draft that ignores "what we said last time" is the draft that gets you the worst question in the room.

And underneath all three: the actual time sink was never the writing. It is assembling evidence from five systems (analytics, warehouse, tracker, CRM, call recorder) into one narrative. That assembly is exactly what this build automates. The writing you keep.

Phase 0: Prerequisites

Claude Code installed (npm install -g @anthropic-ai/claude-code) and authenticated. Pro, Max, Team, or Enterprise if you want the scheduled routine and artifact publishing later.
Read access to your five sources. Metrics via the PostHog MCP server or your warehouse through Google's MCP Toolbox for Databases (BigQuery, Postgres). Delivery reality via the official Linear MCP or Atlassian MCP for Jira. Customer evidence via the official HubSpot or Salesforce MCPs. Call snippets via community servers for Gong or Fireflies; community means you review the code and pin a version before trusting it near customer data.
A useful head start: Anthropic's knowledge-work-plugins include a Product Management plugin with /stakeholder-update and /metrics-review commands. Good scaffolding; the template, claims discipline, and quarter-over-quarter memory below are not in it.
A dedicated git repo. The recurring design depends on committed history.
Last quarter's deck and commitments, transcribed once by hand into the archive. The system needs a starting point for "what we said last time."

Phase 1: The repo (the template is the quality bar)

qbr/
├── CLAUDE.md
├── .mcp.json                    # analytics, tracker, CRM, call MCPs
├── .claude/
│   ├── agents/
│   │   └── review-judge.md
│   └── skills/
│       └── qbr-draft/
│           └── SKILL.md
├── templates/
│   ├── qbr-internal.md          # product QBR, exec audience
│   └── qbr-account.md           # per-account QBR, CS audience
└── quarters/                    # committed archive = the memory
    └── 2026-Q2/
        ├── review.md
        ├── claims.json          # every claim → its source
        ├── commitments.json     # what we promised, for next quarter
        └── deck.pptx

The template is not a formality; it is the quality bar the whole system is graded against. Each section declares three things: the section name, the question it answers, and the evidence type it requires. For the internal template:

## Metrics vs. targets
Question: did the numbers do what we said they would?
Evidence required: current value, target, and trend per metric,
each from a live query. No dashboard screenshots, no recall.

## Shipped vs. planned
Question: did we deliver what we committed, and why not where not?
Evidence required: tracker query of items planned at quarter
start vs. shipped, with a stated reason per slip.

## Customer evidence
Question: what are customers telling us that the numbers can't?
Evidence required: verbatim quotes with record or call IDs,
escalations with status, wins with account names.

## What we said last time
Question: did we do what we promised in the previous review?
Evidence required: every entry in the prior commitments.json,
each marked done / slipped (reason) / dropped (reason).

## Risks and asks
Question: what could go wrong, and what do we need?
Evidence required: an owner per risk, a specific ask per ask.

qbr-account.md has the same skeleton scoped to one account: their usage trend, their open tickets and escalations, their call highlights, their renewal risks. Same machinery, different slice.

Phase 2: Source wiring

.mcp.json is project-scoped and committed, so every session (including scheduled ones) gets the same connections. Wire the analytics MCP, the tracker MCP, the CRM MCP, and the call-recorder MCP, then spend an interactive session verifying each pull with Claude Code: "planned at quarter start" is a real query against your tracker's snapshot or label conventions, not a guess; CRM escalations need whatever filter your team actually uses; call snippets should come back with IDs you can trace.

Write the resolved query patterns into CLAUDE.md as rules ("shipped means status Done with a release tag inside the quarter window"). Definitions that live in prompts drift; definitions that live in a committed file get reviewed when they change.

Phase 3: The assembly skill

.claude/skills/qbr-draft/SKILL.md

---
name: qbr-draft
description: Assemble a review draft with a claims registry
---
Assemble the review for the given quarter (and account, if the
account template is specified). Run dir: quarters/<YYYY-QN>/

1. PRIOR QUARTER: read the previous quarters/*/review.md,
   claims.json, and commitments.json. List every commitment
   and ask. Each MUST be addressed in this draft.
2. SECTION PULLS: for each template section, run only the
   queries its declared evidence type requires. Metrics from
   the analytics/warehouse MCPs; shipped-vs-planned from the
   tracker; quotes, escalations, and wins from CRM and call
   MCPs, verbatim only, with record IDs.
3. REGISTER: every number or claim headed for the draft gets a
   claims.json entry: claim text, source system, query or
   record ID, value, retrieved-at timestamp.
4. DRAFT: write review.md against the template. A section
   missing its required evidence says EVIDENCE MISSING; never
   substitute a plausible number.
5. JUDGE: launch review-judge. On FAIL, fix and re-judge.
   Max 2 loops, then stop and list unresolved items for the
   human pass.
6. PERSIST: commit review.md, claims.json, and the new
   commitments.json (this quarter's promises, for next time).

Step 2 fans out naturally: each section's pull can run as its own subagent with its own context, so CRM records never crowd out warehouse results. Step 4's EVIDENCE MISSING rule is the anti-fabrication valve; a visible gap is a to-do, an invented number is a credibility incident.

Phase 4: The judge agent

This is the board-deck-judge idea: before any human reads the draft, an agent walks the claims registry and tries to break it.

.claude/agents/review-judge.md

---
name: review-judge
description: Grades the review draft before the human pass
tools: Read, Bash
---
Grade the draft against:
1. Every number and claim in review.md has a claims.json entry.
   No entry, no claim.
2. Pick 5 claims at random and re-run their queries or re-fetch
   their records. Any mismatch: FAIL, report both values.
3. Every item in the prior quarter's commitments.json is
   explicitly addressed. Silence on any item: FAIL.
4. No unsourced superlatives. "Strongest quarter", "major win",
   "significant improvement" must trace to a claims entry or
   be cut.
5. Quotes marked verbatim: grep them against the source
   snippets in the claims entries.
Return PASS, or FAIL with the exact fixes.

Check 3 is the one that changes how the review lands. Execs pattern-match for evasion, and a draft that voluntarily says "we committed to X, it slipped, here is why" reads as a team in control of its own story.

Phase 5: Deck output (and the human pass)

For the deck itself, Anthropic's official document skills include a pptx skill: point Claude Code at review.md and have it generate deck.pptx section by section, one claim-backed statement per slide plus its supporting numbers. A markdown-to-deck pipeline (Marp, Pandoc) works too if your team lives in markdown.

Be clear about the boundary: generated decks are structurally right and visually adequate. Layout polish, brand templates, and the chart that needs to land just so remain a human pass, and budget for it. The division of labor to defend is this: the PM owns the story arc, the system owns the assembly and the receipts. You will reorder sections, cut a slide, sharpen the framing. What you will not do is spend two days re-deriving numbers from five systems, and every number you touch already carries its citation.

Phase 6: Scheduling

Quarterly cadence makes scheduling almost trivial compared to weekly workflows. Two sane options:

A cloud routine via /schedule: a cron routine that fires two weeks before each review date, clones the repo (inheriting templates/, quarters/, and .mcp.json), runs /qbr-draft, and pushes the draft on a claude/ branch for review. Configure source credentials in the routine's environment settings; the cloud sandbox does not have your laptop's secrets.
A manual trigger: for four runs a year, opening Claude Code and invoking /qbr-draft yourself is a defensible v1. The value is in the skill and the archive, not the cron entry.

Either way, the continuity mechanism is identical: a fresh session does not inherit April's conclusions on its own; it inherits them because quarters/ is committed and reading it is step 1 of the skill. For monthly business reviews, same build, shorter window, and the routine earns its keep faster.

Phase 7: Sharing with the team

Two audiences, two mechanics:

Artifact publish for the pre-read. Claude Code can publish review.md as a hosted page on claude.ai: first publish needs your approval, republishing reuses the URL, and on Team/Enterprise plans visibility can be scoped to your organization. Caveats to plan around: publishing works from the CLI and desktop app, not from every automated surface, so in a fully scheduled setup the publish step may be where a human stays in the loop. Send the page as the pre-read three days before the meeting; a review where attendees arrive having read the receipts is a different meeting.

The deck file itself. deck.pptx is committed in the quarter's folder, so distribution is a link to the file or a drop into the meeting invite. For account QBRs, the CS owner gets the draft folder per account and does the customer-facing polish.

Phase 8: Maintenance (what you own now)

Template evolution. The exec team asks for a new section; that is a PR to templates/, and the evidence-type line gets written before the section ships. An evidence-free section degrades the whole quality bar.
Source drift, five ways. Tracker workflows get renamed, CRM fields change, the call recorder's API shifts, warehouse schemas migrate. Any of the five sources drifting silently produces confident wrong pulls. The judge's spot-recompute catches value mismatches; add a pre-flight step to the skill that sanity-checks each source returns non-empty, in-range results.
Claims-registry discipline. The registry only protects you if it stays complete. Watch for the failure mode where hand edits during the human pass introduce numbers with no claims entry; the fix is re-running the judge on the final doc, not just the draft.
Commitment tracking hygiene. commitments.json is only as good as what gets written into it. After each review, spend ten minutes confirming it reflects what was actually said in the room, including asks that were granted or refused. Next quarter's most important section depends on it.

What this costs

This is the cheap end of the series to run and the expensive end to set up, and it is worth saying both plainly.

Token spend per run. Assume a template with six sections, each pull returning a few thousand tokens of query results and records, a draft pass, and a judge that re-runs five queries. That is a bounded, single-digit fan-out reading tens of thousands of tokens, well within a Pro or Max subscription's included usage. And it runs four times a year (twelve, monthly), not weekly, so even the account variant across twenty accounts stays modest. The risk case is an unscoped agent free-exploring the CRM; the section-by-section pulls in the skill exist to prevent exactly that.
Plan tier. Cloud routines and artifact publishing are subscription features; org-scoped artifact visibility specifically needs Team or Enterprise.
The setup cost, stated plainly. The real investment is the template (which is a product-thinking exercise, not a coding one) and the source wiring across five systems (which is an integration project, with credentials, query definitions, and one afternoon per source of verifying that "shipped" means shipped). Expect the first quarter's run to be interactive and iterative. The payback is every quarter after.

The four practical challenges

Setup at scale: here "scale" means breadth, not volume. Five source systems, each with its own MCP, credentials, and query semantics (Phases 0-2), and a template that has to encode what your execs actually ask.
Sharing with the team: artifact pre-reads plus the deck file (Phase 7), with the publish-surface and plan-tier caveats, and a human layout pass that stays in the loop by design.
Maintenance: template evolution, drift across five sources, registry discipline, commitment hygiene (Phase 8). Four sources of rot for a system that runs four times a year, which means rot is discovered at run time unless you pre-flight.
Cost: low and bounded per run; front-loaded in template design and source wiring, which is real engineering and product time that never appears in /usage.

The managed alternative

If you want this without building it, two adjacent categories exist. Data-driven deck tools like Matik automate pulling numbers into slide templates: connect sources, map fields, and recurring decks populate themselves. Customer success platforms like Gainsight generate account QBR content from the health and usage data they already hold. The trade is fair and worth naming: these are strong for standardized, recurring decks, especially the per-account variant at CS scale. What remains yours either way is the cross-system narrative (why the metric moved, told against what shipped and what customers said), the product-side evidence that lives outside the CS stack, and commitment continuity, the "what we said last time" thread that no template-filling tool tracks for you.

Doing this with Second Axis

Everything above is the do-it-yourself path. On Second Axis, QBR prep is a workflow in the marketplace: connect your analytics, tracker, CRM, and call recorder, choose the workflow, and set the goal ("quarterly product review draft with receipts, two weeks before the board date"). It runs on schedule from there, remembers last quarter's commitments, and monitors itself: broken sources, failed runs, and unsourced claims get found and alerted instead of surfacing in the meeting.