Over the years, we’ve been involved in many OSS procurement events and have seen a variety of different pricing models proposed by vendors.
Being software, most vendors have quite a lot of pricing flexibility (others, not so much!). Naturally, pricing models can significantly influence a company’s decision to select one vendor over another so I’m always interested to see each vendor’s pricing approach. Traditional seat-based licensing has been a popular pricing strategy across many software markets, but there are trends that could decrease its relevance into the future. More on that later.
The Seat-Based Licensing Conundrum
Seat-based licensing ties the cost of the software to the number of users or “seats” that require accounts on the software platform. On the surface, this may seem straightforward, especially for organisations with a static number of users or predictable headcount growth. However, the nature of OSS can make this model problematic.
A single OSS implementation can involve hundreds, if not thousands, of users—each with different levels of interaction with the system.
I’ll cite an example from a couple of years ago when we were helping a client to identify a best-fit workforce-management / field-services-management (WFM/FSM) solution from the 35-40 vendors servicing this market. As you probably already know, these WFM/FSM solutions are used to schedule field technicians, many of whom are contractors. This particular client had a network with a large geographical footprint and had a contractor database of over 25,000 contractors. However, a vast majority of these contractors were simply database records. They were often not engaged for long stretches of time, sometimes going years without being assigned to a project by this client. Yet under the seat-based pricing models of most of the WFM/FSM vendors, every one of these contractors must occupy a “seat” in the system. Under this example, the client would’ve been paying millions for “shelfware” – ie. having large numbers of licences that are essentially sitting idle for a majority of the time.
Seat-based licencing suits some clients but this inflexibility becomes ever more pronounced at clients where the number of users, contractors or temporary assignees increases. The prevailing seat-based pricing forced this client to choose between overpaying for unused seats or under-investing in a system that could optimise their workforce. By contrast, there were only a few WFM/FSM solutions that bucked the trend of seat-based licencing, but weren’t as functionally fit for this client’s needs.
A conundrum indeed.
The Impact of Inflexible Pricing Models on Vendor Selection
In this particular case, rigidity in pricing was a major barrier to vendor selection.
This issue can be further compounded by the diverse needs within an organisation. Different departments or regions may use OSS tools at varying intensities. For instance, network engineers might be heavy users – in one system all day, every day – while other departments only need sporadic access for specific tasks like data analysis or report generation. A one-size-fits-all pricing model fails to account for this variety of usage patterns within a client’s organisation, leading to suboptimal usage, spend and ROI for the client.
Rigid seat-based pricing models may be good for the vendor, but not always good for meeting prospective client needs and constraints.
How AI Impacts Seat-based Pricing
However, a rising trend may make seat-based pricing not so good for the vendor either. The rapid adoption of AI, zero-touch automation, and other evolving “efficiency” technologies will continue to change our ways of working, It seems likely to expect that as software gets more automated, there will be less need for user accounts. Rather than having an ever-growing number of seats that add to the vendor’s coffers, AI agents are likely to cannibalise the number of seats, and therefore reduce the revenues of vendors that have seat-based pricing.
Salesforce, a giant in the Customer Relationship Management (CRM) space, is evolving its pricing strategy due to its shift towards AI-driven systems and processes. Salesforce CEO, Marc Benioff recently indicated the shift from seat-based pricing to consumption-based pricing, where customers pay per conversation or task executed by AI agents rather than per seat. This type of model would allow for more granular control over costs, enabling businesses to pay only for what they use. It protects the vendor, but is it also beneficial for the clients too?
On the back of Benioff’s talk, I’m starting to wonder whether seat-based pricing models might begin to evolve in the OSS industry too.
In an OSS context, usage-based pricing is already common. For example, instead of charging for the number of users with access to the system, vendors often charge based on metrics like:
- Number of transactions (eg network activations, changes processed, incidents raised, etc)
- Data usage or storage
- Number of devices managed
- API calls made for integration purposes
- Number of trouble tickets managed
- Tasks or workflows completed by AI agents
Given that OSS often reside on cloud-hosted infrastructure these days, usage-based hosting costs are already often passed on to clients.
When structured attractively for clients, usage-based pricing can reduce friction for organisations. It can allow them to adopt a fully-functional platform from the start and incrementally scale their usage based on real needs, whilst avoiding paying for unused capacity or functionality.
The Case for Hybrid Models
That said, a pure shift to usage-based pricing may not be suitable for all OSS applications. Hybrid models, combining elements of both seat-based and usage-based pricing, could offer the best of both worlds. For instance, a base fee could be charged for core system access, while variable costs are layered on top based on the number of activations, transactions, or automation tasks performed.
These hybrid models could also provide greater predictability in pricing for businesses while still allowing the flexibility to scale. For example, a large telco might pay a fixed price for access to an inventory management system but incur additional fees for each network build-out or service activation managed by the system.
Adapting to Meet the Needs of a Dynamic Market
As OSS platforms become more sophisticated and AI-driven automation increases, the traditional seat-based pricing model may become an obstacle rather than an enabler of growth. The evolving landscape requires more flexible, usage-based, or hybrid models that align with how businesses actually use OSS systems—particularly in industries with dynamic workforces and variable demand for system access.
Vendors that offer flexibility in their pricing will likely have a competitive edge, as they reduce financial friction and make it easier for businesses to justify the evaluation, selection and expansion of OSS tools. Conversely, vendors that cling to rigid models may find themselves left behind as customers demand more agile, cost-efficient pricing strategies tailored to their operational realities.
The Missing Piece
However, there’s one big elephant in the data centre.
Organisations don’t mind consumption-based pricing if they can guarantee a profit uplift on every unit of consumption. For instance, if an OSS costs $1 per transaction, but can be demonstrated to reduce cost to serve (via automation) by $2 and generate $4 in profit (not just revenue), then it’s a win for the client. This is a profit-centre OSS. As OSS rainmakers, it’s our responsibility to help clients structure their OSS business cases to be highly attractive investments to project sponsors. It’s OSS projects that help the OSS industry grow and thrive.
If it’s consumption-based pricing (eg number of devices managed) and there’s no way to associate the software costs with any profit uplift (other than the vendor’s) then it’s purely a cost-centre OSS for the client. As OSS practitioners, we need to do whatever we can to avoid the cost centre model. I’m looking at you, vendors, in particular here (but I’m eyeballing everyone here, including myself). It’s complex, risky, time-consuming, full-friction, cost-centre OSS that give our industry a bad name!
What are your thoughts? What good (or bad) pricing models have you seen? How will pricing models change in future? Feel free to share your thoughts and/or stories in the comments section below.