Kill the 40-Slide Board Dump: 6 Metrics Computed at the Source

Forty slides go to the board and four numbers on them are typed by hand. NRR from one spreadsheet, CAC payback from another, magic number from a third that a former analyst built and nobody fully understands, coverage from a fourth. Four metrics, four sources, zero of them queryable. When a board member asks what is in that NRR number, the honest answer is “let me get back to you,” and everyone in the room hears the number lose a little authority.

The fix is boring and it is the whole game: compute the four numbers as queries against the CRM and the GL, on a schedule, so the board metric is the same object your team looks at on a Tuesday. Not a snapshot someone reconstructed for the deck. The live number, with the definition baked into the query where anyone can read it.

Every board metric worth trusting climbs the same four rungs. You define it in writing, you instrument the source so the fields exist, you compute it as a scheduled query with the definition in a comment, and you reconcile it against finance so the gap is explained instead of hidden. Skip a rung and the number reverts to a typed-in guess. Scroll the ladder, then I will show the worked NRR and the queries under each rung.

1. L4Reconcileexplained gap

   The CRM number and the finance number will differ because they run on different clocks. Do not force them equal. Explain the gap in a documented reconciliation so a director drilling from 78.6 percent NRR into the churn line lands on the same six accounts finance sees.

2. L3Compute3x daily

   Write each metric as a commented query on a schedule. Three refreshes a day keeps the board number and the Tuesday operating number within hours of each other. The definition rides in the query comment, not in an analyst head.

3. L2Instrument1 join

   Make the source fields real. ARR by account lives in the CRM the sales team commits against; S&M spend lives in the GL. Join them once on period so every metric reads from one join, not four private spreadsheets.

4. L1Define1 row/metric

   Pin one row per metric: exact formula, source fields, single owner. This is the data dictionary the board can read. Contraction means downgrades within a logo, churn means the logo left, expansion means net-new ARR on an existing logo. If two people compute NRR differently, this is where you catch it.

The four numbers and where they actually live

Each of these has a clean definition that maps to fields you already have. The problem is never the formula itself; it is that the formula lives in a slide instead of in the system.

Metric	Formula	Source fields
NRR	(starting ARR + expansion − contraction − churn) ÷ starting ARR	ARR by account, period over period
CAC payback	S&M spend ÷ (new ARR × gross margin)	GL spend, new-business ARR
Magic number	net new ARR ÷ prior-quarter S&M spend	ARR delta, GL spend
Pipeline coverage	open pipeline ÷ target, target ÷ win rate	pipeline by stage, historical win rate

None of these needs a data science team. They need the ARR figures pulled from the same source the sales team commits against and the spend pulled from the GL, joined once, refreshed on a schedule. The architecture is one hop: two sources, one join, one scheduled query per metric, one place everyone reads it.

Each number carries a threshold the board already knows, and each threshold has a published source. Put them on the same table as the formula so the metric and the bar it clears live together.

Metric	2026 threshold	Source	Reads green when
NRR	100 percent or better	Benchmarkit, 2026	Base self-grows without new logos
CAC payback	Under 18 months	Bessemer Cloud 100, 2026	New ARR earns back its S&M inside 18mo
Magic number	0.75 or better	Bessemer	Prior-quarter S&M spend paid back
Pipeline coverage	1 divided by win rate	Clari, 2026	At a 19 percent win rate (Ebsta/Pavilion 2025), that is 5.3x

The reason four metrics turn into four spreadsheets is organizational, not technical. NRR gets owned by whoever runs renewals, CAC payback by whoever owns the marketing budget, magic number by finance, coverage by sales ops. Each builds their number in their own tool with their own definition, and the four never touch until the deck forces them into the same room. So the “let me get back to you” is not laziness; it is that the person presenting the slide did not build three of the four numbers and cannot answer for them. Computing all four off one join does not just make them fresh. It makes them answerable, because there is one artifact and one owner for the definitions instead of four private versions of the truth.

Coverage is the one everyone computes wrong

Pipeline coverage gets quoted as “we need 3x.” Three times what, computed how? The honest version is coverage equals one divided by your win rate (Clari, 2026 coverage framework). B2B win rates fell to 19 percent in 2025, down from about 29 percent the year before (Ebsta and Pavilion, 2025 B2B benchmarks), which puts required coverage at 5.3x for most teams still chanting 3x. If you close 25 percent of qualified pipeline, you need 4x coverage to hit target, not 3x. If you close 40 percent, 2.5x is plenty and demanding 3x means you are telling reps to stuff the pipeline with deals that inflate the ratio and die in stage two.

win rate = 25%  ->  required coverage = 1 / 0.25 = 4.0x
win rate = 40%  ->  required coverage = 1 / 0.40 = 2.5x

Put your own win rate in and watch the required number move:

Coverage you have vs coverage you need

open pipeline÷quota=3.6x

coverage

Open pipeline ($)$3.60MQuota / target ($)$1.00M

TryHealthy (3.6x)Thin (2x)

Below ~3x you are almost certainly going to miss unless win rates are unusually high. Above ~5x the number is either sandbagged pipeline or wishful staging. The healthy band is 3 to 4x.

coverage: 3.6x

The board number “3x coverage, on track” is meaningless without the win rate next to it. Compute both from the CRM, in the same query, and coverage stops being a vanity ratio and becomes a capacity check. This is why it belongs at the source: the win rate that sets the target is already sitting in your closed-won and closed-lost history. Typing 3x into a slide throws that away. I go deep on why the flat ratio lies in the coverage-ratio trap.

A worked NRR that ties out

NRR is the number boards trust most and the one most likely to be quietly wrong, because expansion and contraction get bucketed by hand. Compute it from the ARR-by-account table and it ties out every time.

Starting ARR (cohort, start of period)   $20,700,000
  + expansion                             $1,900,000
  - contraction                            ($740,000)
  - churn                                ($5,600,000)
  = ending ARR from cohort               $16,260,000
  NRR = 16,260,000 / 20,700,000 = 78.6%

That 78.6 percent is a real number from a real book, and it is below the 100 percent line where a business self-grows. Move the pieces yourself and see how sensitive NRR is to the churn line:

NRR from the ARR-by-account table

starting ARR+expansion−churn÷starting ARR=110.0%

net retention

Starting ARR ($)$1.00MExpansion ($)$220kChurn + contraction ($)$120k

TryElite (112%)Leaking (92%)

Above 100% the existing book grows on its own before a single new logo signs. Below 100% you are running up a down escalator: new sales have to refill the leak before they add anything.

net retention: 110.0%

The value of computing it at the source is that the board can drill from 78.6 percent straight into the churn line and see the six accounts that make up most of the $5.6M. In a slide, 78.6 percent is a dead end. As a query, it is the first click of an investigation. The waterfall makes the shape obvious:

View as table

Item	Value
Starting ARR	20,700K
Expansion	1,900K
Contraction	740K
Churn	5,600K
Ending ARR	16,260K

CAC payback is the efficiency line

CAC payback under 18 months is the efficiency line for 2026 (Bessemer Cloud 100, 2026). It is S&M spend divided by new ARR times gross margin, and it is the one board members increasingly lead with because it says whether growth is affordable. Benchmarkit’s 2026 SaaS metrics put median payback for growth-stage B2B in the 15 to 20 month band (Benchmarkit, 2026), so anything past 24 months reads as a spend problem the board will name before you do. Compute it from the GL spend and the same new-business ARR the sales team commits against:

Months to earn back the cost of a new customer

S&M spend÷( new ARR×gross margin )=10

months to payback

S&M spend / period ($)$600kNew ARR won ($)$900kGross margin80.0%

TryEfficient (10mo)Bloated (28mo)

Under 12 months is efficient, 12 to 18 is normal for mid-market, past 24 months you are buying revenue faster than it pays you back. Watch this before you scale spend.

months to payback: 10

The threshold only means something if the number under it is computed the same way every quarter, which is exactly what you lose the moment the metric becomes a manual entry in a deck.

Refresh on a schedule, expose the definition

Two rules make this durable. Refresh the four metrics on a fixed schedule, three times a day is plenty, so the board number and the operating number are never more than a few hours apart. And write the definition into the query as a comment, so the formula is not tribal knowledge trapped in a former analyst’s spreadsheet.

-- NRR, cohort basis. Definition: (start + expansion - contraction - churn) / start.
-- Refreshed 3x daily. Owner: RevOps. Do not edit without updating the board data dictionary.
SELECT
  SUM(starting_arr)                                             AS start_arr,
  SUM(expansion_arr)                                            AS expansion,
  SUM(contraction_arr)                                          AS contraction,
  SUM(churn_arr)                                                AS churn,
  (SUM(starting_arr) + SUM(expansion_arr)
    - SUM(contraction_arr) - SUM(churn_arr)) / SUM(starting_arr) AS nrr
FROM arr_by_account
WHERE period = :board_period;

Here is how I would stand up the whole board-metric layer, in order:

1. 1

   Pin the definitions in writing

   One row per metric: formula, source fields, owner. This is the data dictionary the board can read. If two people compute NRR differently, this is where you find out.

2. 2

   Join ARR and GL spend once

   ARR by account from the CRM, S&M spend from the GL, joined on period. Every metric reads from this one join instead of four private spreadsheets.

3. 3

   Write each metric as a commented query

   The definition lives in the query comment, not in an analyst head. Anyone can open it and read exactly what the number means.

4. 4

   Schedule the refresh 3x daily

   The board number and the operating number are never more than a few hours apart. No snapshot, no reconstruction for the deck.

5. 5

   Make the deck a link, not a retype

   The slide pulls the live number or links to it. When a board member asks what is in it, the answer is a click into the drill, not a callback.

	Typed into the slide	Queried at the source
Where the definition lives	A former analyst spreadsheet	A comment at the top of the query
"What is in this number?"	"Let me get back to you"	Drill straight into the accounts behind it
Freshness	As of whenever the deck was built	Within hours, refreshed 3x daily
Consistency quarter to quarter	Whatever the current analyst did	Identical formula, version-controlled
Board trust	Erodes on the first "get back to you"	Compounds; the number defends itself

The definitions drift is the real risk, not the math

The scary failure is not a wrong formula in one quarter. It is the same metric computed three different ways across three quarters, so the trend line the board reads is measuring your definition changes instead of your business. An analyst leaves, the next one buckets contraction slightly differently, and NRR “improves” four points on a change nobody made to the actual book. Nobody catches it because the number lives in a slide and the old formula left with the old analyst. A query with the definition in a comment and a version history in git makes that drift visible: if the number moves, either the business moved or the query changed, and you can see which in the diff.

This is why the data dictionary is the first step of the build rather than an afterthought. It is the contract that says contraction means downgrades within the same logo, churn means the logo left entirely, and expansion means net-new ARR on an existing logo, and it says so in one place every query reads. Without that contract, four honest people compute four honest NRRs and the board averages them into a number that means nothing. With it, there is one NRR, its definition is a click away, and a change to the definition is a reviewed commit, not a silent overwrite.

So pick the metric your board leans on hardest and move it to the source this quarter. The thresholds (CAC payback under 18 months, NRR over 100 percent, magic number over 0.75) only carry weight when the number under them survives a change of analyst, and a commented, version-controlled query is the only thing that guarantees it will.