There are several distinct pricing models for the on-going use of a Software-as-a-Service (SaaS) offering.
(Often there will be distinct tiers in these different models in which the cost increases as the capacity or capabilities of the offering increases. Also there are often 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 later 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 user licensing model which increases as the number of users and the capability increase (currently from $25/month to $300/month). https://www.salesforce.com/editions-pricing/sales-cloud/
This pricing model can sometimes vary across roles.
Per Transaction
Pros: Enables adoption from the occasional to the power user which helps make the offering ubiquitous across the client's organization significantly increasing its value and impact. (This is SAP Concur's pricing model and its adoption is often aided by it being the only way an employee can be reimbursed for their expenses. Opinions are my own, but I work for SAP 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 Zuroa's platform. https://www.quora.com/Does-anyone-know-the-cost-to-use-a-solution-like-Zuora
https://www.mckfastgrowthtech.com/time-rethink-per-user-pricing-enterprise-saas/
Per User or Per Transaction Freemium (free is often ad-supported)
Pros: Enables easy adoption
Cons: Must have compelling enough capabilities so that users will adopt the free version; but still significant enough differentiation that users will upgrade to the 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 Slack doesn't limit time, but it does limit storage (and other premium capabilities) in the free version.
Per Project
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 within the subscribing company and by other third parties (often subcontractors).
Cons: This all-or-nothing approach makes it unsuitable for use on a small portion of a given project; and makes it difficult for the gradual increased adoption across an entire project.
Examples: Some financial services SaaS products and some construction management products such as Aconex, a construction project management tool. Aconex drives 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).
https://project-management.com/aconex-software-review/
https://www.aconex.com/pricing
https://www.eurekareport.com.au/articles/138999/aconex-xero-construction-sector
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 this model aids adoption since the buyer only pays if they receive the guaranteed benefit.
Cons: Only certain offerings have specific well-defined financial benefits such as savings. Also 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)
Loss-Leader
Some offerings are either free or sold at a considerable discount as a loss leader for other products or services that are provided by the company (such as computer hardware).
Other Notes:
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 they should pay you to solve, trying to convince a customer to purchase your solution in a manner that doesn't align with their business and how they typically buy services is problematic. 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 framework 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 models 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 reduced 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, and 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. Often this is baked into the on-going fee, sometimes it is a distinct upfront cost.
Sources: Information for this article came from sources including:
https://www.inturact.com/blog/the-top-10-saas-pricing-strategies
https://www.cobloom.com/blog/saas-pricing-models
https://www.cloudesire.com/7-best-pricing-models-for-saas-businesses/
https://blog.kissmetrics.com/saasy-pricing-strategies/
RSS Feed