Forecasting AI Support Spend Without Surprises

Usage-based pricing solves one problem and creates another. It solves alignment — you pay for outcomes, not idle seats. But it introduces variance, and variance is what finance teams fear most. A model that bills per resolution can, in principle, produce a bill that scales with a traffic spike, a viral incident, or a product bug that floods support. "Pay for what you use" is only adoptable if you can also answer the next two questions: how much will I use, and how do I stop it from running away?

The first requirement is a hard ceiling. Every plan should support a spend cap — a number beyond which the system will not bill you, full stop. This is non-negotiable for budget owners. A cap converts an open-ended liability into a bounded one. It changes the conversation from "what might this cost?" to "this will cost at most X," which is the only form a CFO can actually approve. A usage-based product without a cap is asking the customer to underwrite the vendor's traffic forecasts, and that's a bad trade.

The second requirement is early warning. A cap that you hit silently is a service interruption waiting to happen; a cap you approach with alerts is a planning tool. Spend alerts at meaningful thresholds let you react before anything breaks — raise the cap deliberately, investigate a spike, or accept the higher month with eyes open. The point of alerts isn't to nag; it's to make sure every increase in spend is a decision someone made, not a surprise someone discovers on the invoice.

The third requirement is a unit you can reason about. Per-resolution pricing has a quiet advantage for forecasting that seat-based pricing lacks: the unit corresponds to a real, countable event. If you only pay on verified resolutions, your bill is a function of how many issues the AI actually solved — which tracks your resolved-ticket volume, a number your support org already understands. That's far more forecastable than "tokens consumed" or "messages processed," units that swing with prompt length and model behavior in ways no operator can predict.

But forecastability depends entirely on what does and doesn't count. This is where the billing definition and the budget meet. If handoffs and abandoned chats are free, then a traffic spike that overwhelms the AI and triggers lots of handoffs costs you nothing extra in AI fees — the cost lands where it should, on human capacity, not on a meter charging for failed automation. If, instead, your vendor bills for handoffs and deflections, your spend becomes least predictable exactly when volume is highest and quality is lowest. Strict resolution definitions aren't just fairer; they make spend behave sanely under stress.

Then there's reconciliation, the unglamorous part that determines whether anyone trusts the forecast. A forecast you can't check against reality is a guess. If every charge produces a readable receipt — what was asked, what was resolved, the evidence behind it — your finance team can reconcile the invoice line by line, your support leads can sample charges for quality, and a variance in spend has an explanation you can actually go read. Disputable charges close the loop: if a resolution was wrongly billed, you challenge it and it's reversed. Reconciliation is how a usage model earns the right to be in the budget every quarter.

Put together, forecasting AI support spend isn't a spreadsheet exercise bolted on after purchase. It's a property of how the product is built: a forecastable unit, a hard cap, threshold alerts, a fair definition that doesn't bill failures, and per-charge receipts you can reconcile and dispute. We're early, and we won't pretend to hand you a precise multi-quarter model from data we don't yet have. What we will commit to is the controls that make spend knowable — caps and alerts on every plan, $0 for handoffs and silence, and a receipt on every charge — so that the surprises live in the receipts you can read, not the invoice you can't.