Clear transparency in your pricing, and having a structured enterprise contract model can go a long way in customer retention
When it comes to SaaS products in the range of hundred’s of $/month, it’s universal practice for companies to display their pricing clearly on a /pricing.html page. But if you come across a product valued higher, you’ll inevitably find the /pricing.html page replaced by an intimidating “Schedule a Sales Call” tab.
In a web ecosystem of consumers products, which make signing up for a service as simple as a single click, this can, frankly, be very frustrating.
I don’t want to talk to anyone … I just want to know the damn price!
The reason premium SaaS companies don’t really publish structured pricing for their products is not that they want to milk as much money from you as possible.
The reason is that premium SaaS products are generally flexible, multi-pronged solutions to a variety of use cases. It’s very difficult to figure out what to offer in, say, an API package that makes business sense to all ranges of customers. Any discussion about pricing will almost always devolve into a higher level strategy problem:
Who are we targeting actually?
In the SaaS API industry, there are effectively two types of customers:
Small/medium businesses or start-ups
Each type of customer is remarkably different from the other.
Start-ups/small businesses are looking for out-of-the-box products that are affordable, with a set of pre-defined features.
Larger enterprises aren’t interested in products; they want solutions to their problems.
How you treat each customer changes your pricing (and strategy) significantly.
At Semantics3 we serve both clients. While we work with very large and established companies, one of our biggest revenue streams comes from start-ups and SMEs.
We’re pretty transparent about our pricing. It’s basically just 3 rules:
Rule 1: Any scalable product can be made affordable
We subscribe to the IKEA philosophy when it comes to start-ups and SMEs: We strive to make great products, but we get the customer to do a bit more legwork, and pass on the savings.
The API is designed with this in mind:
It has a predefined list of features, and set of limitations
It’s designed to be self-serve. You can access this API programmatically to fit it into any application you can think of.
It’s affordable, because we don’t assign an entire team of engineers to assist you with your project. The implicit assumption is that you are a programmer, or you have access to one who can successfully implement the API for your use.
The pricing is optimized for this set of features and limitations. We’ve arrived at the pricing based on what it takes to support customers at that level of access and still generate revenue growth.
The general rule of thumb is this: If you are okay with a predefined set of features and the level of access offered, and have your own team of developers to integrate the API, our standard SaaS packages work for you.
Rule 2: Customized solutions require customized pricing because our costs aren’t optimized anymore
Many large enterprises who aren’t interested in our standard offerings — instead they look for solutions.
There is an important distinction to make here. Crafting a solution for customers is about more than just making slight tweaks. It’s a long process of establishing trust in the relationship. The focus here is on building a mutually-beneficial business relationship, where we actually solve the customer’s needs, instead of selling stuff to them.
Solution sales usually involve this workflow, or a subset of it:
There’s a reason for this systematic approach to developing an Enterprise relationship:
Enterprise clients need a solution that meets their needs — often this requires additional technical investment and resources dedicated to their projects.
Enterprise clients need a solution that works and keeps working — this requires setting up Service Level Agreements that ensure that additional infrastructure and support are put in place to maintain uptime.
Both client and licensor need to be on the same page vis-a-vis what’s available, what’s possible, and what’s achievable within a set budget. This process is designed to make sure that both parties have full clarity.
Enterprise clients are often large (sometimes publicly listed) companies that require a separate legal contract that’s set apart from our standard terms and conditions.
Both sides need to scrutinize the terms and ensure that they can meet their fiduciary and legal duties
Thus, as you can see, pricing is often a complex process, and only takes place after a systematic evaluation and understanding of technical requirements has been performed. It often is not a case of “bargaining” or “haggling” — pricing is a very well thought out process that takes into account the cost overheads associated with adequately supporting the client, the expected duration of the contract, and an appropriate valuation of the data services rendered.
Rule 3: Providing services at scale or over longer time periods invokes economies of scale
It’s pretty simple — if the enterprise project allows us to provide services or data at large volumes, we can build in volume discounts into the pricing model. This is because economies of scale start coming into play at large volumes.
Additionally, paying upfront for a 12-month or longer contract nets you discounts as well — by paying upfront, you allow us to provision additional cloud services well in advance of when we need it, (meaning we get a discount), and we can pass on those savings onto you.
In sum, pricing and packaging your products well, and transparently where possible, is key in ensuring that you deliver optimal value to all of your customers, both small and large.
It should always be backed by logic and never be about merely
“plucking a number from thin air”