In many cases, different rules apply in product, software and service sales. Lately, I’ve noted that the true game changer is selling — and buying — Software as a Service. Simply said, Software as a Service (SaaS) means that you get access to a software application running somewhere in the cloud, instead of having it installed and managed by you at your own premises — an approach gaining popularity across industries and the way of the future.
While the SaaS solution brings several benefits compared to on-premises software, it also raises new types of questions both for the buyer and vendor. It’s essential for both the roles and responsibilities to be accurately defined in the contract; both parties also expect their risks to be covered in an appropriate manner.
SaaS is a common model for delivering the value of application to the user, so solutions are available for various needs from office tools to sales support and documentation management. Our Landis+Gyr team just recently bought a SaaS solution to streamline the documentation process. At the same time, we promote AMI Software as a Service for our utility customers. For me, it was a learning experience to buy a SaaS solution for our own use in the morning and to sell our SaaS in the afternoon. I would like to share some feelings and findings regarding SaaS contracts.
Buying SaaS: it’s all about trust
As a buyer of a SaaS solution, whether for business or private use, my first question is about security and trust. If I let someone move my valuable data — photos, documents, asset information — to a cloud somewhere, how can I be sure it’s safe and secure? Can I access the data when I need it, day or night? What happens if the vendor goes out of business? For now, I know the exact upcoming costs, but is there a risk that the vendor will start milking me after we’ve signed the deal? Who decides on the new features to be added and how they will be priced?
As a buyer, these were the obvious questions we discussed among our team prior to deciding on SaaS and the supplier. And no wonder, I face the same questions when selling a SaaS solution to a utility.
Selling SaaS: optimizing the offering
As a SaaS vendor, I also have some fundamental questions. What is the optimal offer for this customer case: SaaS solution, on-premises, or a combination of the two? Customers have different needs — how can I offer tailored features using a shared service platform? When offering SaaS, my customer buys scalability: how much capacity and processing power do I need to reserve now and in the near future? The list of considerations continues: as the access to a SaaS solution takes place via internet, the number of parties involved in the data connection is unknown: how do I guarantee performance in an environment where all the details are not 100% under my control? How to evaluate and include the risk of security issues or unexpected circumstances in the contract and keep the offering attractive?
Finding a balance
As I pointed out above, there are questions and concerns on both sides. So how to reach an agreement and realize the gains of a SaaS model?
In my experience, it is all about finding a balance: between the vendor and buyer, between potential risks and perceived benefits, between performance and price.
Security, availability and performance are fundamental components of any SaaS solution. They have to be on an appropriate level. Here, the key word is appropriate. What is appropriate varies depending on the application: how critical is the SaaS application for my business? Do I need 100% access 24/7? Can I accept temporary slowness in the operation? Real-time sounds good in the contract, but do I really need real-time, or would slightly less do?
As a buyer, it is easy to require continuous availability, high SLAs, real-time data etc. This is also what I put in my requirement specification when buying SaaS — and soon experienced the logical outcome: the stronger the requirements, the higher the costs. On second thought, I also realized that I might not need everything to be 100% available in real time, all the time.
So instead of listing hard numbers, a good approach for buying SaaS is to describe the challenges that need to be solved and to define the needs of the business. An experienced vendor can help by asking questions, and then propose a solution that defines both application functionality as well as initial SaaS-specific parameters. The beauty of the SaaS approach is that things can be flexibly changed over the time. For both vendor and buyer, it is better to just get started rather than stand there with a head full of worries.