> ## Documentation Index
> Fetch the complete documentation index at: https://docs.minoa.io/llms.txt
> Use this file to discover all available pages before exploring further.
# Prove Value to Existing Customers
> Walk into check-ins, QBRs, and renewals with the number instead of the anecdote
There's an awkwardness built into post-sale work that nobody names out loud. You're the relationship — the person they call when something breaks, the one who's supposed to be on their side. You're also the auditor of a promise someone else made during a sales cycle you may not have been part of. And the evidence you need to settle it sits inside their systems, owned by people who have no particular reason to hand it over.
Most teams resolve that tension by not resolving it. Check-ins stay warm and vague, QBRs become product roadmap reviews, and the renewal arrives with a story assembled in a panic the week before. The alternative isn't harder, it's just earlier: keep one number current from day one, and every one of those conversations has a spine.
Don't rebuild the model. Continue it.
The step that makes everything else possible.
One metric a month beats a quarterly scramble.
A check-in, a QBR, and a renewal are not the same meeting.
Name the gap before they do.
Proof first, then the expansion it justifies.
## Start from the business case that was sold
Resist the urge to build something new. The business case from the sales cycle already has the use cases, the calculations, and the assumptions the customer agreed to — rebuilding it means re-litigating a model they already signed off on.
Add a **Value Realization Scenario** to that same business case instead. It copies the structure across and gives you a place to record what actually happened. [Start Tracking Realized Value](/pages/recipes/create-value-realization-scenarios) covers the mechanics end to end; this recipe assumes you've read it and is about the conversations that follow.
## Get the baseline before anything changes
This is the step that quietly determines whether any of this works, and it's the one that gets skipped, because at kickoff nobody is thinking about a renewal fourteen months out.
Send a kickoff baseline survey before implementation starts. You're capturing the current value of every metric the business case promised to move — while it's still measurable, and while the customer still remembers that these were the numbers the purchase was justified on. Once the rollout is underway, "what was it like before?" becomes a question nobody can answer honestly.
[Set Up Baseline Surveys](/pages/recipes/set-up-baseline-surveys) covers building the templates; your admin has probably already made a Kickoff one.
No baseline means no realized value — only current value, which proves nothing. If you've inherited an account that
never captured one, reconstruct it from the original business case inputs and get the customer to confirm the
numbers in writing before you build anything on top.
## Keep the cadence small
Monthly, one tracked metric per calculation, ten minutes. Values carry forward automatically, so a month you skip inherits the last figure you entered rather than dropping to zero.
Pair the numbers with [milestones](/pages/value-realization/milestones) — rollout complete, second team onboarded, integration live. Milestones are what explain the shape of the curve. A flat quarter with "regional rollout paused for their fiscal year-end" attached is context; the same flat quarter with nothing attached is a problem you'll be asked about with no answer ready.
If your data team has connected a warehouse, some of this lands on its own. See [Pull Live Data into Your Business
Case](/pages/recipes/pull-live-data-into-business-case).
## Open each conversation differently
Same underlying data, three genuinely different meetings.
One metric that moved and one milestone that landed. No deck, no Value Summary, no ceremony — just "handle time
came down another six percent last month, and the Manchester team went live." Thirty seconds at the top of a
call you were having anyway.
The purpose isn't to impress anyone. It's to make sure that by the time you're in a room that matters, the
number is something they already believe, rather than something you produced.
Lead with the realized-versus-estimated chart, and lead with the gap in whichever direction it runs.
This is the counterintuitive part. A lagging use case that you raise yourself, with a diagnosis and a plan, is a
partnership. The identical use case, raised by them because they noticed it in your chart, is a credibility
problem — and now everything else you said is being re-examined too.
Then go to the per-use-case breakdown. Where value concentrated tells you what to do more of, and it's usually
not what anyone predicted at signing.
Start around ninety days out, not three weeks.
Total realized benefit against what they paid. That's the headline, and it should be a realized number rather
than a projection — the whole point is that this figure isn't a forecast anymore.
The **Renewal Pitch** document is built for this: what they paid, what they got, and one specific ask. You'll
find it on the deal under **Docs** → **Shareable Templates**. [Upsells and
renewals](/pages/value-realization/upsells-and-renewals) covers how to time the scenario so it closes cleanly
against the term you're renewing from.
## Handle a bad number honestly
Sometimes the value isn't there. You can hide the estimated-value curve so the chart shows only what was realized, and there are moments where that's the right call — a board-facing readout that isn't the venue for a variance discussion.
Usually it's the wrong call. They know what was promised; it's in the business case they signed.
Name the gap first. **Churn Save** is written around exactly this order: what's at risk, then what did land, then a named cause, then a dated plan with owners against it. Not wins first, and never a version where the shortfall is quietly their fault for not adopting properly.
A customer who watches you open with the bad news, unprompted, tends to conclude the good news was probably true as well.
## Extend a good one
When the number is genuinely strong, the mistake is to spend the meeting celebrating it.
**Upsell & Expansion** puts the proof first — what they realized from what they already own — and then models the extension from the unit economics of that proof. If one team saved \$340k, the case for the next three teams is arithmetic they can check rather than a new pitch they have to evaluate from scratch.
Two things keep it credible. Label the extension as forward-looking and keep it conservative; the realized figure is the one carrying the argument, and mixing a projection into the headline undoes that. And make the ask specific — which team, how many seats, which use case, starting when. "There's more value available here" is a sentiment. "Add the Manchester and Leeds teams in Q3" is a deal.
Whichever direction the number went, you're having a conversation about evidence. That's the difference this makes
— not that the news is always good, but that it's never a surprise.
## Key takeaways
* **Continue the business case, don't rebuild it.** Re-modelling invites a re-negotiation of assumptions they already accepted.
* **The baseline is the whole thing.** Capture it at kickoff or you're measuring current state, not realized value.
* **Small and monthly beats big and quarterly.** Ten minutes a month, with milestones for context.
* **Raise the gap before they find it.** Self-reported bad news is a partnership; discovered bad news is a credibility problem.
* **Proof first, projection second.** Let realized value carry the headline and label the extension for what it is.