The QBR Where Nobody Argued About the Data

Emily Goh · 2026-11-12

It's two weeks before QBR. The CEO sends a note to the leadership channel: "Can everyone send me their numbers by Friday?" By Friday there are three versions of pipeline, two versions of new ARR, and a Marketing slide that counts 412 MQLs while the Sales slide counts 260. The QBR itself turns into an hour of "whose number is right?" and ten minutes on what to do next.

So, how do you prepare data for a QBR? Start two weeks out, not two days. Pick the handful of numbers that will go on the slides. Write down in plain English what each one means and who owns it. Check the records against those definitions before anyone builds a slide. Fix what you can, footnote what you can't, and bring the rows behind every number. Do that, and the meeting is about decisions instead of the data.

Below is a made-up use case that walks through it, one question at a time.

The setup: two weeks out, five numbers, three versions

Picture a hypothetical B2B software company with about 150 people. Dana runs RevOps. The QBR deck has five numbers that matter: new pipeline created, Commit for next quarter, new ARR closed, win rate and MQLs.

Last quarter, every one of those numbers was challenged in the room. Not because anyone lied. Because each team pulled its own report, with its own filters, on its own day. This quarter Dana tries something different. Instead of collecting slides, she runs the prep as a set of questions the team answers in order.

We've written before about what the board actually wants to see at QBR. This post is about the work before the slides.

Questions 1 and 2: Which numbers, and what do they mean?

Which numbers are actually going on the slides? Dana asks each leader for the two or three numbers they plan to present. She gets eleven. After one short call they agree on five shared numbers, plus one per team. Everything else goes in the appendix.

That step alone removes half the arguments. You cannot fight about a number that isn't on the slide.

What does each number mean, in writing? For each of the five, Dana writes two sentences and puts a name next to it. For example:

• New ARR closed: counted in the quarter the contract is signed, at the first-year contract value, excluding one-time services. Owner: the CFO.
• Commit: a deal is in Commit when the buyer has confirmed budget, a signature date is set, and the paperwork is with legal. Owner: the head of Sales.
• MQL: a contact who meets the scoring threshold, is not an existing customer and is not a duplicate. Owner: the head of Marketing.

Then she sends the list to every owner and asks one question: "Is this how you count it today?" Two of the five come back with edits. That's the point. Better to find out on day 3 than in the room on day 14. If your team has never written down what a closed deal means, start with the definition nobody writes down.

Question 3: Does the data follow the definitions?

Now Dana has rules. The next question is whether the CRM follows them.

She checks each number against its definition. Say Commit shows $2.4M across 31 deals. When she checks those 31 deals against the written rule, 9 have no signature date and 4 have a close date that already passed. So the honest Commit is not $2.4M. It's the deals that pass, plus a clear note about the ones that don't.

The same check on MQLs finds that 70 of the 412 are existing customers who filled in a webinar form. That's why Marketing counted 412 and Sales counted fewer. Both reports were "right." They were counting different things.

This is the step most teams skip. They check that the number looks reasonable, not whether the records behind it meet the definition. Those are very different checks.

Questions 4 and 5: What about the failures, and where's the proof?

What do we do with the records that fail? Dana sorts them into three groups:

1. Fix before QBR. Missing close dates, wrong stages, obvious duplicates. The owner of each record gets a short list with a deadline.
2. Footnote on the slide. Things that can't be fixed in time. "Commit excludes 9 deals with no signature date, worth $610K."
3. Raise as a process issue. Patterns, not one-offs. If existing customers keep counting as MQLs, that is a form or scoring problem, and it goes on the agenda as a fix, not a blame.

The tone matters here. The question is "what does this record need?", not "who messed this up?" That keeps reps and marketers helping instead of defending.

Where's the proof if someone asks? For every number on the slide, Dana keeps the list of records behind it and the definition it was checked against. When a board member asks, "Why is Commit lower than last month's preview?", the answer takes thirty seconds: here's the rule, here are the 13 deals that didn't meet it, here's what each one is missing. That is what being able to trace a number looks like in practice.

The QBR runs differently. Nobody argues about whose pipeline figure is real, because there is only one, with a written definition and the rows behind it. The hour goes to the real questions: where to invest, which deals need executive help, and what to change in the process.

Do this before your next QBR

You don't need new software to try this. You need two weeks and a shared doc.

1. Day 1: agree on five shared numbers that will go on the slides. Everything else goes in the appendix.
2. Day 2 to 3: write a two-sentence definition and an owner for each. Send it to the owners and ask, "Is this how you count it today?"
3. Day 4 to 6: check the records behind each number against its definition. Count how many pass.
4. Day 7 to 10: fix what you can, footnote what you can't, and log the patterns as process issues.
5. Day 11 to 14: build the slides from the checked numbers, and keep the record lists ready for questions.

Where Gohvio fits

Gohvio is built for the checking step. You upload your own guardrails, the definitions your teams actually use, as a document. A person approves them, and each change is recorded with who changed it and when. Gohvio then checks your CRM data against those guardrails and shows what is broken, what it does to pipeline and forecast, and the rows behind every finding. It is read-only, so it reads your CRM and does not change it.

That is days 4 to 6 above: the records checked against the definitions, with the evidence attached.

Stop debating your data. Start making evidence-based decisions.