A per-seat contract works because the cost of serving a seat barely moves. One user generates roughly the same number of tickets this month as last, so a flat fee and a known cost-to-serve produce a predictable margin. That assumption is the foundation the entire managed services industry is built on.

AI breaks it. The cost of running an automation depends on how often it fires, how much text it reads, how large a document somebody uploads and whether a workflow gets stuck in a loop at two in the morning. The same service can cost you four pounds one month and four hundred the next, and nothing about the contract will have changed.

So the question is not whether to charge for AI work. It is which parts of it belong in a fixed fee and which parts must never go anywhere near one.

Split the contract into three, and price each part differently

The mistake is treating AI as one line item. It is three, and they behave nothing alike.

The first is the work you already do. Helpdesk, patching, endpoint security, tenant support. Predictable cost, predictable fee, and it stays exactly as it is. If anything this layer gets more profitable as you automate your own service desk, because your cost to serve it falls while the price does not.

The second is the management of the AI itself. Keeping permissions tidy so a generative search tool does not surface the payroll file, maintaining prompt libraries, watching for drift, running the quarterly review where somebody senior decides what to do next. This is skilled recurring work with no variable input cost, which makes it the highest-margin thing in the contract. Price it as a flat monthly retainer.

The third is raw consumption. Tokens, API calls, compute units, credits. This is not a service you provide. It is a utility the client uses through you, and the moment you swallow it inside a fixed fee you have written an insurance policy against your own client's behaviour without pricing the risk.

Keep those three separate on the invoice. A client who can see them separately will argue about the right things.

Three ways to handle the meter

Let the client own the account. Provision the workloads inside the client's own cloud subscription so the hyperscaler bills them directly, and charge a modest handling fee for monitoring it, usually in the region of ten to fifteen per cent, or fold that into the management retainer. You are completely insulated from a spike. Your top line is smaller and your sleep is better. For larger clients this is the right answer almost every time.

Sell a capacity bundle. Include an allowance in the monthly fee, say a fixed pool of credits or tokens, with an agreed rate for anything above it. The client gets a predictable number and you get the volume discount on capacity bought in advance. This only works if you actually watch the meter, because an unbilled overage is a discount you did not decide to give.

Price the outcome and stop talking about tokens. For a discrete automation with a stable shape, charge per completed unit of work: per invoice reconciled, per claim processed, per report produced. The client understands it immediately because it maps to something they already count. Your margin comes from making the pipeline cheaper to run than the unit price, which is a problem you control.

The third option is the strongest position and the one that requires the most evidence. You cannot quote a price per invoice until you know what processing an invoice currently costs, and most clients do not know either.

The controls that stop a bad month

Whichever model you pick, the technical guardrails are not optional, because the failure mode is fast and silent.

Set hard spending caps at the provider, not just alerts. An alert tells you about the money after it has gone. Configure automated warnings at half, three quarters and ninety per cent of any allowance. Constrain each automation's context window and maximum output so a single oversized document cannot consume a month's budget in one run.

And baseline your users before you price anything. Technical staff and senior people consume several times what an administrator does, so an average per seat calculated across a whole company will be wrong in both directions at once.

Rewrite the agreement before you sell the service

Two clauses matter more than the pricing model.

Take AI consumption out of anything labelled unlimited. Most managed services agreements promise unlimited support in some form, and that wording was written when the marginal cost of support was an engineer's time. Exclude token, compute and model API costs explicitly, in the contract, before the first automation goes live rather than during the argument about the first big bill.

Then fix your service levels to the things you control. Never promise accuracy. A generative system produces a probabilistic answer, and a service level that guarantees correct output is a claim you cannot honour and should not make. Commit instead to availability, to response latency, and to how quickly a human picks up an exception. State plainly in the scope that outputs are recommendations requiring verification where the decision matters, and define who does that verification.

Move clients at renewal, not mid-contract

Do not reopen a live agreement to add a consumption layer. It reads as a price rise, whatever the arithmetic says.

Bring it in at renewal, or attach it to a new piece of work the client asked for. The cleanest entry is a paid assessment: a fixed-fee engagement that audits where AI is already being used, which processes are worth automating, and what the running cost of each would actually be. That last number is the one that makes the renewal conversation easy, because you are no longer proposing a pricing model. You are showing them a cost, against a saving, for a process they already recognise.

The part most providers get wrong

The pricing model is not the hard bit. The hard bit is that value-based and outcome-based pricing both require a baseline, and almost nobody has one.

If you want to charge a share of the saving, you need to know what the process costs today: how many people touch it, how long each step takes, how often it runs. If you want to charge per invoice, you need to know what an invoice costs to process now. Without that, you are quoting from a feeling, and the client's finance director will find the hole in about ninety seconds.

This is also the honest argument against going straight to value pricing. Your first few engagements will not have a baseline worth the name, so price them as fixed fees, measure properly while you deliver, and earn the right to the better model on the third one.

abi. Clone for MSPs produces that baseline from interviews with the client's own team: the processes, who runs them, how often, and the hours each one consumes, costed at the client's own rates. It is the same map the assessment is built on, and it is what turns a pricing conversation into an arithmetic one.

The providers who win this work will not be the ones with the cleverest rate card. They will be the ones who can say, with evidence, what the work costs now.