A baseline is the only step in a value model that can make your number smaller.
Which may explain what I found when I went looking for one.
I read the five pages currently ranking for "value realization framework." The word baseline does not appear in any of them. Not once, across 11,963 words. Tested against eleven synonyms, the idea surfaces twice, both times as the throwaway phrase "starting point," neither attached to anything measured. Two of those pages discuss ROI at length. One says ROI eight times without ever establishing what anything was compared against.
That is not a style complaint. It is the reason value stories collapse in the room where they matter.
A CFO does not challenge your conclusion. They challenge your denominator. "Twelve hundred hours saved, against what?" takes four seconds to ask and ends the meeting if you cannot answer it. Every generous assumption upstream of it survives everyone except the person who signs.
Most teams do not skip the baseline out of laziness. They skip it because by the time anyone needs the number, the before-state is twelve months gone and nobody wrote it down.
This framework puts it back.
What value realization actually is
Value realization is turning the outcome a customer expected when they bought into measurable, defensible evidence that the outcome occurred.
Two parts, and you need both:
- Realization. The customer gets the outcome.
- Recognition. The customer understands and agrees the outcome happened.
A customer can receive value without recognising it. That is why a heavily used product still faces a hard renewal: it became part of the workflow, but nobody translated that workflow into a result the budget owner can defend.
The inverse happens too. A customer may believe the product is valuable while the data does not yet support the story.
The chain you want is:
expected outcome → measurable change → credible evidence → acknowledged business value
That is a far stricter standard than an aha moment.
Product usage is not customer value
This is the distinction most frameworks blur, so here it is as a ladder.
| LEVEL | EXAMPLE | WHAT IT ACTUALLY PROVES |
|---|---|---|
| Activity | 86 users logged in | People accessed the product |
| Adoption | 71 users run the reporting workflow weekly | A workflow became habitual |
| Operational outcome | Weekly reporting fell from 5 hours to 90 minutes | Work changed |
| Business outcome | The team saves roughly 182 hours per quarter | The organisation benefits |
| Economic value | Those hours represent roughly $11,000 of loaded labour per quarter | The benefit has financial magnitude |
| Value proof | The VP Finance accepts the methodology and the baseline | The benefit survives scrutiny |
The first two matter. They are not the value.
This is also why NPS and CSAT should not be your primary value-realization metrics. They measure perception. A happy customer has not necessarily produced a measurable business outcome, and a customer producing a major outcome may still be unhappy about a support ticket. Keep the constructs separate.
A CFO does not renew because 87% of licensed users logged in last month. They renew because those users cut onboarding from 18 days to 11, removed 400 hours of manual work, or absorbed growth without another hire.
The evidence chain
Most frameworks describe value as a lifecycle. For customer success it is more useful as an evidence chain, because a chain shows you exactly where a claim breaks.

1. PROMISE: what did they believe they were buying?
Start before onboarding, and not with the feature list.
| WEAK | STRONGER |
|---|---|
| Implement automation | Reduce manual invoice processing |
| Adopt analytics | Cut reporting preparation time |
| Use the recruiting module | Reduce time to fill |
| Deploy customer success software | Identify retention risk before renewal |
| Enable the API | Reduce engineering work for integrations |
The left column describes what the product does. The right describes what the customer wants changed.
Your first artifact is a one-sentence value hypothesis:
Because we bought [product], we expect [business outcome] to move from [baseline] to [target] by [date].
If Sales cannot supply that sentence, the CSM writes it during success planning. A hypothesis written at month four is a reconstruction.
2. BASELINE: what was true before?
This is the step the category skips, so it gets the most space here.
A customer says: “Your platform saves us a lot of time.”
Useful. Not yet measurable. The only question that matters is compared with what?
If reporting took five hours before implementation and takes 90 minutes now, you have a baseline. If nobody recorded the five hours, you have a memory. Those are not the same thing and should never be presented with the same confidence.
| OUTCOME | BASELINE YOU NEED |
|---|---|
| Time saved | Previous hours per workflow |
| Cost reduced | Previous spend, or cost per unit |
| Productivity | Previous output per employee |
| Revenue | Previous conversion or output rate |
| Errors | Previous error count or rate |
| Risk | Previous incident frequency or expected loss |
| Cycle time | Previous days or hours |
Every baseline carries a source and a date. Compare:
“The customer said onboarding took about three weeks.”
with:
“Median onboarding duration from January to March was 20.4 days across 63 customers, from their implementation tracker.”
Both are usable. Only one survives a finance review.
3. OUTCOME: what movement counts as value?
Teams routinely replace outcomes with milestones. “Complete the integration” is a milestone. “Train 100 users” is a milestone. “Reach 80% feature adoption” is an adoption target. None is a business outcome.
An outcome describes something the customer wanted changed:
- Reduce monthly close from eight days to six
- Increase recruiter capacity from 22 to 30 roles
- Reduce average handling time by 90 seconds
- Cut manual reconciliation from 40 hours to 10
These are much harder to fake with a green health score.
4. DRIVER: what product behaviour should cause it?
Here adoption becomes useful, not as value but as a causal candidate.

Outcomes move slowly. Drivers give the CSM a leading indicator. If the customer wants 800 hours back this year and nobody has adopted the workflow that removes those hours, you can intervene in month two rather than discovering it in the annual review.
This is where adoption and value realization connect without becoming the same thing. Usage measurement itself belongs to your product adoption KPI.
5. EVIDENCE: how do you know it moved?
Every claim carries four fields:
| FIELD | EXAMPLE |
|---|---|
| Baseline | 5.0 hours per report |
| Current | 1.5 hours per report |
| Source | Workflow telemetry plus customer validation |
| Measurement date | 17 September 2026 |
Then label what kind of evidence it is. This is the part that makes a model defensible under challenge:
- Strongest. Direct measurement from an operational or financial system.
- Strong. A customer-owned metric, validated by the customer.
- Useful. Product telemetry connected logically to an outcome.
- Directional. A survey or interview estimate.
- Weakest. A vendor assumption with no customer validation.
Observed, customer-reported and estimated are all legitimate. They must never silently become interchangeable. The goal is not perfection. It is knowing which kind of evidence you actually hold when someone pushes back.
6. ECONOMICS: translate it into a business unit
You are not turning CSMs into analysts. You are making the benefit legible to whoever controls the budget.
| VALUE TYPE | EXAMPLE | CALCULATION |
|---|---|---|
| Time | Analyst hours eliminated | hours saved × people × periods |
| Cost | Vendor or process spend removed | previous cost minus current cost |
| Capacity | More work from the same resources | additional output × economic value |
| Revenue | Incremental revenue from the workflow | incremental volume × realised value |
| Risk | Expected loss reduced | exposure × change in probability |
| Quality | Rework or errors avoided | errors avoided × cost per error |
Worked, for time:

Now read the wording carefully. That is $74,880 of capacity value, not $74,880 saved. Unless headcount or external spend actually disappeared, claiming a cash saving overstates the result and hands the CFO an easy way to dismiss the whole model.
That distinction costs you nothing and buys you the room.
7. PROOF: can they defend it without you?
The final test, and the one most programmes fail.
If their CFO asked tomorrow, "why are we still paying for this?", could the customer answer without opening your deck?
A value programme has failed if the CSM understands the ROI and the economic buyer does not.
Notice what this rules out. The test is not whether the account is using the software, because a customer can be deep in the product and still go silent when their own CFO asks what it returns. Usage is not an answer to that question. The only thing that is, is a number the buyer can say out loud, with a baseline behind it they remember agreeing to.
Which is why proof has to be built into the relationship rather than assembled for it. A CSM carrying 200 accounts cannot construct a bespoke economic model for each one at renewal. What scales is a small library of outcome patterns, each with a known baseline shape and a known unit, applied again and again. Handcrafted value stories do not survive contact with a real book of business.
The value realization record
For every strategic outcome, maintain this:
| FIELD | EXAMPLE |
|---|---|
| Desired business outcome | Reduce analyst reporting workload |
| Executive owner | VP Finance |
| Baseline | 5 hours per report |
| Target | Under 2 hours per report |
| Current | 1.5 hours per report |
| Product driver | Automated reports |
| Driver adoption | 91% |
| Evidence type | Workflow telemetry, customer validated |
| Annualised value | Roughly $74.9K capacity |
| Confidence | High |
| Last validated | 17 September 2026 |
| Next review | 15 December 2026 |
A health score answers should we pay attention to this account?
A value record answers what measurable reason does this customer have to keep paying us?
Different questions, and the second one is the one renewals turn on.
A worked example, end to end
You sell support automation. During the sales cycle the customer says:
“Our support team cannot keep adding people every time ticket volume grows.”
- Promise: absorb volume growth without proportional headcount.
- Baseline: 10 agents handling 20,000 tickets per month, so 2,000 per agent.
- Outcome: increase tickets handled per agent.
- Driver: automated resolution of repetitive tickets.
Three months later: 24,000 tickets, still 10 agents. That is 2,400 per agent, a 20% productivity improvement.
Now do the part most teams skip. Establish that the improvement is connected to the product. Automated resolution handled 4,100 tickets last month and staffing stayed flat, which is useful operational evidence.
You might now estimate the value of the headcount that was not added. But you should not claim a saving unless the customer agrees the hire would otherwise have happened.
So the defensible statement reads:
Ticket volume rose 20% while support headcount stayed flat. Automated resolution handled 4,100 tickets last month. The customer estimates this deferred one planned support hire, worth roughly $72K in annual loaded cost.
That sentence survives a finance review. “Automation ROI: 842%” does not.
The maturity ladder
| LEVEL | WHAT THE TEAM REPORTS |
|---|---|
| 1. Activity | “They use the product.” |
| 2. Adoption | “The workflow is embedded.” |
| 3. Outcome | “A business metric changed.” |
| 4. Economics | “We can quantify the magnitude.” |
| 5. Proof | “The customer agrees and can defend it.” |
Mistaking level 2 for level 5 is one reason renewals still surprise teams when the account looked well adopted. Nobody had tested whether the buyer could defend the spend.
What this is not
Not time to value. Time to value asks how quickly the customer reached meaningful value. This asks what the value was, how much it was worth, and whether it can be proven. A customer can hit first value fast and never accumulate enough to defend renewal. Setting and hitting that first milestone is covered in time to value targets for CSMs.
Not product adoption. Adoption is an input, value is an outcome. When adoption climbs from 30% to 90%, the next question is what changed in the business because it did.
Not a health score. A health score aggregates signals about an account. A value record documents specific outcomes. You might hold a health score of 82 and underneath it: reporting time down 70%, 1,248 hours removed annually, executive validation confirmed, second outcome stalled. That is far more actionable than an 82. Score construction and the reasons scores go wrong belong to how to build a customer health score and why health score accuracy is poor.
Not the QBR. The QBR is the presentation layer for evidence you are already maintaining, not the afternoon a CSM reconstructs value from four months of activity. What to do when that meeting stops working is covered in the QBR template.
Not the renewal forecast. Value evidence should inform commercial decisions without becoming them. For renewal, the question is whether the customer can defend continuing the investment. For expansion, whether the existing use case has produced enough value to give a second one a credible case. The mechanics live in SaaS renewal management and the expansion pipeline model.
Six failure modes
Starting from the data you have rather than the outcome the customer bought. This produces dashboards full of logins, feature counts, tickets and NPS, because those are the easy things to measure.
Never recording the baseline. The failure the ranking pages have institutionalised.
Converting activity straight into money. Skipping the causal step between “they used it” and “the business changed” is where credibility dies.
Double counting. If 1,248 hours saved and $74,880 of capacity describe the same outcome, they are one number expressed two ways. Do not add them.
Waiting until renewal. A value story assembled in the last 30 days looks exactly like what it is.
Being the only party who believes the calculation. If the economic buyer rejects your assumptions, a mathematically perfect model is worth nothing.
What if there is no baseline?
Do not invent one. You have four honest options:
- Recover it from historical data in their systems.
- Ask for a retrospective estimate and label it customer-reported.
- Start measuring now and prove forward movement from today.
- Use a reference benchmark, labelled explicitly as a benchmark rather than as their baseline.
The wrong move is false precision. This:
Estimated from a customer interview. Confidence: medium.
is more defensible than this:
ROI: 427%
built on assumptions nobody can trace.
What if it cannot be turned into money?
Do not force it. Cycle time, risk exposure, employee effort, error frequency, compliance posture and strategic capacity are often the outcomes that matter most, and converting them badly is worse than not converting them.
Track the unit the customer cares about. Monetise only where a credible conversion exists.
The purpose is not to attach a dollar sign to everything. It is to make the customer’s result measurable and defensible.
Review cadence
Not only at the QBR, and certainly not only before renewal. Match the cadence to the outcome.
A workflow metric may move weekly. An onboarding outcome gets validated at 30, 60 and 90 days. A financial outcome needs a monthly or quarterly period to be meaningful. An executive outcome is reviewed quarterly.
How to roll this out
Start with one outcome per strategic account, not ten. Build the seven fields. Run it on a small group of renewals first, then ask the customer to challenge the calculation and track where your evidence breaks.
Then standardise an outcome library for your repeatable use cases. The goal is not hundreds of bespoke ROI models. It is a small set of defensible value patterns your team applies again and again. Past a few hundred accounts there is no other option, because the bespoke version quietly becomes the thing nobody has time to keep current.
Where GainTrace fits
The hard part of value realization is rarely writing the final sentence. It is keeping the evidence current.
The data needed to prove an outcome lives across product analytics, CRM activity, support systems, billing records and customer conversations. GainTrace brings those post-sale signals together at the account level, so a team can see what changed rather than reconstructing it quarterly from memory.
The honest caveat matters more than the pitch: an account signal is not automatically business value. Usage growth, fewer tickets, stronger adoption or an expansion signal becomes evidence only when it is tied back to the outcome the customer actually bought, with a baseline recorded and a source attached. No platform does that step for you, ours included. The framework is what makes the signal mean something.
GainTrace is free on your first 25 companies.
No credit card needed | 14-day free trial
The test
Before your next renewal, take one account and answer six questions:
- What did this customer buy us to change?
- What was the baseline?
- What changed?
- What evidence proves it?
- What is that change worth?
- Has the customer agreed?
If you cannot answer all six, you do not have a value realization problem yet. You have a value story.
Stories get challenged when budgets get tight. Evidence survives.
Frequently asked questions
- What is a value realization framework?
- A repeatable system for defining the business outcome a customer expects, recording the baseline, measuring what changes after implementation, translating that change into a business unit, and validating the result with the customer. The baseline is the step that separates a framework from a narrative.
- How do you measure value realization?
- Compare a documented baseline against the current result, preserve the source and date of both, and express the difference in the unit the customer cares about: time, cost, capacity, revenue, risk or quality. Measure the business outcome rather than product activity.
- Is product adoption the same as value realization?
- No. Adoption shows customers are using the product. Value realization shows what changed in their business because they did.
- What is the difference between time to value and value realization?
- Time to value measures how quickly a customer reached meaningful value. Value realization measures what that value was, how much was achieved, and whether it can be proven. A fast first value does not guarantee enough cumulative value to defend a renewal.
- Is ROI required for value realization?
- No. Some outcomes are best expressed in cycle time, capacity, quality or risk. Convert to money only where the conversion is credible and useful to the customer. Forcing a dollar figure onto an outcome that does not support one is how models get dismissed.
- Who owns value realization?
- Customer Success usually orchestrates it, but the evidence comes from several places. Sales captures the original promise, Product creates the behaviour that produces the outcome, Finance often holds the baseline, and the customer validates whether the outcome mattered.
- How often should value be reviewed?
- At the cadence of the outcome, not only at renewal. Operational outcomes may move weekly or monthly. Financial and executive outcomes are typically validated quarterly.
- Can AI automate value realization?
- It can do the expensive work around the edges: extracting promised outcomes from sales calls, finding commitments buried in meeting notes, flagging accounts whose value has not been validated recently, and drafting the executive summary. The economic model itself should stay inspectable. If a customer disputes the number, a CSM has to be able to answer where it came from, and that requirement does not disappear because the calculation arrived through a model.