Business Models & Corporate Strategy · Open-access guide

AI business models: choosing an offer, a price and a sustainable margin

Design an AI offer around customer value, a clear charging unit and full delivery costs, including model usage, human review, support and exceptions.

Stroncature Research · Sources checked · Editorial method

An AI business model explains who pays for an AI-enabled result, how the fee is measured and which costs the supplier must carry to deliver it reliably. The strongest starting point is a specific customer task with an observable benefit. Subscription, usage and outcome fees can all work, but each allocates workload and uncertainty differently. An SME should test the complete service, including human review and exceptions, before treating low model-processing costs as evidence of an attractive margin.

What exactly is the customer buying?

Start with the work the customer needs completed. A system that extracts information from supplier documents might sell a usable data file, a reviewed record or access to an extraction tool. Those are different obligations. If the customer must check every field and correct the output, a claim about automated completion can misdescribe the offer. Define the inputs accepted, the output delivered, the quality test and the circumstances that require a human decision.

Stripe’s discussion of AI business models places the commercial result alongside data, delivery and operating constraints. It is guidance from a billing provider, not independent evidence that a particular model will succeed. For an SME, the practical implication is to identify a budget owner and the alternative the customer uses today. Saving time can be valuable, but the buyer may need evidence that the time becomes capacity, faster service or expenditure avoided. Novel functionality alone does not identify the budget.

How should the charging unit be chosen?

A subscription makes the customer’s spending easier to plan but leaves the supplier exposed to variation in use unless the package has defined limits. Usage charging can follow consumption more closely, although technical units may be difficult for a non-technical buyer to forecast. A fee per completed workflow can be easier to understand when the task has a clear boundary. Outcome charging requires both parties to agree what counts as success and which events are attributable to the service.

Stripe’s practitioner interviews on AI pricing distinguish consumption, workflow and outcome measures. Treat that as a design spectrum, not a ranking. For document processing, a per-document fee may be intuitive until documents differ sharply in length and complexity. A base subscription with an included workload and separately priced exceptions may fit better. The important test is whether a customer can estimate its bill while the supplier can estimate the cost of fulfilling that promise.

What counts as a billable outcome?

Outcome pricing needs an operational definition. Fin’s own pricing documentation defines several billable outcomes and explains when an issue is treated as resolved, including circumstances where the customer does not request more help after an answer. This is a provider’s billing definition, not proof that every end customer received a satisfactory result. It illustrates why the measurement rules are part of the product, rather than a small detail left to invoicing.

For a hypothetical appointment-booking service, the parties could charge for a confirmed booking, attendance or a completed paid appointment. Each transfers different risks. Attendance depends partly on the customer; completed revenue may depend on the client’s sales team. A supplier should not accept responsibility for events it cannot observe or influence without pricing that uncertainty. Keep a traceable record of the event, reversals and disputes. A good metric should reduce disagreements, rather than create an expensive investigation for every invoice.

Which costs belong in the unit economics?

Model usage is only one part of delivery. Anthropic’s API pricing documentation, for example, distinguishes input and output tokens and describes separate treatment for caching, batch processing and certain tools. These are supplier-specific terms that can change; they demonstrate why a single headline token price is an incomplete cost model. The customer’s task may involve several requests, retrieval, storage and repeated attempts before a usable output exists.

Measure costs at the level of accepted work. Include human review, specialist escalation, customer support, data preparation and the infrastructure needed to retain or remove records. Separate recurring delivery expense from initial onboarding so that a difficult implementation is visible. Track the distribution as well as the average: a small group of unusually complex accounts can consume the contribution from many ordinary users. Falling model prices will not automatically remove those labour and support costs.

How can an SME test a margin without inventing a benchmark?

Suppose, hypothetically, a supplier charges £600 per month for 1,000 accepted records. Model and infrastructure usage costs £80, human review costs £180 and directly attributable support costs £40. The package contributes £300, or 50% of revenue, before sales costs, development, central overhead, finance and tax. If review doubles to £360 while other costs stay the same, contribution falls to £120, or 20%. These figures are an illustrative sensitivity calculation, not a market price or industry margin.

Run that calculation using pilot logs and fully costed staff time, including the founder’s work. Then ask whether heavier use remains economical under the proposed terms. A headline subscription can conceal unlimited processing or premium support that was never costed. Define usage notices, approval for excess work and a fair process for changing a package. Customers need to understand those boundaries before relying on the service; surprise bills or sudden throttling can damage the relationship even if they protect one month’s margin.

What should a paid pilot establish before wider launch?

A useful pilot tests buying, delivery and continued use together. Agree a limited dataset and a representative workload, then record accepted outputs, rejected outputs, review effort, elapsed time and the amount invoiced. Include cases that are difficult in ordinary operation rather than selecting only clean examples. Where outputs affect important decisions, agree who reviews them and what happens when the service is unavailable. Those responsibilities consume resources and therefore belong in the commercial design.

The launch decision should distinguish evidence of customer value from evidence of supplier efficiency. A client may renew a manually supported pilot even though its delivery cannot yet be repeated economically. Conversely, an inexpensive automated process may solve a task nobody prioritises. Reprice, narrow the task or improve delivery according to the problem observed. The related guides on turning AI time savings into business value and scaling a service business address the organisational work that follows an accepted offer.

Email newsletter

Business Model Monitor

Business Model Monitor follows how AI changes what companies sell and which capabilities they retain. Its cases help founders examine pricing, delivery obligations and the costs behind apparently scalable revenue.

Sign up for the free newsletter

Newsletter sign-up is free. Access to paid reports depends on the subscription selected.

About this publication