Preamble
Before I get going, I need to explain that this article is written from a purchasing and sourcing perspective. My role is to always help clients manage costs, and you’ll soon read how challenging that mission is when dealing with SaaS products. The few SaaS industry experts I presented this article to before releasing it agreed with my points but felt I didn’t give enough credit to SaaS companies which, as I say in the article, are offering a better product than their predecessors. Let me give homage to the SaaS industry which, by and large, offers innovative and quality products. My beef is not with the product offering but rather almost exclusively with the difficulty of managing this cost. It is on this issue that I focus my attention.
Introduction
As a procurement and sourcing specialist, I’m not a fan of the software as a service (SaaS) model. SaaS once promised to be a simpler and lower-cost solution than the older software purchase model, but it hasn’t worked out that way. Instead, SaaS-based solutions have become arguably more expensive and stickier than their predecessor. Don’t bother wishing for the old days of software purchasing, which had plenty of issues of its own, because there’s no point in even discussing it. We’re stuck with this model because companies offering SaaS-structured products are pleased as punch about it; it’s way too profitable to consider anything else. Frankly, from a cost perspective, it’s only going to get worse for customers.
Background
It might be useful to briefly explain how we got into this mess. The older software purchase and ongoing maintenance model also wasn’t great for customers, so the traditional software companies got what was coming to them. Truth be told, I didn’t like them much either. The SaaS model was introduced as a way for new names in technology to break into industries dominated by established players. It was difficult for a new player to sell large and expensive unknown software applications. So instead, the SaaS model was born. In its infancy, SaaS was more of a subscription model than being fully hosted, as it often is now. The idea was to rent the licenses for an annual fee rather than come out of pocket for a big software purchase. It was meant to be a cheaper way to essentially rent instead of buy, and not feel married to any one technology.
SaaS model evolves
Those who developed the SaaS model turned out to be geniuses. I have to give them credit for offering a better product, or they wouldn’t have gotten any traction in the first place. However, the real genius was that the model did more than just succeed in getting companies to try their product; it turned out to be extremely profitable. Some of the early pioneers of the SaaS model have become corporate powerhouses. Conversely, those companies that clung to their traditional software sale and maintenance model lost ground and are now playing catchup.
SaaS products also turned out to be much stickier than envisioned. The original thought was that you were essentially renting an application and, because there was no invested customization, it would be easier to move off the application if you ever desired. Had it worked out that way, customers would have much stronger leverage, and I might now be writing about my love for the SaaS model. Instead, there turned out to be a lot of customizations required surrounding the application, even if the core SaaS product remained relatively standard. The variety of interfaces and support applications create an external independent ecosystem which needs care and attention, resulting in a higher transition and operating cost than anticipated. Furthermore, as the SaaS companies began to host their applications, it became difficult for customers to obtain their own data in desired formats to even transition to other applications. I suspect this circumstance is not an accident. SaaS companies have realized that they can hold customers hostage by making the hosted data only practically assessable in their applications.
Pricing power reality
The success of the model structure and surprising stickiness of the products gives pricing power to the SaaS companies, and they haven’t been afraid to use it. SaaS renewals are often a brutal experience for any sourcing and procurement team member tasked with trying to keep costs under control. SaaS customers can expect price increases that are multiples of annual inflation (CPI) growth, and there is little room for negotiation. The pitch is always that the product has “so many more features since our last renewal” and no regard to whether those features are actually used or need by their clients. In fact, those features that are beneficial are often rolled into another module and offered as an incremental purchase.
On renewals, SaaS companies seem to set an expectation for increased revenue down to the customer level. There is some flexibility as to how that increase is obtained. If you’re in a position to need more licenses or additional paid features, your price per license will not increase as dramatically. However, if you need the same number of licenses or, god forbid, you manage to decrease your requirements, you can expect a nasty price increase per license. One way or another, SaaS companies will get the total revenue increase they desire from each customer.
Strategies
Let’s break down the strategies to control SaaS-related costs into two categories: the initial purchase of a SaaS product, and the dreaded renewals.
In the SaaS model, the buyer only has power during the initial purchase process. SaaS companies aggressively seek to obtain new customers to strengthen their overall footprint. Since their products have proven to be sticky, gaining new customers is extremely valuable, and sales staff are paid accordingly. SaaS companies know they’ll eventually be able to get their desired product margins during renewals, and they’re willing to compromise on the initial sale price as necessary.
Initial purchases should follow the typical purchasing process with these points emphasized:
- A critical step early in the process is an internal analysis to determine requirements. That is true for almost any purchase but even more so when considering a SaaS product. Only through a proper assessment of requirements can it be determined whether a SaaS product offering is suitable. Ideally, the requirements should be prioritized and ranked. During the sale process, the buyer will be inundated by lists of functionalities, and it is important to be reminded about what was initially important to the buyer and not get distracted by the plentiful other bells and whistles.
- Focus on top providers of the SaaS service. It can be dangerous to go with a new or smaller player for a hosted SaaS application because if they don’t make it, your data can be difficult to obtain. Furthermore, a transition to a new solution is almost always costly and disruptive. Ideally, and in most cases, there will be a few quality providers of competing technology.
- When issuing an RFP, far more than the typical price, qualifications, and match against requirements should be covered. Hit all the standard key terms and conditions, but two aspects will require more attention than usual: renewal and exit. Sometimes, those elements are saved for contract negotiations when a vendor has already been selected, but for SaaS negotiations, that’s not recommended. It’s wise for an RFP to require detail on the renewal process, including timeline and price limits. Timeline is important since most SaaS companies will wait until a couple months before a renewal to provide pricing. At that point, options are limited to move off the product or adjust usage when shocked by the price increase. A limit on price increases at renewal should also be included, although I would set your expectations low here. It’s not unusual for there to be some limit, but don’t think you’ll get anything close to reasonable, which is a sign of the renewal pain to come. The RFP should further require a response to the possibility of early termination, but I would again set your expectations low. Regardless, getting information on how the SaaS company would support an exit off their product will provide insight on that level of difficulty. You can expect their obligation and support of such a transition to be close to nil. Finally, to make sure there are no last-minute surprises, I would recommend requesting and reading the standard licensing contract, which is often rather friendly toward the SaaS company.
- Ideally, a Total Cost of Ownership (TCO) analysis was done at a high level at the beginning of the process, but once you have solid product cost and functionality information, it deserves special scrutiny. Where most go wrong in a TCO analysis is underestimating what it will take to support the SaaS product, and overestimating the savings from moving off the old product (assuming there was one). When speaking with those charged with implementing and managing SaaS solutions, they’re quick to warn of unexpected transition costs. First and foremost, SaaS products can be installed quickly and cost effectively, if a company is able to adjust to the product’s standard configuration. However, it is often the case that this “plain vanilla” functionality doesn’t meet business expectations, which relates to the first point regarding establishing proper requirements upfront. The effort to go beyond the standard configuration can become a complex, time-consuming, and costly effort to marry emerging business requirements to the SaaS product’s capabilities. Another hidden TCO element is the efforts outside of the SaaS product to feed data in the exact form required. Since you can’t customize the actual SaaS product, an ecosystem is often required outside of it. Put another way, the need for customization doesn’t disappear as the SaaS model promises; in many ways it just moves outside of the application. There is also the difficultly of transitioning staff between old and new products. Even if your ongoing product support plans require a certain headcount, you can’t assume that your existing staff with an expertise in one product will make the transition to the new one. Even if you’re willing to trade headcount to obtain new staff with the proper skills, which also has an associated cost, finding employees with experience in a hot SaaS application can be difficult and expensive. In summation, it’s easy to miss on a TCO estimate because not all the risks and costs are understood. Just missing some of the elements discussed here can have a significant financial impact, sometimes even doubling or tripling the original estimated implementation and support costs.
Before moving on to renewals, a key point that can’t be overemphasized is that the buyer has negotiating power only once in this relationship, and it’s during the initial purchase. Do what you can to make the renewal or exit a little less painful.
For Renewals, consider the following:
Despite your best efforts during the initial purchase, I suspect you’re going to be disappointed when the renewal occurs. Your assigned salesperson or account rep has been given a revenue increase target for your account, and it’s going to be met. Under their renewal formula, the only way they can offer you something close to the existing price per license or module is if you purchase more of their product. That might be fine if you truly need the additional licenses or modules, but I never liked the idea of getting more attached to a SaaS vendor. The more you take from them, the more leverage they have on you later.
Renewal considerations need to start early, maybe even a year or more out if there’s a thought of exiting the product. Assuming you plan to keep using the SaaS product, the focus this far out should be license and application usage. There should be an attempt to assess whether the licenses or modules are being actively used and where the usage can be reduced. Some reduction efforts take time to implement. For example, one of my clients had developed a ticketing type process in Salesforce that had nothing to do with the sales process. That application was better suited for the cheaper licenses offered by ServiceNow, which was also used by the client. However, those transitions take time and must be completed before the renewal date. Once you scrub the current license and module usage, it’s time to project future needs based on anticipated changes in business operations. Once complete, you have a reasonable assessment of what you need from a renewal. Ideally, you should start the negotiation well in advance of the current contract expiring, but most SaaS companies won’t play ball unless your needs are increasing and you’re offering them more revenue. If you’re not, they will likely ask you to wait until a couple months before the renewal date to present the new pricing. It’s their way of limiting your options as the deadline for renewal looms over the discussion.
If your license or module needs are notably increasing, the renewal process might not seem as painful since the SaaS company can get its pound of flesh by selling you more product. However, any product needs that are flat or lower will result in a steep increase in price. This is where I wish I could provide some titillating and insightful advice, but I can’t. Make sure the SaaS company is abiding by any price increase limits you imposed in the original agreement. Beyond that, all I can advise is that you brace yourself for the beating. Pull out all the usual negotiating strategies, but understand that you have no real leverage and they know it. Your only remedy is to move off the product, but they know that scenario is unlikely because transitioning to a new solution would be daunting, disruptive, and costly. Besides, the SaaS company knows it got you there too, since you’ll still need the product during the transition. SaaS companies will renew for shorter timeframes, but the price increase is considerably higher than a multi-year commitment.
Even if as a result of this process you’re foot-stomping mad, I recommend locking in a price for as long as you can, usually a few years, because shorter periods will only make the renewal beating occur more frequently.
Concluding thoughts
From a cost standpoint, the SaaS model has proven to be even worse than the old software purchase model. The power shift at the point of renewal gives all the pricing power to the SaaS provider, unless some limits are negotiated during the initial contract. Even then, those limits are likely high and valid only for the first renewal. The only way to maintain some purchasing power is to have the ability to leave the SaaS application which, in most circumstances, is an unrealistic business scenario. It would involve a concerted effort to use the SaaS structure as originally designed: an application you rent rather than buy, thus allowing you to move away from it if ever desired. Essentially, try to adjust the business to the application rather than adjusting the application to the business. This is often not practical and would still not be a silver bullet, with SaaS companies increasingly hosting their own applications and controlling how customer data is accessed.
The best advice when considering a SaaS purchase is to understand upfront what you’re getting into: the adoption of a product that will be difficult to leave, a surprising amount of unforeseen implementation and support costs, and the potential for significant price increases at each renewal. An accurate long-term TCO analysis is difficult to do, yet critical to making an informed decision. As a final reminder, you’ll only have leverage during the initial purchase. Make best use of it to limit the sting of renewals.
Author information
Duane R. Deason is the President of The Efficacy Group, a company specializing in helping clients increase efficiency and improve profitability. Please feel free to reach Mr. Deason at ddeason@efficacygroup.com for a free consultation on managing SaaS or any other corporate cost.
