The earlier parts of this series looked at AI as a cost of running your own operations. This one turns the question around. Many South African software companies, service providers and administrators are now adding AI features to what they sell. The moment they do, their cost of serving a customer stops being mostly fixed and starts depending on how much each customer uses the feature.
Software has traditionally been priced on the assumption that serving one more user costs almost nothing. That assumption is why per-seat pricing works so well for conventional software. AI breaks it. Every use of an AI feature has a real marginal cost, paid to a model provider in dollars, and some customers use it ten or twenty times as much as others.
Price an AI feature as if it were conventional software and you can end up with a product whose best customers lose you money.
Tugela Claims Services is fictional, and its systems and figures are illustrative. Tugela charges its seven insurer clients a fee per claim administered. Two insurers have asked for an AI claims-summary feature in Tugela's insurer portal, so their own staff can generate a summary of any claim file on demand. The product team's first proposal was R1,500 per insurer user per month.
Seat pricing meets variable cost
Tugela ran the feature with one insurer's 40 users for a month to measure what it cost to serve. Usage was uneven, as it nearly always is. A light user cost about R120 a month in model and platform costs. The median user cost about R450. The heaviest users, claims managers who summarised every file before every meeting, cost about R1,900.
At R1,500 a seat, the light user earns a margin of R1,380 and the median user R1,050. The heavy user loses R400 every month. Worse, the heavy users are the champions: the people who rely on the feature most and are most likely to tell colleagues about it. Success, in the form of adoption, erodes margin.
There are three common responses, and each has a cost.
Raise the seat price until the heaviest users are covered. Light users then pay far more than their cost to serve, which invites the question of why they are paying for something they barely use, and slows adoption.
Add a fair-use limit to the seat. This works when the limit is generous enough that most users never meet it and clear enough that hitting it does not feel like a trap. It also requires metering per user, which you need anyway.
Price per use instead. Margin per unit then stays roughly constant regardless of who uses it most.
Per-use margin is flat, but volume risk moves
Tugela's measured cost per summary, including model, platform and a share of the engineering that maintains the feature, was about R5. Priced at R12 per summary, margin is R7 per unit whether a user generates ten summaries a month or four hundred.
That is the attraction of per-use pricing: margin follows usage instead of fighting it. It also matches how the cost is incurred, which makes the economics legible to both sides.
The trade-offs are real, though.
- The buyer carries volume risk, and many buyers dislike unpredictable invoices. An insurer's procurement team may prefer a figure it can budget a year ahead.
- You need trustworthy metering. The customer will want to see what they are being charged for, and disputes need an audit trail per use.
- The unit must be one the customer recognises. "Per summary" or "per claim" is understandable. "Per thousand tokens" is your cost unit, not their value unit, and passing it through makes your pricing look like an infrastructure bill.
- Regeneration needs a rule. If a user regenerates a summary three times because the first two were poor, is that one charge or three? Charging for all three penalises the customer for your quality problem. Charging for one means you carry the cost of retries, which is an incentive to improve quality. Tugela chose to charge per delivered summary and track regenerations internally as a quality measure, which connects directly to Part 2.
Choosing the model
Two questions narrow the choice: how much does cost to serve vary between customers, and how much does the buyer need a predictable invoice?
Most B2B AI features end up in the bottom-right quadrant: a hybrid of a platform fee, a bundle of included uses, and a per-use rate above the bundle. The platform fee covers fixed costs and gives the buyer a predictable base. The bundle is sized so that typical customers rarely exceed it. The overage rate protects margin on heavy use and is set high enough to be profitable but low enough not to feel punitive.
Tugela's eventual offer was a monthly platform fee per insurer, 2,000 summaries included, and R10 per summary above that. For the pilot insurer, that produced an invoice within 10% of what the seat model would have charged on average, with no loss-making users.
Rand prices, dollar costs
A South African company selling in rand while buying AI in dollars has a currency mismatch built into its margin. Part 5 showed how much a monthly dollar bill can move in rand terms. On a thin-margin AI feature, an exchange-rate swing can remove the margin entirely.
Three contract mechanisms help, and they are standard for other imported inputs:
- A price review clause allowing the per-use rate to be adjusted at stated intervals, with notice, when underlying costs change materially. Tie it to an observable index, such as a published exchange rate, rather than to "our costs".
- A pass-through for reductions as well as increases. Model prices have tended to fall for equivalent capability. A clause that only ever moves upwards is harder to sell and easier to resent.
- A short initial term on a new feature, so that the price can be reset once real usage is known. Committing to three years of fixed per-use pricing on an AI feature that has been live for a month is a bet on numbers nobody has measured yet.
Run the margin maths before launch
The process mirrors Part 6, seen from the seller's side:
- Measure cost to serve per unit in a pilot with real customers, including model, platform, engineering share and support. Do not use the model price alone.
- Measure the distribution of use, not just the average. The heaviest decile decides whether a seat price works.
- Choose a customer-facing unit that matches how the customer thinks about value.
- Model margin by usage band under each candidate pricing approach, as in the diagram above.
- Stress-test the exchange rate and a provider price change in both directions.
- Decide the regeneration and failure rule before customers ask.
- Set a review date for the price, and write the review mechanism into the contract.
Tugela's own work in Part 3 also matters here. A seller has an even stronger reason than an internal user to run each feature on the smallest model that passes its evaluation, because the saving goes straight to margin. But the evaluation has to come first. A cheaper model that produces worse summaries will cost more in churn than it saves in tokens.
Closing the series
The thread through all eight parts is the same. Tokens are how AI is metered; they are not how it is valued. Cost becomes a useful number only when it is attached to a unit of work, divided by the outcomes actually accepted, compared with the cost that would otherwise have been incurred, and, when you sell AI, set against what the customer pays. The levers are known: model tier, prompt design, caching, batch, routing and review. The discipline is in measuring the right unit first, so that the levers are pulled for the right reasons.
Start again from Part 1, A token is a unit of compute, not a unit of value. All parts are on the series page.
How CloudNala can help
We help software companies and service providers price AI features they sell: measuring cost to serve per unit in a pilot, modelling margin across usage bands and pricing models, and drafting the review and pass-through mechanisms a rand price needs when the underlying cost is in dollars.
Work with CloudNala
CloudNala helps organisations move from technology ambition to practical execution across cloud, AI, data, platform engineering and digital services.
Whether you are exploring AI, modernising your cloud environment, building a public-sector digital service, or turning an idea into a working MVP, we can help you shape the roadmap and deliver the next step.
Book an AI Cost Review or write to us at consult@cloudnala.co.za