Your Pricing Page Is a Game Board

Suppose we built an AI support agent today. It answers product questions, changes subscriptions, processes refunds inside policy, and sends the genuinely weird cases to a human.

Now it is Monday morning and six people are sitting in a pricing meeting. Engineering has a spreadsheet of model and tool costs. Finance wants gross margin. Sales wants a number that will not frighten the first ten customers. The product team thinks charging for a successful resolution sounds honest. Somebody says “why not just charge per seat?” and everybody looks at the AI that is supposed to reduce the number of seats.

This is the annoying thing about pricing. The arithmetic can be correct while the price is still wrong.

The engineering answer is to count the tokens, add the tool calls, apply a margin, and send an invoice. That is useful for understanding cost. It is less useful for understanding what the customer bought. The customer did not come looking for twelve million tokens. It came because its support queue is growing, customers are waiting, and hiring another shift is expensive.

Okay, charge for outcomes then. Except now we need to decide what an outcome is. If the agent gives a vague answer and the customer silently leaves, did we solve the problem or merely tire the person out? If one conversation resets a password and another saves a fifty-thousand-dollar renewal, are those really the same unit? If hard tickets are free because they escalate, does the vendor have a reason to avoid them?

A seat price has a different problem. The product becomes more useful as it removes work from human agents, but its revenue falls as the customer needs fewer seats. The contract and the product are pulling in opposite directions.

I went into the pricing-theory rabbit hole expecting to find the formula companies had somehow forgotten to use. There is no such formula. What I found was a collection of smaller ideas about costs, choices, negotiation, competition, and incentives. Put together, they explain why a pricing page is never only a list of numbers.

That is where game theory enters. I do not mean a room full of people drawing giant payoff matrices. I mean the ordinary fact that my best move depends on what I think you will do. The seller knows its costs better than the buyer. The buyer knows its workflow and budget better than the seller. A competitor can respond to a public discount. A salesperson can quietly change an experiment by offering an extra concession. Once a metric decides the bill, people begin adapting to the metric.

Lemme build the story around one fake company. Call it RelayDesk. None of its numbers are benchmarks; they are just a clean little world in which we can break contracts without upsetting an actual finance team.

The first two numbers are not the price

RelayDesk is talking to a software company with 40,000 support conversations each month. A human agent costs about $35 per loaded hour and spends eight minutes on the average ticket. That is roughly $4.67 of labour per ticket. RelayDesk expects to resolve 60 percent of conversations without a human, so it expects 24,000 resolutions.

Its model and tool cost is $0.12 per attempted conversation. Dividing by the probability of success gives the expected compute cost of one resolution:

Twenty cents is not the price. It is one boundary. The customer's simplified labour value is another:

\[ 24{,}000\times \$4.67 \approx \$112{,}080 \text{ per month}. \]

That enormous gap looks like free money. It is not. It contains onboarding, monitoring, account support, mistakes, human review, security work, the customer's next-best vendor, and the fact that buyers generally dislike donating their entire surplus to a startup.

It also hides a fairly basic mistake: cost, value, and willingness to pay are three different numbers. Cost asks what RelayDesk must spend to serve the account. Value asks how much better the customer is with RelayDesk than without it. Willingness to pay asks how much of that improvement the customer would actually exchange for the product. A buyer might save $100,000 and still refuse a $70,000 contract because the savings are uncertain, the integration is painful, or a rival is available for $40,000.

A useful first sketch is

\[ C(q)=F+cq, \]

where \(q\) is the amount of service, \(F\) is the account-level fixed cost, and \(c\) is the extra cost of one more unit.Fixed and marginal cost. A fixed cost is incurred even when usage is low, such as integration or security review. Marginal cost is the extra cost caused by one more conversation, token, or outcome. For RelayDesk, \(F\) includes integration, evaluations, support, and monitoring. The $0.12 belongs inside \(c\), but it is not all of \(c\).

Imagine one account sending 100,000 simple password questions and another sending 5,000 conversations but needing custom permissions, weekly reviews, and legal approval for each workflow. The first has more usage. The second may cost more to support. A pure per-conversation price sees only the first fact, which is one reason platform fees appear.

The seller would like a price above cost. The buyer accepts a price below the value of choosing RelayDesk instead of its best alternative. That last phrase matters. Manual labour may create $112,080 of apparent value, but if another vendor creates nearly the same result for $35,000, RelayDesk cannot negotiate as though the alternative were a room full of humans.

The classic monopoly benchmark relates markup to demand elasticity:

\[ \frac{p-c}{p}=\frac{1}{|\varepsilon|}. \]

The left side is the fraction of price sitting above marginal cost. The right side says that a seller can sustain a larger markup when customers are less sensitive to price.Elasticity, without ceremony. Price elasticity asks how strongly demand changes when price changes. If a 1 percent price increase reduces quantity by about 2 percent, elasticity is roughly \(-2\). The absolute value removes the minus sign. This is the Lerner condition, not a quote calculator.[4] Enterprise founders almost never know \(\varepsilon\) cleanly. A lost deal may be about security, timing, procurement, a missing integration, or price. The formula gives us a direction, not a button.

Think about two sales calls. One buyer says, “At $50,000 we approve this; at $60,000 we build it ourselves.” Another has a launch in three weeks and RelayDesk is the only approved vendor. Price probably changes the first buyer's decision more. Elasticity is the name for that difference in response, though enterprise teams usually estimate it from messy evidence.

How a number became a game

The history helped me here. Pricing theory did not progress by finding one increasingly clever way to mark up cost. It progressed by noticing another player, another hidden fact, or another reaction that the previous model had ignored.

Cournot's 1838 model began with quantity. Imagine two producers deciding how much to make. Each producer's profit depends not only on its own output but on how much the other producer releases into the market. That is already a game: choosing ten units is sensible if the rival chooses five and foolish if the rival chooses a hundred.[1]

A few decades later, Bertrand pushed on the obvious weak point. What if firms choose prices rather than quantities? If the products are identical and each seller can serve the whole market, a tiny undercut can take all the customers. Keep undercutting and the price is pushed toward cost.[2] The assumptions are severe, but the result explains why software companies work so hard not to look interchangeable.

Hotelling made that difference easier to see. His sellers occupied different locations, so customers cared about price and about the inconvenience of reaching a seller.[3] For software, “distance” can mean missing integrations, weaker security, a confusing interface, or six months of migration work. Two products can look similar in a comparison table and still feel far apart to the buyer using them.

Later work moved closer to the actual deal. Nash asked how two parties might divide the gains from an agreement when both can walk away. Oi studied the choice between charging at the gate and charging again for each ride. Mussa and Rosen studied menus of different qualities and prices. Holmström studied payment when the person doing the work knows more about the effort than the person paying for it. The questions became less like “what is the monopoly price?” and more like “what can each side see, what can each side choose, and what happens after the contract is signed?”

That is why old pricing papers remain useful for a very new product. An AI vendor knows its model costs and failure modes. The buyer knows how difficult its tickets really are. Neither side can perfectly observe whether every answer solved the underlying problem. Both sides learn after deployment. A 2026 working paper by Lobel, Sun, and Wu studies this choice between charging for use and charging for reported success.[10] It is one recent model, not the final word on AI pricing. I like it because it shows that outcome pricing is not simply a more modern invoice. It changes which facts matter and who has a reason to report them honestly.

Four meters, four games

RelayDesk writes four proposals on a whiteboard. They are not four ways to collect the same money. They create four different products.

A billing metric should be close to customer value, measurable, and easy for both sides to check. It should also be difficult to manipulate. No metric does all of that perfectly. The practical question is which imperfection the buyer and seller can live with.

Seats are familiar and easy to budget. But an AI product can serve more work without adding another employee, which breaks the connection between seats and use. RelayDesk might automate half the queue and then see the customer's seat count fall from 120 to 70. Under a seat contract, doing the job well reduces the bill.

Tokens and model calls are easy to count. They also expose the buyer to choices it may not control. RelayDesk decides how long a prompt is, how often an agent retries, and which model handles the task. If an update doubles token use without improving the answer, a token contract asks the customer to pay for that inefficiency.

Conversations are closer to something a support leader recognizes, and incoming volume can be easier to forecast than successful outcomes. The weakness is that a five-second greeting and a forty-minute refund dispute both count as one.

Resolutions are closest to the result. If RelayDesk fails, the buyer does not pay the variable fee, so the vendor carries more performance risk. But now the definition of “resolved” matters financially. A status in a dashboard is worth $1.75.

The customer knows its own mess. RelayDesk sees a demo and a sample of tickets. If RelayDesk carries all the risk for one flat outcome price, the companies with the hardest queues have the strongest reason to accept. The offer changes the kind of buyer who turns up. That is the simple idea behind adverse selection.

The metric also changes usage. A fee on every conversation can create a ticking meter in the buyer's head, so teams route only obvious cases to the agent. Research on information goods shows that this feeling of paying for every use can change demand and profit.[12] An included allowance or prepaid credits can feel less like a taxi meter, even when the expected bill is similar.

This is why “usage based” is not one design. A raw meter, a bundled allowance, a committed spend, and a platform fee plus overage can all count the same event while feeling different to the buyer. The unit may be identical. The experience of deciding whether to use one more unit is not.

When we charge for outcomes, we start arguing about outcomes

The appeal is obvious. The buyer wants a result. RelayDesk chooses many of the details that produce it: which model to call, how much context to retrieve, when to try again, and when to bring in a person. The buyer cannot watch every one of those decisions. Contract theory calls the buyer the principal and RelayDesk the agent.Principal and agent. One party delegates work and another performs it. The person doing the work usually knows more about the action taken. The contract tries to make their interests less different. Paying for the result seems like a direct way to align them.

It works only if the result can be defined well enough.

RelayDesk proposes the following rule:

That looks objective until a customer goes silent. Silence can mean “thanks,” “I gave up,” “I found the answer elsewhere,” or “I am now angrily searching for a competitor.” The vendor benefits from the first interpretation. The buyer benefits from disputing it. The measurement rule has created a new game inside the old one.

Picture a real ticket. A customer writes, “Why was I charged twice?” RelayDesk explains that one line is a temporary authorization and says it should disappear within three days. The customer leaves. On day two, the billing system captures both charges because this case was not a temporary authorization at all. On day four, the customer returns furious.

Was the first conversation resolved? Under a rule that counts silence after twenty-four hours, yes. Under a rule that reverses the charge when a ticket reopens within seven days, no. Under a customer-satisfaction rule, we may never know because the person ignored the survey. None of these definitions is absurd. They simply answer different questions.

This is where product analytics becomes contract language. The timeout, reopen window, escalation category, and exclusion list eventually decide money. They need to be written for a finance team that wants to reproduce the invoice, not only for a dashboard that wants a clean success rate.

This is not hypothetical. Intercom currently documents an “assumed resolution” when the user leaves after receiving an answer, while later reopens are deducted; it also distinguishes billable procedure handoffs from several non-billable escalations.[18] Sierra argues for agreed outcome definitions and says most escalations are not charged.[19] Decagon supports both conversation and resolution pricing, but says most of its customers choose conversation pricing for predictability and fewer arguments about what was solved.[20]

That disagreement is more useful than a universal best practice. It tells us that the quality of the measurement decides whether an outcome contract works.Observability. This just asks whether both sides can measure an outcome reliably enough to put it in a contract. “API call completed” is easy. “The customer's real problem disappeared” is much harder. HubSpot moved two agents toward completed-task pricing in April 2026. Zendesk says its outcome system uses the acting agent plus a separate evaluation model to verify a resolution.[21][22] The market is not converging on one meter. Different companies are trying different ways to verify the result.

Holmström's work on hidden effort explains the tension. Paying for performance is helpful when the thing we measure closely reflects the work we care about. It becomes less helpful when luck and measurement error have a large effect on the score.[8] Holmström and Milgrom add another problem. If a job contains several tasks and we strongly reward only the easiest one to measure, effort can move away from the rest.[9]

If RelayDesk is paid only for resolution count, it may improve the count while making tone, safety, coverage, or long-run trust worse. The answer is not to create fifty separate prices. It is to choose one main billing event and keep a short list of limits around it: reopen rate, customer satisfaction, policy violations, escalation rate, and minimum coverage. If one of those measures crosses an agreed threshold, the teams investigate or pause billing. That is less elegant than “pay only for success,” but it is much closer to how the work actually behaves.

A pricing menu is also a question

The buyer knows things RelayDesk does not. It knows its real ticket complexity, internal labour cost, appetite for budget surprises, and how painful a failed answer would be. Asking “what are you willing to pay?” is unlikely to produce a spiritual commitment to honesty.

So the seller can ask through choices.

Economists call this second-degree price discrimination: the seller offers choices and lets buyers sort themselves.Why “second-degree”? First-degree tries to charge each buyer its exact willingness to pay. Second-degree uses a menu. Third-degree sets prices for visible groups, such as student pricing. The name sounds harsher than the everyday practice. Cloud providers do it with on-demand and committed-use plans. Gyms do it with monthly and annual memberships.

Mussa and Rosen's classic model makes the sorting logic precise.[7] A recent B2B study by Ghili and Yoon uses won and lost deals to estimate a price schedule rather than one flat rate.[11] Their numerical result belongs to their setting, not ours. The useful lesson is that failed deals contain information too. A buyer who rejects outcome pricing but accepts conversation pricing has revealed something about trust, risk, or budgeting.

Two conditions keep the menu honest:

\[ \underbrace{U_i(\text{chosen plan})\ge U_i(\text{outside option})}_{\text{better than leaving}} \]

\[ \underbrace{U_i(\text{chosen plan})\ge U_i(\text{other plan})}_{\text{prefers the intended plan}}. \]

\(U_i\) means the overall value customer type \(i\) receives after price, risk, and effort.Utility. This is a compact score for what someone prefers. Here, read it as business value minus the bill, implementation pain, risk, and the value of alternatives. The first line says the plan must beat walking away. The second says the intended customer must actually prefer it to the other plans.

On the pricing call, that means the predictable plan must genuinely suit the buyer who wants predictability. Putting the word on the card is not enough. If the overage is frightening or the allowance is tiny, that buyer may choose another plan or leave.

A useful menu needs meaningful differences. Four cards with nearly identical economics reveal little. One plan can make the bill stable. Another can make the vendor carry performance risk. A third can exchange an annual commitment for a lower rate. Then the choice teaches us something.

The sorting can still go badly. Customers with complex cases may prefer a flat outcome rate because RelayDesk absorbs the difficulty, while easy customers choose conversation pricing. The menu has separated the groups, but in a costly direction.

This is why the two-part tariff keeps reappearing:

The fixed fee pays for the account existing. The variable price follows use or value. Walter Oi made this structure famous through the Disneyland problem: charge at the gate, charge at the rides, or mix both?[6] RelayDesk has the same problem with fewer mouse ears. Integration, security, and monitoring belong at the gate. Conversations or verified outcomes are the rides.

A platform fee is therefore not automatically a random tax added by sales. It can defend against a small but integration-heavy account and against hard customers selecting only a generous variable contract. The mistake is pretending the fee came from compute.

More plans are not always better. Every new choice asks the customer to forecast a product it may not understand yet. If estimating next month's bill requires a simulator, a glossary, and a sales call, the menu is costing trust. RelayDesk needs enough choice to separate important needs, not every possible customer.

Enterprise pricing happens across a table

A self-serve price can look like a vending machine: choose the plan, enter a card, and begin. Enterprise pricing is a conversation. The buyer asks for security work, custom limits, support, and a lower rate. The seller asks for an annual commitment, faster payment, or permission to use the logo. The final number depends on the other terms and on what happens if they fail to agree.

The lightest useful version of Nash bargaining is

\[ p^*=\arg\max_p \bigl(U_B(p)-d_B\bigr)^\beta \bigl(U_S(p)-d_S\bigr)^{1-\beta}. \]

This looks more frightening than it is. \(U_B\) and \(U_S\) are what the buyer and seller get from making the deal. \(d_B\) and \(d_S\) are what they get if the deal dies. The parameter \(\beta\) represents how much weight the buyer has in the negotiation.“Arg max.” This means “choose the price that makes the following expression as large as possible.” The formula compares what each side gains from agreement with what it keeps by walking away. The useful lesson is not that every deal splits the benefit fifty-fifty. It is that the alternatives outside the room affect the number inside it.[5]

Suppose RelayDesk saves the buyer $112,080 a month compared with doing everything manually. That does not mean the two sides are negotiating over the full $112,080. If the buyer can adopt another product and still save $95,000, RelayDesk is responsible for only about $17,000 of additional value before we consider switching costs and differences in risk. On the other hand, if RelayDesk is the only vendor approved before a major launch, the buyer's alternative may be overtime, delay, or a visibly bad support experience. The same product can support a very different price because the alternative changed.

Now reverse it. The customer has spent six months integrating RelayDesk into permissions, billing, and internal policy. Switching is painful. RelayDesk's renewal leverage rises. It can exploit that once, perhaps. But this is a repeated game. The buyer can fund a replacement project, reduce expansion, refuse a reference, and remember the surprise at the next negotiation.

This is also where the repeated part of the game matters. If this were the only transaction the two companies would ever have, squeezing for every available dollar might work. But the buyer will decide whether to expand, renew, provide a reference, or recommend RelayDesk to another team. Renewal caps, grandfathering, and volume commitments give the buyer some confidence about what happens after it becomes dependent on the product.

Trust here is not a sentimental extra. It changes behaviour. A buyer who expects a sharp renewal increase may hold back integrations and keep a replacement vendor warm. A buyer who understands the pricing rule may send more traffic, share better data, and spend less time auditing the invoice. Those actions affect the value RelayDesk can create later.

The same logic explains discounts. A lower price exchanged for a longer commitment, reference rights, faster payment, or simpler implementation is a trade. A lower price because the salesperson panicked is merely missing data. Record the reason. Negotiation can teach the company, but only if every concession is attached to the fact that caused it.

The competitor is playing too

If two products are identical, easy to compare, and cost the same to deliver, Bertrand competition gives us a brutal instinct: each seller can steal the market with a tiny undercut until price approaches marginal cost.[2] Real B2B software avoids this cliff through differentiation, switching cost, reputation, integrations, and imperfect information.

Hotelling's old spatial picture is useful even when nobody is standing on a beach. Put two vendors on a line. One is cheap and narrow. The other is expensive but can safely execute refunds and account changes. A buyer's effective price includes the distance between what it needs and what the product does. Product position changes how many customers an undercut actually steals.[3]

Things become harder to predict when sellers respond over and over. One firm cuts price, the other undercuts it, both prices fall, and eventually one firm raises its price because the low rate is no longer worth offering. Maskin and Tirole modeled versions of this pattern, known as Edgeworth cycles, in a game where firms take turns setting prices.[14] A public SaaS pricing change moves more slowly, but the reactions are familiar. Rivals match it, procurement saves a screenshot, and existing customers bring it to renewal. The test has changed the information available to everyone in the market.

There is a quieter version of this in almost every enterprise pipeline. A salesperson says a rival is “half the price.” Sometimes that is true. Sometimes the rival counts a different unit, excludes support, requires a larger annual commitment, or has not priced the same security work. Before reacting, RelayDesk has to normalize the offers. Otherwise it may cut its resolution price to match what was actually a conversation price with a minimum spend.

Differentiation helps only when the buyer values it and can verify it. Saying “our agents are more reliable” does little on its own. Showing that RelayDesk can safely process refunds, documenting the failure rate, and accepting a service guarantee turns a vague claim into part of the offer. Product work and pricing work meet here. A capability that the customer cannot see or trust will not protect much margin.

Algorithms make reactions faster. Calvano and coauthors studied software sellers that learned prices through trial and error in a controlled market with few competitors. The sellers kept prices above the competitive benchmark without directly communicating.[15] Brown and MacKay show that how often pricing systems update, and whether one seller can hold a price while another reacts, can change the usual price and the spread between prices.[16]

None of this means a high market price proves that algorithms colluded. The cited studies explain ways repeated automated pricing can behave under particular assumptions. An annual enterprise negotiation is very different from an online shop changing prices every hour. The relevant lesson for RelayDesk is simply that faster reactions and more visible prices give competitors more chances to respond. We have to understand the setting before borrowing the conclusion.

What people mean when they say dynamic pricing

People use dynamic pricing to describe at least three systems:

1. A dynamic bill. Quantity changes while the unit rate stays fixed. More API calls create a larger invoice. This is usage billing, not necessarily dynamic pricing.
2. A rule-based price. The unit rate changes when an observable threshold is crossed, perhaps because volume enters a new band.
3. A learning price. The seller experiments, estimates demand, and changes the offer to improve an objective.

Only the third is really trynna discover a better price. Its simplest objective is

\[ \pi(p)=(p-c)D(p)-F, \]

where \(\pi\) is profit and \(D(p)\) is demand at price \(p\).Demand function. \(D(p)\) describes how much the market buys at price \(p\). It usually falls as price rises, but enterprise data rarely reveals the curve cleanly. Raising price improves margin on accepted deals and may reduce the number accepted. The seller is learning that curve while earning from it.

This is easy to say and hard to do with five enterprise renewals. There may be only a few observations, and no two deals are quite alike. Sales representatives may compensate for a high-price test with more attention or a hidden discount. One deal fails a security review and gets labelled price sensitive. Another accepts because migration has already begun. Assigning prices randomly in a spreadsheet does not help if the rest of the sales process changes with the price.

Suppose RelayDesk compares $1.50 and $1.75 per resolution. The higher-price group happens to contain two banks with long security reviews, while the other group contains three small software companies ready to buy. Sales then gives the banks more attention and one free pilot. If the higher rate appears to lose, was it the price, the buyers, or the different sales process? With a small sample, the answer may remain unclear.

Cheung, Simchi-Levi, and Wang study demand learning when the seller can change prices only a limited number of times.[13] That is a much better metaphor for enterprise SaaS than a supermarket repricing every minute. RelayDesk should learn at pilots, new offers, expansions, and renewals. It should use broad groups, stable rules, and the profit left after serving an account rather than conversion alone.

A practical test can be modest. For one quarter, RelayDesk might keep the unit price fixed and compare two included allowances for new mid-market customers. The eligibility rule is written before the first quote, and sales records every exception. The test will not reveal a perfect demand curve. It can still show which package creates fewer objections and healthier use.

Conversion alone can reward bad pricing. A low rate may win nearly every deal while leaving no money for support. RelayDesk should also track what remains after model cost, tools, account support, and concessions. That is the contribution the profit formula is trying to summarize.

Personalization creates a separate problem. If two similar buyers compare notes and discover different unexplained prices, their reaction depends on more than the amount. They may decide the process was unfair. Competition makes the overall effect hard to predict too; theory does not support the easy claim that more customer data always means more seller profit.[17] A model can find a number that looks profitable in historical data and still damage the relationship when a person has to explain it.

The billing system has to match the promise

Once the teams agree on a pricing rule, the billing system has to reproduce it. This sounds administrative until the first disputed invoice arrives.

This is where companies such as Flexprice, Orb, Metronome, and Lago enter. They sit mainly in the execution layers: ingest events, aggregate usage, apply customer-specific rates, manage credits and commitments, preserve legacy plans, and produce billing data.[24][25][26][27]

Follow one resolution. RelayDesk records that conversation 813 began at 10:04, the AI took three actions, the user left at 10:11, and no human took over. After the waiting period, the billing layer checks that it is not spam, a test, or a duplicate. It applies the contracted rate and keeps enough detail for the customer to trace the charge.

If the user returns two days later, the system may reverse the event. An old contract might use a seven-day reopen window rather than three. An account that prepaid an annual commitment may record the usage without adding a charge. The simple idea “$1.75 per verified resolution” has become a list of data and accounting rules.

This is why changing a price takes longer than editing a website. Existing customers have old definitions, limits, credits, and renewal dates. Finance needs a history of which rule applied when, and customer success needs to explain the result. Without that history, a sensible experiment can create months of corrections.

Flexprice is a particularly neat example because its current product pages connect pricing experiments to the operational mess underneath. It describes testing rate structures on subsets, rolling them back, grandfathering legacy plans, segment overrides, and audit logs.[24] If RelayDesk chooses a $2,500 platform fee plus $1.75 per verified resolution, Flexprice can help turn accepted resolution events into the correct bill.

There is still an important boundary. Infrastructure can execute a rule without proving that the rule is a good one. Counting usage does not tell us how demand responds to price. Splitting customers into test groups does not produce a clean comparison if sales treats the groups differently. Calling a changing usage bill dynamic pricing does not mean the system is learning anything. Good billing software can faithfully run a bad pricing decision.

Forethought's public description of a platform fee plus outcome-based cost is a useful real-world hybrid.[23] Orb and Lago both describe support for tokens, outcomes, credits, commitments, and mixed plans.[25][27] The variety is the point. A modern pricing system needs to represent the contract a company has chosen without forcing the engineering team to rebuild billing every quarter.

A first contract for RelayDesk

After all that theory, I would not let an autonomous optimizer loose on five renewals. I would begin with a contract that the support lead, salesperson, and finance team can each explain without opening a second document:

Here \(F\) is the monthly platform fee. \(R\) is the number of verified standard resolutions and \(p_r\) is the price of each one. \(C\) is a separately defined complex outcome class and \(p_c\) is its price.The subscripts. The small \(r\) and \(c\) only label two rates: one for standard resolutions and one for complex outcomes. They do not introduce a new operation. Approved tool costs cover rare third-party expenses that both sides agreed to pass through, not every internal token RelayDesk happens to use.

The relationship would start with a paid six-week proof of value. The teams would sample old conversations and write examples of what counts as resolved, escalated, or excluded. RelayDesk would then run on limited traffic while both sides score the same sample. Large disagreements would change the definition before they change the bill.

Only then would paid outcomes begin. A weekly file would show the conversation ID, category, resolution time, reopen status, and charge. Both teams would review a random sample. If errors exceeded the agreed limit, the account would return temporarily to conversation pricing or a fixed pilot fee.

This is slower than putting “pay for outcomes” on a pricing page, but it makes the phrase believable. The customer need not trust a private score, and RelayDesk need not accept a result redefined after the invoice arrives.

I would offer conversation pricing and verified-outcome pricing rather than declare one morally superior. The buyer can show whether it worries more about an unpredictable bill or about paying when the product fails. Annual minimum commitments can purchase lower variable rates. Spend alerts and caps prevent a busy month from becoming a finance incident. No personalized rate changes appear halfway through a contract. Renewal tests happen across broad, clearly defined groups, and existing customers know whether their old terms continue.

For the large customer in our example, suppose the platform fee is $5,000 and the standard resolution price is $1.75:

\[ \text{bill}=\$5{,}000+\$1.75(24{,}000)=\$47{,}000. \]

Against the simplified $112,080 labour value, the buyer retains about $65,080 before review costs, error costs, implementation work, and the value of alternatives. If RelayDesk also spends $8,000 monthly on account support and its 40,000 attempts cost $0.12 each, simplified account contribution is

\[ \$47{,}000-[40{,}000(\$0.12)+\$8{,}000] =\$34{,}200. \]

These numbers do not prove $1.75 is optimal. They tell us that the example is at least internally possible, and they make the assumptions visible. What happens if resolution falls from 60 percent to 40 percent? What if account support costs $18,000 rather than $8,000? What if the buyer's best alternative costs only $35,000? Each answer changes the deal.

This is the kind of spreadsheet I would actually want beside the contract. Not one tab containing a single “recommended price,” but a few cases showing easy traffic, hard traffic, high support, low support, strong competition, and weak competition. Pricing theory does not remove judgment. It makes the judgment easier to inspect.

Now try to break it

This is the part of pricing decks that should be much longer than it usually is.

1. Hard customers select the outcome plan. Resolution probability falls, support rises, and the risk premium was too small.
2. Verification is weak. Disputes and human audits cost more than the alignment benefit.
3. A close rival exists. RelayDesk's differentiated value is far below the buyer's total labour saving.
4. The meter suppresses use. Customers protect their budget by withholding exactly the borderline cases from which the product needs to learn.
5. The quality scorecard misses the real harm. Resolution rises while trust, safety, or long-run retention quietly falls.
6. The evidence is too sparse. A pricing model learns the personalities of five procurement teams and mistakes that for a demand curve.

A contract should fail on paper before it fails on an invoice.

What this story does not say

It does not say outcome pricing is always better. It works best when the result is valuable and both sides can verify it. A conversation can be the more honest meter when success is disputed. It also does not say value-based pricing means charging the customer everything it gains. Competitors, alternatives, and the long-term relationship all limit what the seller can reasonably keep.

Not every customer needs a unique price either. Personalization can improve fit, but it adds fairness and explanation problems. A small menu is often easier to learn from. And high prices do not automatically prove algorithmic collusion. Laboratory agents, online shops, and negotiated B2B software are different settings.

Tokens still matter because they affect cost. Seats describe part of the customer's organization. Conversations are easy to count. Outcomes get closer to value. The mistake is expecting one of these units to answer every question.

Back to the Monday pricing meeting

We began with six people trying to price an AI support agent. Engineering brought the twenty-cent compute estimate. The customer example suggested $112,080 of possible labour value. Both numbers were useful. Neither could become the price on its own.

The team still has to ask ordinary questions. What would the buyer do without RelayDesk? Can both sides reproduce the resolution count? Who pays when tickets are harder than the sample? Will the contract still feel fair at renewal?

Pricing theory gives the team ways to organize those questions. Game theory reminds it that the answers change behaviour. A conversation fee may suppress experiments. An outcome fee may create disputes about success. A strong reward for one quality score may pull attention away from safety. A surprise renewal increase may cause the customer to keep a replacement ready.

So I would leave the meeting with a small menu, a paid pilot, clear event definitions, a platform fee for account-level work, and one variable rate the customer can audit. I would write down every assumption behind the number and test them slowly. The exact rate will change. The reasons for the rate should remain understandable.

That, more than the cleverness of the formula, is what makes a price usable.