Why the Customer Relationship is More Important Than Ever Before

A lesson from selling air traffic control simulators and why it matters for the economics of AI in SaaS.

We sold air traffic control simulators. We assumed people bought them to train air traffic controllers.

That seemed a reasonable starting point. It was also an inadequate understanding of our market.

We had several types of customer, with different reasons for buying and different ways of reaching a purchasing decision. Military and civil government customers had budgets, evaluation criteria and procurement processes that differed from those of for-profit aviation colleges. International and domestic customers operated to different timelines and purchasing requirements.

The colleges taught us a particularly useful lesson and it was revealed during a casual conversation. Training capability mattered, of course. But a primary commercial driver was marketing to the parents paying the fees. The simulator wowed the parents with its high quality 3D graphics and sound effects. We were evaluating our product through its training features while those customers were evaluating its ability to attract enrolments.

We treated too many of these customers alike in our marketing and pricing. We understood what our product did better than we understood why each customer would spend money on it.

I think SaaS companies planning AI capabilities need to pay close attention to that distinction, before they approve the project.

The economics of an individual feature

Traditional SaaS companies generally establish their pricing around the value of the whole product or a package of capabilities. They do not need a separate commercial case for every feature.

A feature might help win a competitive evaluation, improve retention or make the product easier to use. Its contribution can justify development even when nobody would pay for it separately. Once built, it can often be delivered repeatedly at relatively little additional cost.

An AI capability can introduce a different calculation. Every use may incur inference, compute or tool costs. Agentic workflows may require several steps, retries and checks to complete a task. The cost of serving a customer can therefore change with both the volume and the nature of the work.

Development expenditure still matters, but it is only part of the commitment. The supplier is also funding the continued execution of that capability.

That means an AI feature can become popular without becoming profitable. If usage grows inside an existing subscription, the delivery bill may grow without a corresponding increase in revenue.

It does not follow that every AI feature needs its own price. It does mean that its economics need to be understood, including how its value will be recovered through the wider subscription.

“It will reduce support costs” is a starting assumption

Consider a proposed customer support chatbot.

The pitch is familiar: it will answer questions, reduce the workload on support staff and save the customer money.

Before approving development, I would want to know which customers have that problem and what solving it would actually change for them.

A business with a growing support backlog might value the ability to handle more customers without recruiting. Another might have a small support team whose staffing cannot realistically be reduced. Saving those people some time could be useful, but it would not necessarily reduce expenditure.

A third customer might care most about answering questions outside working hours. Its economic benefit could come from retaining customers or converting enquiries into sales. A fourth might face complex support issues that require extensive human checking, leaving much less benefit than the demonstration suggests.

The same capability can have a different commercial value in each case. It may also cost different amounts to serve those customers.

If we market it to all of them with the same promise and price it on an assumed average benefit, we risk repeating the mistake we made with simulators.

What does AI add to the tools the customer already has?

Consider another use for a chatbot: delivering information from the SaaS product itself.

“How are my project margins tracking against budget?”

The chatbot retrieves the figures and presents an answer. It looks useful in a demonstration. But a traditional SaaS dashboard or report can already provide those figures using deterministic tools.

The commercial question is how much additional economic value the AI chatbot creates over that existing capability. If the customer gets essentially the same information, presenting it through a conversation may add very little. The supplier has introduced an ongoing AI delivery cost without establishing a corresponding increase in customer benefit.

Easier access could justify the investment where finding and interpreting the information currently takes substantial effort. That benefit needs to be established against the customer’s existing tools and working practices. The value of knowing the project margin cannot simply be attributed to the chatbot delivering it.

Now consider a capability that proactively predicts margin deterioration, without waiting for the user to ask. It identifies a developing trend early enough for the project manager to investigate and act before more profit is lost.

That has a different commercial proposition. The customer may be able to protect margin that would otherwise disappear. The supplier can build its case around the additional warning, the opportunity to intervene and the financial difference that intervention could make.

The distinction matters when deciding what to build. A chatbot that reports existing figures and a capability that predicts emerging losses may both be sold as “AI project intelligence”, but their potential economic value is quite different.

Before attaching a price to either, establish what the customer can do with it that they cannot already do as effectively with their existing software. A useful answer from a chatbot is not, by itself, evidence of additional value worth paying for.

“How much will it cost me?”

Now imagine telling a customer that your new capability comes with outcome-based pricing.

“How much will that cost us?”

“It depends on how many tokens you use.”

You have just given the customer a technical consumption measure when they asked for a commercial commitment. Unless they can translate their workload into a dependable estimate of consumption, they still cannot budget for the purchase.

Perhaps you offer a fixed subscription with a token allowance and additional charges when it runs out. The customer will reasonably ask how much work that allowance will cover. If you cannot give a credible answer, the fixed price offers little certainty about the cost of completing their work.

The difficulty is the non-deterministic element. Similar tasks can take different paths, consume different amounts of context and require different numbers of retries or checks. The customer may know how much work they need done without being able to predict what your system will spend doing it.

A token cap puts a ceiling on expenditure. It does not establish how much useful work will be completed before the ceiling is reached. The customer could spend the entire allowance and still have work left to do.

For a buyer, adopting a tool with costs that vary in ways they cannot reasonably forecast or control is a poor basis for a financial commitment. A supplier cannot assume that transferring this uncertainty to the customer makes an otherwise weak commercial model viable.

“Then make it $200 a month, unlimited”

A fixed price of $200 a month for unlimited use gives the customer a much clearer proposition. They know what they will pay, without having to forecast tokens or negotiate what counts as an outcome.

But the uncertainty has not disappeared. The supplier now carries the commercial risk.

Revenue from that customer is fixed at $200. The cost of serving them is not. It can change with how often they use the capability, the work they ask it to do and the number of steps, retries and checks the system needs. Even a similar volume of apparently similar work can produce a different bill.

A customer who uses the service heavily may be getting excellent value while costing the supplier more than the subscription brings in. More customers on those terms can mean larger losses. Popularity is an expensive way to discover that the pricing was wrong.

This is the danger of offering fixed, unlimited pricing before understanding the delivery economics. It resolves the customer’s concern about an unpredictable bill by committing the supplier to an uncertain cost of fulfilment. A token cap or overage charge may protect the supplier, but it brings back the customer’s original question: how much will it cost to complete our work?

Fixed pricing can work where the supplier has enough evidence about usage and delivery costs, sufficient margin and controls that support the promise being sold. “$200 a month, unlimited” is a poor commercial commitment when those conditions have simply been assumed.

What exactly is an outcome?

Outcome-based pricing also requires agreement on what the customer is paying for.

Has a support chatbot delivered an outcome when it answers a question, when the conversation ends, or when the customer’s problem is resolved? Who decides whether the problem was resolved? What happens if the customer returns the next day, or a member of staff has to correct the answer?

These details affect both the bill and whether the customer believes it is fair.

Even a clearly defined outcome does not necessarily have a consistent economic value. Imagine a chatbot spending twenty exchanges resolving a minor issue with a low-value purchase. Another conversation answers one straightforward question and helps secure a substantial order. The first interaction could cost more to deliver while creating less economic value.

Charging by tokens could therefore make the customer pay more for the less valuable result. Charging the same amount for each outcome leaves the supplier absorbing differences in delivery cost, while the customer receives outcomes of different value.

That does not make outcome-based pricing impossible. It means counting outcomes is insufficient. The supplier needs to understand the likely mix of work, the costs of completing it and the value customers attach to it. A model that works across one customer group may fail across another.

Our simulators had the same basic purpose, but their commercial value depended on who was buying them. Calling two chatbot interactions “successful outcomes” does not make their economics equivalent either.

Establish the commercial case before development

There is a tendency to start with an AI idea, establish that it can be built, and then ask sales to find customers for it. Pricing becomes an exercise in recovering the costs already committed.

By then, the most useful opportunity to challenge the economics has passed.

Before launching the project, the company should have a credible view of the target customer, the buying driver, the additional economic value over existing tools and the price that customer might accept. It should understand whose budget would fund the purchase, what evidence would be required and how long procurement might take.

That gives the development team something commercially meaningful to work within. If the likely selling price cannot support the expected delivery cost at an acceptable margin, the scope, architecture or target market needs to change. Sometimes the right decision will be to stop.

Nobody can know all of this precisely before building. Estimates will need testing. But uncertainty is a reason to validate assumptions early, while changing course is still relatively inexpensive.

The proposed pricing model must pass the customer’s purchasing test as well as the supplier’s margin calculation. Can the buyer budget for the work? Can they understand what they will receive? Who carries the cost when the system needs another attempt? Those questions belong in the original commercial case.

A closer relationship has a practical purpose

This is why I believe the customer relationship becomes more important when SaaS companies introduce AI capabilities.

The supplier needs enough access and understanding to distinguish an attractive demonstration from a worthwhile purchase. That means talking to the people doing the work, the people managing it and the people authorising the expenditure. They may have quite different views of the benefit.

It also means checking what happens after deployment. Does the customer realise the expected benefit? How much review and rework remains? Has the capability created enough value to justify continued spending?

You do not need a bespoke consultancy assignment for every customer. You do need to recognise meaningful differences between customer groups and test the assumptions behind your proposition.

Our simulator customers shared an interest in air traffic control training. That did not give them identical commercial priorities, budgets or purchasing processes. Treating them as though it did weakened our marketing and pricing.

Before approving your next AI project, ask which customers would fund it, why they would do so, and whether the price they will pay supports the cost of delivering it. Then ask whether those customers can commit to that price with a reasonable understanding of what their money will buy.

If the answers are unclear, there is more commercial work to do before development begins.