The RevOps Dashboard That Reconciles: A Claude Agent Builds One Number Set from CRM, Ads, Product, and Billing

Write the metric definitions before you touch a revops dashboard tile

Sit the CRO, the CMO, and finance in one room for ninety minutes and leave with six definitions written in sentences. Pipeline created: deals that reached the qualified stage this period, counted at qualification date, amount from the CRM. Pipeline coverage: open qualified pipeline with a close date in the quarter, divided by remaining quota. CAC by channel: paid spend in the period divided by new customers whose first touch was that channel, first touch from the CRM's original source field. Win rate: closed-won divided by closed-won plus closed-lost, by close date. NRR: this month's recurring revenue from customers who were paying twelve months ago, divided by what they paid then, from billing. Each one names a formula, a source of truth, and an owner.

The definitions template below is the shape. The point of the meeting is not the formulas, which are standard; it is the source-of-truth column. When marketing's attribution tool and the CRM disagree on how many customers a channel produced, one of them is the number and the other is a delta to explain. Deciding that once, in writing, with names attached, is the entire reason the rest of this play works.

Save it as metrics.md in the repo. It is the file the agent reads first on every run, and it is the file the CRO reads when a tile looks wrong. A definition change is a commit, with a date and an author, so when Q3's pipeline number differs from Q2's you can see whether the business changed or the formula did.

Connect every source read-only over MCP, and check that the joins exist

Connect HubSpot or Salesforce and confirm the agent can list deals with stage history, amounts, original source, and dates. Connect billing: Stripe has an official MCP server (listed in the MCP directory) that exposes customers, subscriptions, and invoices; if revenue lives in a warehouse, Snowflake's server or a Postgres connection does the same job. Ad spend is the least glamorous part: most teams export LinkedIn and Google Ads spend by campaign and day into a folder the agent reads, and move to the APIs later if the export ritual breaks.

Then check the joins before you compute anything. CAC by channel needs a customer in billing to match a company in the CRM, which needs a shared key, usually the domain. NRR needs the customers who were paying twelve months ago, which needs billing history, not a current snapshot. Run the agent once with the instruction 'list every join you could not make and what percentage of records it affects' and fix the worst gap first. A dashboard built on a 60% join rate is a dashboard that will be wrong in a way nobody can see.

The agent reads everything and writes only files and a Slack message. It does not update a CRM field to make a join work, does not tag deals with a channel it inferred, and does not create records in billing. The hygiene agent proposes those fixes for a human to approve; this one reports what it found and computes with what is there.

• Reads: CRM deals with stage history, amount, original source, create/qualify/close dates, associated company domain
• Reads: paid spend by channel, campaign, and day; new-customer first-touch source from the CRM
• Reads: billing customers, subscriptions, invoices, and cancellations with dates; product usage per account if you have it
• Reads: metrics.md and last week's computed table, so the page shows movement and the diff has a baseline
• Writes: dashboard/index.html, data/YYYY-MM-DD.json, and one Slack post. Never a field in any source system

Write the brief so every number arrives with its formula and its deltas

The brief has two rules that make the page trustworthy. First: compute each metric exactly as metrics.md defines it, from the named source of truth, and print the formula and the row count beside the number. A tile that says 'Pipeline created $2.4M' is a claim; a tile that says '$2.4M, 61 deals reached Qualified between Sep 1 and Sep 7, HubSpot' is a fact someone can check in two minutes. Second: for every metric where another tool reports the same concept, record that tool's number and the delta, and never blend them. The reconciliation table is the part of the page the leadership team will actually read.

Give it a tolerance per metric and a rule for what to do when the delta exceeds it. A 3% gap between the CRM's pipeline and the attribution tool's is noise from timing; a 30% gap for two consecutive weeks is a definition problem or a broken sync, and the brief tells the agent to name the metric, the two numbers, the likely cause from what it can see (records missing a source, deals with no close date, customers with no matching domain), and the owner from metrics.md. It does not choose a winner. Resolving a disagreement is the owner's job; making it visible on Monday morning is the agent's.

Tell it what the page is not. No forecast, no commentary on whether the numbers are good, no recommendations. The forecast brief and the pipeline digest do the narrative work. This page is the number set they both cite, and the moment it starts editorializing, it becomes one more opinion in the meeting instead of the thing the opinions are about.

Every Monday at 6:00am {{TIMEZONE}}, rebuild the revenue metrics page for the period ending yesterday.

Read metrics.md first. It defines each metric's formula, source of truth, owner, tolerance, and refresh cadence. Compute every metric exactly as written, from the named source only. If a source or a required field is unavailable, report the metric as UNAVAILABLE with the reason; do not substitute another source.

Read from {{CRM}}: deals with stage history, amount, original source, company domain, and create, qualify, and close dates for the trailing 13 months.
Read from {{ADS_FOLDER or ADS_API}}: spend by channel, campaign, and day for the trailing 13 months.
Read from {{BILLING}}: customers, subscriptions, invoices, and cancellations with dates for the trailing 13 months; match customers to CRM companies on domain.

For each metric, produce: the value for the period, the same value for the prior period and the same period last year where the definition allows, the formula quoted from metrics.md, the record count behind it, and the source.

Reconciliation: for each metric, also record what every other connected tool reports for the same concept (for example: attribution-tool opportunities vs CRM qualified deals; billing MRR vs CRM closed-won ARR / 12). Print the delta in absolute and percentage terms. Do not average, blend, or pick between sources. If a delta exceeds the metric's tolerance, add a row to the exceptions list with: metric, the two numbers, the most likely cause visible in the data (unmatched domains, missing source field, deals with no close date, timing), and the owner from metrics.md.

Joins: report the match rate for every join (billing customer to CRM company, new customer to first-touch channel). A join below 90% is an exception.

Write:
1. data/{{DATE}}.json with every computed value, count, and delta.
2. dashboard/index.html: one page. Six metric tiles with value, period change, formula, count, and source. A trend table for the trailing 13 periods. The reconciliation table. The exceptions list. A definitions section that reproduces metrics.md verbatim. Ink on paper, no charts library, no external requests.
3. A Slack post to {{REVOPS_CHANNEL}}: each metric with its change, the exceptions with owners, and the join rates. No commentary on whether the numbers are good.

Write nothing to any source system.

Build the page as one static file, not a BI project

The dashboard is a single HTML file the agent writes every Monday: six tiles, a trend table, the reconciliation table, the exceptions, and the definitions, in that order. No chart library, no login, no external requests, so it opens from a shared drive or an internal URL in under a second and prints to one page for the board pack. The agent builds it from a template you review once; the numbers change weekly, the layout does not. If you want a chart, a table of thirteen periods with a sparkline drawn in inline SVG is enough, and it is the agent's job to draw it, not yours.

Resist the pull toward more tiles. Six metrics that everyone agrees on and can trace to a formula are worth more than forty that reproduce every tool's own dashboard. When someone asks for a seventh metric, the answer is a definition in metrics.md with an owner, which is a harder ask than 'add a tile', and that friction is a feature. Every metric on the page should have someone who will defend its formula in the meeting.

If the team already lives in Google Sheets, write the same table to a Sheet instead of an HTML page and let the page be the printable version. What matters is that the values come from one run against one definitions file, so the Sheet, the page, the Slack post, and the board slide all say the same number for the same week. The funnel pillar is the map of which of these metrics belongs to which stage.

Run the diff on Monday and work the exceptions, not the tiles

Schedule the run for 6am Monday as a scheduled Claude Code job so the page and the Slack diff are waiting before the leadership meeting. The diff is short on purpose: six metrics with their movement, the exceptions with owners, and the join rates. If the diff has no exceptions, the meeting starts with the decisions. If it has two, the two owners come to the meeting knowing which definition or which sync they need to rule on, and the arithmetic conversation is over before it starts.

Run the first three Mondays by hand with the RevOps lead and read every exception against what they know. The first run will find things: the 40 deals with no original source that make CAC by channel undercount every channel, the billing customers whose domain is a personal email, the attribution tool counting re-opened opportunities as new. Each is either a data fix (route it to the hygiene agent), a definition fix (a commit to metrics.md), or a known gap you write into the definitions section so nobody rediscovers it in November.

Watch the exceptions list shrink week over week. That shrinking line is the real output of the play. A reconciliation table with zero exceptions for a month means the company has one definition of its numbers and every tool is being held to it, which is what 'single source of truth' was supposed to mean before it became a vendor slogan.

Review the definitions quarterly, and version every change

Once a quarter, read metrics.md with the same three people who wrote it. Definitions drift because the business does: a new self-serve tier means 'customer' needs a floor, a partner channel means CAC needs a new bucket, a move to annual billing changes what NRR looks like month to month. Change the file, commit it with a note, and have the agent recompute the trailing thirteen periods under the new definition on the next run, so the trend line is consistent and the page says when and why the formula changed.

Keep the old computations. The data folder holds a JSON per week, so 'what did we report to the board in March' is a file, not a memory, and 'what would March have looked like under the new definition' is one instruction to the agent. That history is also how you catch a broken sync: a metric that steps 20% in one week with no business explanation is a source problem, and the weekly JSONs show the exact week it started.

Publish the definitions inside the company. A one-page 'how we count' document, generated from metrics.md, kills more Slack threads than any dashboard. When a new sales leader asks why their pipeline number differs from the page, the answer is a link to the formula and the source, and the conversation moves to whether the definition should change, which is the right conversation to be having.