Table of Contents
Picture a warehouse management system sold into a mid-sized distribution company. Before the system, a single pick might cost the equivalent of ten euros in labor and time. After a proper implementation, with better pick paths, better slotting, and less time spent walking around looking for stock, that same pick might cost three euros. This improvement highlights the importance of value based pricing in maximizing efficiency.
Case studies back this up. A well-run WMS rollout can add fifty to a hundred extra picks per hour per worker, and comparisons of picking methods alone have shown picking-time reductions of more than 25 percent, depending on the method chosen.
Understanding these metrics is crucial for implementing value based pricing effectively.
What almost never exists is a system that measures this continuously, for that specific customer, and shows it back as a living number rather than a one-time case study written by a vendor’s marketing team six months after go-live. That is the product value meter.
Not an ROI calculator filled in once during the sales cycle, but an instrument built into the product that tracks the before state, tracks the after state, and keeps updating the gap between them for as long as the customer runs the system.
This is also, in effect, the instrumentation layer that outcome-based pricing needs to exist honestly, not just as a slide in a sales deck.
Why This Matters More Than a Nice ROI Dashboard
The obvious use is sales and renewal conversations. Right now, most vendors make a value argument once, during the deal, using a projection. A year later, the renewal conversation is mostly a negotiation about price, because nobody kept the original promise measurable.
A value meter turns that projection into an ongoing, defensible fact: this account went from ten euros a pick to three euros a pick, and here is the trend line to prove it.
The less obvious use is that it makes value-based pricing far easier to defend. One of the hardest parts of pricing this way is proving that the price charged for a result reflects real value delivered, rather than an arbitrary number tied to seat count or feature tier.
A growing share of SaaS companies now build hybrid pricing that folds in some value or outcome component, but most still struggle with the same problem this article is about: identifying the right value metric and tracking it reliably enough to price against it.
A working value meter is the instrumentation layer this kind of pricing needs to run on. It is also the kind of continuous, quantified metric that our earlier piece on metrics in MEDDIC sales argues every serious B2B deal should be anchored to, except automated and running in the background instead of recalculated by hand at each business review.
A dashboard alone usually cannot do this. Most show current-state numbers, not a defensible link back to a pre-implementation baseline. SaaS value tracking that actually holds up in a renewal conversation needs both halves: the number today, and proof of what the number was before.
The Hard Part of Value-Based Pricing: Building a Believable Baseline
Measuring a believable “before” is the real problem, not the “after.” Most companies cannot tell you precisely what their pick cost was six months before a WMS went live, and asking them to reconstruct it after the fact invites exactly the kind of rounding that makes the improvement look better than it was.
I want to be honest about why this is harder than it sounds, because the idea is easy to romanticize. To measure a genuine before-and-after, you need reliable data from before the product existed, and most companies were not instrumenting their own operations carefully enough to produce that baseline.
Ask a warehouse manager what the exact labor cost per pick was a year before the new system, and you will usually get an estimate, not a number, one that conveniently supports whatever conclusion is already being told back to leadership.
Practitioner guidance on this point is consistent: establish baseline measurements before implementation begins, not after, so the comparison has something solid to stand on. That is easy advice to give and hard advice to follow. By the time anyone thinks to measure the baseline, the deal is usually already signed and the implementation clock has started.
Why Nobody Has Built This Properly Yet
There is also a genuine attribution problem. Between the old state and the new state, a company usually changes more than one thing. Headcount shifts. Order volumes grow or shrink. A warehouse gets reorganized. A second shift gets added.
Cleanly attributing an improvement to one piece of software, and not to everything else happening around it at the same time, is a real analytical challenge, not a data entry problem.
Building this well also requires customers to expose operational data they may not want a vendor to see in that much detail. That is a trust conversation as much as a technical one.
I think that is exactly why nobody has built this well yet. It is not a feature a customer asks for on a shortlist. It does not close a deal by itself.
It sits closer to infrastructure, quietly making every other value conversation more honest, which is precisely why it tends to lose the internal roadmap fight against features that visibly move next quarter’s win rate.
A Baseline Checklist for Value-Based Pricing Programs
If you are trying to build something like this, or just want a defensible baseline for this kind of pricing conversation without full instrumentation, a few steps hold up better than others:
- Agree on the measurement methodology with the customer before implementation starts, not after the first quarterly business review
- Capture at least four to six weeks of pre-implementation operational data, not a single snapshot
- Document known confounding factors in writing: planned headcount changes, seasonal volume swings, other projects touching the same process
- Get written sign-off from the customer’s own operations lead on the baseline numbers, not only from the economic buyer
- Decide upfront how disputed numbers will be resolved, before either side has an incentive to dispute them
- Revisit the baseline definition if the customer’s operations change materially mid-contract, and log the change instead of silently updating the number
None of this is exciting work. It is also the only part of the process that makes everything downstream defensible.
Value Meter vs. ROI Calculator vs. ROI Dashboard
The three approaches get talked about as if they are interchangeable. They are not.
| ROI Calculator | ROI Dashboard | Product Value Meter | |
|---|---|---|---|
| When it runs | Once, during the sales cycle | Continuously, current state only | Continuously, tied to a fixed baseline |
| Baseline handling | Projected, not measured | Usually absent | Captured and agreed before go-live |
| Renewal usefulness | Stale within months | Shows activity, not proven value | Shows the actual before-to-after gap |
| Risk of being gamed | High, it is a projection | Medium, numbers can be cherry-picked | Lower, if methodology was agreed upfront |
| Trust required from customer | Low | Low to medium | High, needs real operational data |
An ROI calculator sells the deal. A dashboard reports on the deal after the fact. A value meter is closer to a shared instrument that both sides trust, because they agreed on how it works before either side had a stake in the outcome.
Skip the baseline step, and you end up in the second column, not the third, no matter how good the visualization looks.
Why Value-Based Pricing Is Still Worth the Effort
I keep coming back to this idea because it solves a problem I see constantly in B2B software: vendors and customers arguing about value using two different sets of facts, one from a sales deck and one from a finance spreadsheet, and neither side fully trusts the other’s numbers.
A product that could show, with real data, that a customer’s cost per outcome genuinely dropped from ten euros to three would end most of those arguments before they started.
It would not be simple to build, and it would not be cheap. It would need careful baseline capture at the start of an implementation, honest handling of confounding factors, and a customer relationship built on enough trust to share the operational data that makes the whole thing meaningful.
Of everything I would want to see in a product roadmap, this is the one I think would change how B2B software gets priced and renewed, more than almost anything else on the list.
If your GTM motion or pricing structure could use a second pair of eyes on this, that is exactly the kind of portfolio value creation work I take on, alongside broader GTM and pricing advisory engagements.
FAQ: Value-Based Pricing and SaaS Value Tracking
What is a product value meter in value-based pricing?
A product value meter is an in-product instrument that captures a customer’s operational baseline before implementation and keeps measuring the same metric afterward, so the value gap stays current instead of being calculated once during the sales cycle.
How is SaaS value tracking different from an ROI dashboard?
A standard dashboard usually shows only current-state numbers. The real version also requires a documented, agreed baseline, so today’s number can be compared to something both sides trust rather than to an assumption made months earlier.
Can a value meter be gamed?
Probably, at least at first. A vendor could pick a flattering baseline, and a customer could under-report the after-state to negotiate harder at renewal. The only real defense is making the measurement methodology transparent and consistent, agreed before implementation starts, not adjusted afterward.
Is this approach realistic for every product category?
No. It works best where the outcome is genuinely measurable, cost per pick, cost per invoice, time per resolved case, and where the customer is willing to share that operational data. It is a poor fit for products whose value is hard to isolate from everything else happening in the business.
If you have tried to build something like this, or have opinions on why it has not caught on, I would like to hear about it. Get in touch.