A Practical Guide to Outcome-Based Pricing

Welcome back to Good Better Best.

Each week, we break down real pricing, packaging, and product moves from SaaS and AI leaders and share the ideas worth stealing.

This week, I'm sharing a guest post from George Kats. George is a member of the PricingSaaS Community who previously led Monetization Engineering at PandaDoc. He is now building witn, billing infrastructure for outcome-based pricing. Over the past few months, he’s spoken with tons of operators about outcome-based pricing, and today he’s sharing his top 3 learnings.

Let’s get to it.

This week we observed 100+ changes. The highlights:

Check out more updates on PricingSaaS →

Here’s what was top of mind in Pulse this week:

Over the past several months, I have spent a lot of time sitting with founders, product teams, RevOps and billing operators who are either running outcome-based pricing today or seriously considering it. The conversations were less about whether outcome-based pricing is a good idea and more about the messy reality of implementing and operating it once teams try to make it real.

This guide is my attempt to compress those learnings into something practical. Let's start at the beginning, because if the first step is wrong, nothing downstream works.

The first mistake teams make is trying to make the outcome too profound. They reach for things like revenue influenced or pipeline generated. Don't. The best billable outcomes are usually boring. They're chores. Small, repetitive jobs the customer used to do manually: an appointment gets booked, a creative asset gets generated. That's the right level. Concrete, countable, the kind of thing that happens hundreds of times a week.

A good billable outcome has three properties:

This is why "appointment booked" works better than "pipeline created". The closer a metric gets to a quarterly business result, the more likely every invoice turns into an attribution debate.

The definition also needs a time window. A booked appointment might only count if it has not been cancelled after 24 hours or if it is still on the calendar when the meeting time arrives. The time window is part of what makes the outcome concrete, not just a billing edge case.

My recommendation is to start with the least impressive unit that still feels valuable. The thing a customer used to assign to a person, and now expects the product to finish.

Which brings us to credits. Credits are everywhere right now and they're often useful. They give teams a way to manage variable costs and package messy usage. But credits are rarely the thing the customer actually wants. A customer buying credits to generate slide decks wants finished slide decks. The credit is the accounting layer sitting between the customer and the job they came to complete. That means most credit-based products already have an outcome hiding one layer underneath. The work is figuring out whether that outcome is concrete enough to price directly. Often it is and naming it instead of the credit is mostly a question of nerve.

So before building anything, write one sentence:

We charge when ___ happens and remains true for ___.

Fill the first blank with the smallest concrete event you can defend. That sentence becomes the spec for everything that follows.

The reason outcome pricing scares finance teams is that nobody knows what the invoices will actually look like. So find out before committing. The data is almost certainly already there. Replay historical events through the outcome definition and calculate what every customer would have paid last month under this model.

That first backtest is only the starting point. Change one condition at a time, rerun the model and watch the invoice move line by line. Maybe a booked appointment only counts if it has not been cancelled in the calendar. The goal is to understand which definition changes the invoice and by how much. This is where you decide what counts. One CX company serving ecommerce only counts a resolution when there is a genuine exchange. End users often open a ticket by accident and never reply, so a single inbound with no follow-up does not count. It is a smart, customer-aligned call that keeps every charge tied to real value.

The simulation should also show the new model against the old one. Put the customer's outcome-priced invoice next to what they actually paid under the current model. Do the same for the business across last month, last quarter and the renewal base. If the customer pays more, the model needs to make the extra value obvious. If revenue drops, that needs to be known before launch.

Run this with a few trusted customers. Take their real historical usage, show the invoice they would have received and walk through it slowly. The point is to learn where the customer hesitates, where the definition feels unfair and where the bill is harder to predict than expected. Every objection raised there is a dispute defused before it ever hits a real bill.

Model the future, because the product is going to get better and that can quietly wreck a usage-based model. Take voice AI, where much of the category is still anchored around per-minute pricing: if an agent starts resolving the same job in less time, revenue can fall precisely because the product got better. That's the trap of pricing the input. Outcome pricing flips it by billing per resolved call, so getting faster should, in all likelihood, improve margin instead of compressing revenue. When the model gets simulated, simulate the roadmap too and make sure it shows where revenue goes when the product is twice as good.

Surprisingly, the hardest part is explaining the invoice. Customers dispute bills they don't understand and with AI-driven outcomes there is a lot they don't understand. In the worst cases, outcome-related disputes become a daily operational tax.

The customer has to be able to understand what they are being charged for. If the product shows one number and the invoice shows another, the customer is right to be angry. They do not care which internal system is technically correct. They care that the bill does not match the version of reality they were shown.

The fastest way to manufacture a dispute is to build the resolution layer far from billing and let each product team decide for itself what "done" means. Resolution has to be a single shared definition that customers, product, RevOps and CX all read from.

The deeper problem is that the context of an outcome often disappears before it reaches billing. When a customer asks about an invoice, the teams downstream of billing cannot answer on their own. They escalate to product and suddenly one disputed line item becomes a multi-team investigation. Run that every day and the margin on outcome pricing quietly leaks out as support cost.

In practice that means every charge carries its own explanation. Open a line item and you see:

A question about the bill should be answerable from the line item itself. The record the customer sees is the same one billing charged from, so there is much less to reconcile after the fact.

My recommendation is to treat the outcome ledger as part of the billing infrastructure and as the customer-visible source of truth. The charge needs to carry enough context to show why it was billable, so the customer can understand the invoice and any downstream team can explain a line item without opening a ticket to product.

Shared does not mean frozen. Outcome definitions change constantly: custom contracts, new conditions, price experiments. Teams have far more appetite to reprice and redefine outcomes than they ever had with seats, and that appetite is a real competitive advantage. The way to keep it is to centralize that agility: one place to change the definition quickly, so iteration stays fast without every team inventing its own version of the truth.

Outcome-based pricing works when the customer can understand the unit, predict the bill and trust the explanation. None of that is solved on the pricing page. It has to hold up in billing infrastructure, customer communication and the operational path for disputes. The teams that win at this will be the ones where the invoice feels obvious by the time it arrives.

If you're working through outcome-based pricing and want to pressure-test how the outcome turns into a charge, George is always up for a conversation. Grab time here.

Thanks for reading! If you’re working on AI monetization and want to learn more about how we help, book time here.

Until next time,

Rob