Pricing software by seats is comfortable because both sides know what the invoice means, and that predictability travels well; Databook chose a less comfortable number today: incremental revenue above the customer’s financial plan.
Its new GTM Decision System pairs a base fee with a variable fee only on revenue earned above the CFO’s plan, while baseline commitments carry no variable charge across an enterprise contract. That’s a more interesting product decision than another pricing page with Starter, Pro, and Enterprise columns.
Outcome-based pricing changes what the vendor has to know.
A seat is directly observable. So are API calls, storage, and tokens. Incremental revenue is a counterfactual: what would the customer have earned without the product, given everything else that happened during the same period? Databook’s own services model hints at the machinery required because its 90-day evaluation starts by agreeing on a baseline, defining improvement before deployment, and measuring results against that baseline.
Measurement becomes product surface.
For a revenue product, I’d want the contract and telemetry to answer some awkward questions early, before anyone has money riding on the answer. Does a renewal count differently from net-new revenue, and how is seasonality handled when the comparison period wasn’t remotely normal? What happens after a territory changes hands, a sales rep leaves, or the customer’s annual plan gets revised halfway through the measurement period? Attribution arguments aren’t edge cases when attribution determines the invoice.
This is where outcome pricing either earns its keep or becomes invoice theater for both sides.
The upside is alignment: a vendor sharing incremental revenue has a strong reason to care about adoption, data quality, deployment time, and whether users actually change behavior. Databook describes a 90-day proof of value, forward-deployed engineers, and measurement against an agreed baseline; those services are infrastructure for making the pricing model believable.
There’s a harder downside, though, because customers may reasonably resist paying a percentage of upside they believe their sales team would have produced anyway. Vendors can tighten attribution rules, but every extra rule adds commercial friction and another place for finance teams to disagree about whose spreadsheet is authoritative.
Outcome isn’t automatically a billing unit.
I’ve written before about how API pricing makes the billing unit part of the product. Outcome pricing pushes that idea further because the billing unit now depends on a model of causality rather than a meter, so product, finance, sales, and customer success inherit the same attribution model and its disputes.
Databook’s launch is aimed at enterprise sales, where revenue is at least visible enough to argue about. In products with longer causal chains, weaker attribution, or outcomes controlled mostly by the customer, the commercial model gets shakier fast because neither party can cleanly isolate contribution.
If you’re considering outcome-based pricing, start the pricing workshop with the baseline, not the percentage. If two reasonable finance teams can’t reproduce the same incremental-revenue number from the same data, the product isn’t ready to bill against it.
Comments
Comments are powered by GitHub Discussions through Giscus.