There are several distinct pricing models for the on-going use of a Software-as-a-Service (SaaS) offering.
Often there will be tiers in which the cost increases as the capability (example: storage) or features increase; either for all users in a customer's company or on a persona basis. Also these models often have increasing discounts for an increasing amount of pre-committed volume; with an additional “overage” fee for when a customer surpasses that volume.
Per User or "Per Seat"
Pros: Easy to calculate and allocate, encourages adoption and increased usage by users who have a license or seat.
Cons: Discourages adoption across a company by creating a barrier (seat license) for potential infrequent users - who might become frequent users. Slack’s per-active-user model partially addresses this by only charging for users have been active in the last two weeks (https://www.quora.com/Who-pays-for-Slack)
Examples: Salesforce (CRM). Has a standard per use licensing model which increases as the number of users and the capability increases (currently from $25/month to $300/month). https://www.salesforce.com/editions-pricing/sales-cloud/
Pros: Enables adoption from the occasional to the power user which helps make the offering ubiquitous across the client's company and significantly increases its value and impact. (This is Concur's pricing model and it may be a bit easier to do since an expense management system can be mandated if it is the only way an employee can be reimbursed. Opinions are my own, but I work for Concur).
Cons: For some high price per transaction offerings, the lack of an all-you-can-eat model can limit usage for a given user or on a given project.
Examples: Concur https://www.concur.com/en-us/small-business/expense.
Note: A variation of this per-number-of-transactions model is a per-$-of-transaction model. For example it seems that Zuora, a subscription billing company (so helps actualize pricing models), bases their model on the amount of subscription revenue the customer has on their platform. https://www.quora.com/Does-anyone-know-the-cost-to-use-a-solution-like-Zuora
Per User or Per Transaction Freemium (free is often ad-supported)
Pros: Enables easy adoption
Cons: Must have compelling enough capabilities that users will adopt free version; but still significant enough differentiation that users will upgrade to paid version.
Examples: Slack: https://slack.com/pricing. While Slack has a standard per user model, they also have a free version "For small teams wanting to try out Slack for an unlimited period of time” So it doesn't limit time, but it does limit storage (and other premium capabilities) so that small teams can find value.
Based on the value of the project (construction management) or portfolio (financial assets under management) that is benefiting from the offering.
Pros: Encourages viral adoption for all users and third party partners across a project (leading to familiarity and possible adoption on future projects). The benefits of this type of model is that it encourages interactivity and adoption with all the participants involved; both by the subscribing company and other third parties (often subcontractors).
Cons: This all-or-nothing approach makes it unsuitable for use on a small portion of a given project; this obviously makes it difficult for gradual increased adoption across entire project.
Examples: Some financial services SaaS products and some construction management products such as Aconex, a construction project management tool. Aconex drive adoption of their “project wide solutions" by including "unlimited access to training and support resources for every organization you work with.” (From certain sources it seems that Aconex contends with the cons of this model by offering an enterprise model for companies that adopt their tool across many projects and a per user pricing model when the tool is just used for a small portion of a project).
Per Resource Used (or Pay-as-You-Go):
This is more common in the rent-a-resource world of PaaS/IaaS where providers will charge based on resource usage; example per CPU or per GB storage.
Example: AWS (https://aws.amazon.com/ec2/pricing/) which has per hour (and per second) pricing that can vary depending on required availability of service, "on-demand" is more expensive than "spare capacity" pricing.
Per Outcome or % of Savings:
While many offerings claim a hard dollar ROI, a pricing model which is based on a percentage of that return on investment (such as savings) can be compelling.
Pros: Obviously aids adoption since the buyer only pays if they received the guaranteed benefit
Cons: Only certain offerings have specific well-defined financial benefits such as savings; there are specific companies who have moved away from this models since it leads to disagreements with their customers over the specific savings achieved.
Examples: Vat Reclaim: TaxBack https://www.taxback.com/en/corporate/vat-recovery/ and VATiT: https://www.vatit.com/en/page/vat-recovery
Per Company (Flat-rate or tiered)
For simple services provided by SaaS providers - https://www.cobloom.com/blog/saas-pricing-models
Open Source Model
Open sourced companies often charge for support or additional features (in which case it could be consider a type of freemium model). https://techcrunch.com/2016/02/09/the-money-in-open-source-software/
Examples: RedHat (Linux) or Docker (containerization)
Some offerings are either free or sold as a considerable discount as a loss leader for other products or services that are provided by the company (such as computer hardware).
Hybrid Model: As noted by McKinsey, companies can use hybrid models that include both user and non-user metrics. https://www.mckfastgrowthtech.com/time-rethink-per-user-pricing-enterprise-saas/
Price as a Client Buys: Almost as bad as trying to convince a prospect that they have a problem that you can solve, it makes the sale process more difficult if you have to convince the customer to purchase your solution in a manner that isn’t aligned with their business and how they typically buy services. Therefore you should understand how a typical customer buys a solution like yours before you define your pricing model.
Pricing Strategy: This blog posts suggests a few different models used to price a SaaS offering, but it doesn’t address the more complex question of what should your price be considering a given model. (One simple model is the three C’s: cost-based pricing, customer value-based pricing, and competitor-based pricing.)
On-Premise: SaaS pricing models are typically distinct from on-premise pricing model which are generally based on a one-time perpetual license plus an on-going service and support fee.
Non-Profit Pricing: Many of these companies provide a free or significantly reduce pricing for non-profits which is a good cultural signal about the company.
Setup and Training Costs: Ideally your SaaS product is easy to “discover, try, buy” with a quick time to value with minimal setup that can be performed by the customer. Sometimes either the complexity of the software or the topic prohibits this so that there needs to be implementation (and possibly data migration) and/or training provided either by the SaaS company or a third party. Sometimes this is baked into the on-going fee, sometimes it is a distinct up front costs.
Sources: Information for this article came from sources including: