Someone Still Has to Guess

I was reading about GitLab Flex, a new way GitLab lets customers make one annual dollar commitment and then use that money across seats, AI credits and other eligible capabilities.

It sounded pretty sensible at first.

Instead of separately committing to a fixed number of seats, some AI usage and whatever else you might need later, the customer gets some room to change the mixture as needs change.

Then I got to this bit.

If there is money left in the Flex balance when the annual term ends, you don't get it back.

GitLab calls it a use-it-or-lose-it annual spend agreement. Reserved credits can be stricter still: they're allocated monthly, and whatever isn't used that month expires.

Oh.

I had apparently misunderstood which part was flexible.

The customer can change what some of the money is spent on.

The commitment itself is still very much a commitment.

And that sent me down a pricing rabbit hole I wasn't really expecting.

Why agree to that?

I haven't been the person making this kind of buying decision, so I don't want to pretend I know exactly how an enterprise buyer would weigh it.

My first reaction was simply that committing money before you know exactly what you'll need sounds risky.

But that isn't quite the decision GitLab is asking a Flex customer to make.

GitLab tells customers to size the commitment from base seat costs, expected credit usage, and some additional room for growth or new capabilities.

So imagine a company that already uses GitLab heavily.

Maybe it doesn't know whether next year's spend will become:

more seats
less seats
more AI
some new capability
some mixture of all of them

But it is fairly confident that a substantial amount of money will go to GitLab either way.

Those are two different uncertainties.

The customer may not be able to predict what the GitLab spend will contain very well while still having a decent idea of roughly how much GitLab spend there will be.

Now Flex makes more sense to me.

The customer isn't getting out of forecasting.

It's making a broader forecast.

Instead of committing precisely to every product and quantity in advance, it commits at the vendor level and gets some room to change the composition later.

That can still go wrong. If the overall commitment is too high, the unused annual balance is forfeited. If usage goes above the balance, GitLab charges overages separately.

So the useful question isn't whether Flex is "more flexible."

It's what the customer is being allowed to be wrong about.

Atlassian is trying something similar

This would have been a GitLab pricing curiosity if Atlassian hadn't announced its own Flex model five weeks earlier.

Atlassian's version is also built around a fixed wallet. Large customers can redirect spend between products, users, Rovo credits and other kinds of consumption instead of deciding the whole mixture up front.

What caught my attention is that Atlassian is developing it with selected enterprise customers rather than rolling it out as the default way everybody buys its software.

That seems important.

A broad wallet probably isn't automatically useful just because a company is large.

What seems more relevant is whether the customer already has a broad enough relationship with the vendor that total spend is easier to predict than its composition.

Something roughly like:

fairly sure how much I'll spend with Vendor A
not very sure what I'll spend it on

That looks like a pretty good problem for a flexible wallet.

Whereas:

fairly sure how much I'll spend
fairly sure exactly what I'll buy

doesn't obviously need much flexibility at all.

And if neither number is remotely predictable, locking in a large annual floor becomes harder to justify.

That's just my mental model, not some rule of enterprise procurement.

But I found something interesting when I went looking at how other companies are pricing AI.

Salesforce is offering several answers at once.

There isn't even one Agentforce payment model

Salesforce gives Agentforce customers several payment options.

There's pay-as-you-go with no upfront commitment.

There's pre-commit, where the customer commits in advance and gets better pricing.

And there's pre-purchase, where the customer pays upfront for a set amount of usage and gets the strongest savings. Salesforce describes that last option as suited to customers with more predictable, consistent usage, while PAYG is meant for things like pilots and unpredictable workloads.

That was useful because it stopped me trying to find the pricing model that AI software is moving toward.

Salesforce itself is offering several.

Its current Agentforce pricing also includes things like Flex Credits and per-user licences.

So maybe the choice isn't simply:

flexible pricing or inflexible pricing?

It might be closer to:

Which thing am I comfortable predicting?

With PAYG, I don't have to predict usage very precisely before I start.

Nice.

But I also don't know the final bill as precisely.

With pre-purchase, I can get better economics.

But now I have to be more confident that I'll actually consume what I bought.

With GitLab Flex, I can be wrong about parts of the product mixture.

But I can't be too wrong about my overall GitLab spend.

There isn't one version where nobody has to guess anything.

Some companies are trying to charge much closer to the result

Then I got to Intercom.

Fin for customer service has been priced around outcomes rather than raw AI activity. When Intercom brought Fin into sales, it chose a qualified lead as the main billable outcome.

Their reasoning is interesting.

Why not charge against the eventual sale?

They considered it.

But too much happens between Fin qualifying somebody and that company eventually becoming a customer. A salesperson runs a demo. The product might have an outage. The prospect's budget might disappear. The deal might die for some completely unrelated reason.

Intercom didn't think closed revenue was a clean enough outcome to price Fin against.

So it moved the billable event closer to the part of the process Fin actually controls: qualifying the lead. The customer defines what "qualified" means for its own business.

That complicated my neat little idea that outcome pricing somehow solves the pricing problem.

Because now there's a new question:

Which outcome?

If you charge too early in the process, maybe you're still charging for activity rather than value.

If you charge too far downstream, the vendor is getting paid according to something it only partly caused.

And if measuring the result requires a giant integration and an argument over attribution, the wonderfully simple "pay for results" idea starts getting messy pretty quickly.

Zendesk has made a related choice in customer service. Its AI-agent billing uses automated resolutions: customer requests handled successfully by the AI without being handed to a human. Its current system also uses an LLM verification step to distinguish some kinds of resolution.

Again, that seems pretty sensible to me.

But it's another decision about where to draw the line.

Maybe pricing is partly deciding which mistake you can live with

By this point I had stopped thinking in terms of:

seats → usage → credits → outcomes

as though software pricing were climbing some evolutionary ladder.

The models expose buyers and vendors to different kinds of mistakes.

With seats, you can pay for capacity that barely gets used.

With pure usage, you can get exactly what you used and still hate the bill because usage was much higher than expected.

With prepaid credits, you can buy too many.

With something like GitLab Flex, you can correctly predict that the product mix will change and still overestimate how much you wanted from GitLab in total.

With outcome pricing, you have to define the outcome and decide how much responsibility the vendor actually has for producing it.

That doesn't tell me which model is actually better.

It just shows me that each one seems to create a different way of getting the forecast wrong.

And buyers don't seem to automatically choose commitment simply because it comes with savings.

Cloud is a useful older example here. Commitment discounts have existed there for years, but Flexera's 2026 State of the Cloud report says fewer than half of organizations use any one commitment discount with a given major cloud provider. It also estimates wasted cloud spend at 29%.

That's cloud rather than SaaS, so I wouldn't use it to predict what GitLab customers will do.

But it was enough to kill my assumption that a sufficiently good discount makes committing an obvious decision.

At minimum, there is more in that decision than the discount.

The portfolio bit is still strange

There is one consequence of GitLab and Atlassian's model that I still find particularly interesting.

Once money has been committed at the vendor level, a new product can become another place for that money to go.

GitLab says new generally available capabilities can be enabled inside an existing Flex agreement without another contract amendment. Atlassian similarly talks about the wallet moving as customers adopt different products and capabilities.

That means a future product might still have to convince the customer:

this is useful.

But it may not always have to start with:

please find us a completely new budget first.

Those are not the same hurdle.

And if one product becomes less useful while another becomes more useful, some spending could potentially move rather than disappear from the vendor relationship altogether.

I can see why that would be useful to the vendor.

It could also be useful to the customer, because being wrong about Product A doesn't necessarily mean being stuck with Product A for the whole year.

There is a tension there that I had originally flattened into "flexibility."

The customer gets more room to move within the vendor.

The vendor gets a stronger claim on the overall pool.

Whether that trade is actually worth it probably depends a lot on the customer, the contract, the discount and how confident they are in the vendor relationship in the first place.

There is at least some buyer evidence that the ability to move money around matters. In a McKinsey survey of 150 enterprise software purchasing decision-makers, 65% rated the ability to move usage or spend commitments between products as very or extremely important.

The same research notes that software vendors with consumption models often vary discounts with the level and type of commitment, partly to balance customer choice with revenue predictability.

That tells me buyers can value the flexibility.

Whether customers like the exact bargain GitLab or Atlassian has constructed is a different question.

We don't have enough history with either model to know that yet.

I stopped thinking this was mainly a story about seats

I started all of this because two companies announced similarly named flexible contracts within a few weeks of each other.

For a while I thought the interesting part was commitment moving from the individual product to the vendor relationship.

Then I thought it might be products competing for money that had already been committed to their parent company.

Both still seem interesting to me.

But looking at Salesforce, Intercom, Zendesk and the older cloud model made the situation look less tidy.

Different companies are making different bets about what can be predicted.

Some let the customer avoid commitment and pay as usage happens.

Some offer better economics if the customer is willing to predict more.

Some ask the customer to commit to a vendor while leaving more of the product mixture open.

Some are trying to charge after a particular result has happened.

I don't know which of these will age well.

I also don't know how buyers will behave once they have a few years of real AI usage to forecast from instead of whatever evidence they have today.

When I first saw "Flex," I read flexibility as though it were an absolute property of the contract.

It isn't.

The question that ended up being more useful for me was simply:

Flexible about what?

GitLab gives customers flexibility over some allocation decisions, but not the annual commitment.

Salesforce can remove the upfront commitment, but then the eventual bill moves with usage.

Outcome pricing gets closer to charging for value, but somebody still has to decide what counts as the outcome.

For now, I'm less interested in which model eventually wins than in which forecast each one is asking the customer or the vendor to make.