SaaS Factory · 8 min read
Subscription, hybrid and outcome based pricing. AI is rewriting how SaaS companies charge, and staying just with subscriptions is not an option.
By Glyn Trott, — SaaS Factory CEOI was recently at the AWS conference in London and one of the talks on how pricing models are evolving caught my attention. AWS walked through the trends they are seeing across their customer base, the data behind it and where it is heading.
What they were seeing is that some AWS customers were not offering one billing model anymore. They were running three, side by side, at the same time.
And the direction of travel was clear, with it gravitating towards metered use and outcome pricing way out on the horizon.
One example was Intercom, the customer support platform.
They started where everybody starts. Subscriptions and seats, and with the arrival of AI some of the licence and user tiers got AI capabilities and tokens included.
Then they went hybrid. Keep the subscription, but buy extra tokens for the AI agents on top. That is the moment metered billing starts, as you are no longer just paying for access, you are also paying for consumption, and the bill moves with how much the AI actually does.
Then they introduced outcome based pricing. Cost per solved ticket, not per login or seat. Per ticket actually resolved.
Three models. Same company. Same product. The customer picks.
Seats made sense when humans did all the work. One human, one login, one licence.
That starts to change the moment an agent does some, if not all, of the work instead. The agent does not need a seat in the way a person does. It needs capacity. It runs at 3am and clears a hundred tickets while your team sleeps.
This is where consumption based billing, or metered billing, starts to kick in. You are no longer charging for access to the software. You are charging for the work it does.
The pushback in the AWS conference room was immediate.
The subscription is fine, you can budget and get approval for that. It is the tokens on top they cannot forecast. They do not know what next month looks like, they cannot put a number in the forecast, and nobody wants an open ended line on a P&L. So they panic.
I understand it. You employ people, buy subscriptions, have a fixed cost and fixed capacity. A person can only solve so many tickets a day. Opex is controlled and the P&L is protected.
The EBITDA never comes under pressure from a busy week you cannot control.
A token line does the opposite. It moves with demand, a busy month costs more, and nobody can sign that off in advance.
But let's look at the comparison for a second.
The thing doing that work before was a person. That person cost you a salary, national insurance, pension, holiday, sick cover, a laptop, training and a manager. That cost is consistent, sizeable and payable whether the work comes in or not. It does not flex down in a quiet August, and it will also go up at the start of a financial year, at the start of a tax year, or if a government introduces new employment costs.
Nobody calls that unknown or unforecastable. It is normal and reassuringly predictable.
Dylan, SaaS Factory CTO, and I had the classic reaction when we started paying for consumption.
We run on Anthropic. A big part of what SaaS Factory does is built on tokens we cannot fully predict. We obviously work within forecasts and budgets, so at the start we were nervous, we watched it tick up, sometimes every day, we started to panic and got our reasons ready for month end reporting. But we also talked about it and then we built habits around it.
We started to get very clear about the instructions we were giving, because we knew every one of them consumed tokens. We also keep looping and improving SaaS Factory to be really efficient, using the minimum amount of tokens for the maximum amount of output.
And there is an even simpler, more elegant solution. We ask Claude to make it cheaper.
All because of forecasts and having to report to finance, we had to really understand how Anthropic billing worked.
On a fixed AI plan, some people will run straight into their daily, weekly and monthly limit, back off, wait, then go again. They are extracting maximum value out of their subscription.
What they are really doing is paying with time. They accept the delay because waiting is cheaper than upgrading. Then the waiting gets expensive enough, and they buy the time back. Either pay for additional tokens or take a second seat, just so they can bounce between the two when one maxes out. By the way, Dylan has four separate accounts on Claude and cycles through them.
That tells you something about what a billing model actually does. It does not just collect money, it shapes behaviour. It can let a customer set their own exchange rate between time and money, and they do the sums to work out the value.
And this can impact revenues. One of your best customers wanted to use more of your product. They hit a wall, worked round it for a while and eventually built a workaround. That is friction that takes time for them to work out, and it slows down the speed to revenue every business needs to keep accelerating.
This is what we have done at agentOS.com, our sister company to SaaS Factory. We introduced AI Users.
An AI user is a hybrid. Part subscription user, part consumption, inside a monthly subscription. It has a set capacity of tokens for the month, and when that capacity is used up you either wait until the month resets or you take on another AI user with fresh capacity to carry on the work.
By design, this is not tokens on account. It is a user with a defined capacity, exactly like hiring a person. And as with people, if your team is at full capacity, you take on another one.
We called it an AI User and not an AI Agent on purpose. Customers already understand what a software user is, its fixed cost and its known capacity. It gives them AI capacity and the tokens behind it, while knowing what they are going to pay each month.
SaaS Factory built SaaS Factory, and our billing model uses the SF payment rail.
We offer a low level subscription that essentially keeps the lights on. After that, we have hybrid metering across the entire tech stack and business stack. From AI tokens, Vercel hosting and Neon's database use, to business stack services from Resend emails and Vibe Prospecting prospect data, to Stripe's payments.
Then finally we have an outcome based 'Build for Me' service, where you tell us what you want built, from a simple feature or API connection to a full product. That is an outcome based billing model.
All three billing models AWS shared.
As we build in new tech and business stack services, we are introducing more metered revenue generation. We are a business, so we add a very nominal markup on the metered use. But the important thing is our customers decide whether they need those services at all, and how much they want to use them. We are not adding layer upon layer of services and then at some point having to push an upgrade path or introduce a higher price increase as we added more value.
SaaS Factory has the billing framework that enables all this, not just for SaaS Factory, but also for your products built using SaaS Factory.
Now flip it round. We meter you, and you can pass that straight on to your customers. Or you can plug in services that have nothing to do with us and bill those on outcome based or metered pricing. Or you can wrap the whole lot into a classic subscription and keep it simple.
You do not throw out subscriptions. The AWS data was not saying that.
Stop treating pricing as one billing model.
I am not entirely sure it is, but it could be.
Here is the scenario. Your software goes down and support tickets come in at ten times the normal rate. On outcome based pricing you have just spent ten times more money, at exactly the moment your product is under pressure beyond your control. The worse your week goes, the bigger the bill.
But the fix could be simple, and it is the same fix a human team gives you for free. If ten times the tickets landed on a human support desk, costs do not explode. It would just take longer. It is a capacity issue, so things slow down.
So why not limit AI resolved outcomes? You restrict them by slowing down and stopping the instant solving.
People would queue. That is not a failure in genuine crisis situations. That is capacity doing its job.
Outcome based pricing could build the same thing. Caps, restrictions, rates and a queue. Outcome based pricing without a ceiling is a bet on nothing ever going wrong. Outcome based pricing with a ceiling is just a support team with a limited capacity.
Put your mission statement into SaaS Factory and get a product out with all three pricing models live from day one.
Speed to revenue, not just speed to code.
Glyn Trott founded agentOS in 2004 and sold it to Constellation Software Inc (Volaris Software Group) in 2024. He remained with Volaris as CEO of agentOS Proptech Group, and co-founder of SaaS Factory with his CTO, Dylan Davies. He lives in Wales, competes in CrossFit, and still hasn't worked out how to connect GitHub to Claude Code.
