I suppose it makes sense that much of the discussion you read in blogs, datasheets, websites, and even from the analyst community about SaaS almost exclusively talks about it as a technology, and gives little air time to the other "S" in the SaaS acronym - the service - and what it means to sell a service as well as the use of an application.
When we talk to ISVs about taking advantage of the growth opportunities related to SaaS, what often gets lost is what it takes to be service oriented - as a company. Most get it that the service needs to be available in order to generate revenue, but often times that's where it ends. In truth, that's where it starts.
• The service becomes the product. Treat service problems with the same energy and priority as bugs in the source code. Many successful service companies that I've been fortunate enough to be part of in my past run daily service quality meetings, and not only review the up/down status of the equipment, but also review call volume, call severity, the nature of the call (technical vs. non-technical), billing issues, etc. While service issues can be categorized and prioritized for resolution, speed of resolution and how you handle a customer is even more important. Make sure you can talk to a human within a reasonable period time, and not put them into an endless support queue. I personally don't believe you can get away with different levels of support based on what the customer pays. Sure, it's possible to guide users to help themselves through online help, but don't make that the only option. It's also important to remember that the user is often a buyer or influencer into the decision making process, so be aware. I would bet that for most product companies, the one who made the purchase decision almost never calls the help desk, putting the support team on stage at all times.
• Accountability. Executives should establish service quality goals and tie compensation to those goals. Nothing motivates like cash, and if a company is truly serious about delivering a quality service, establish clear goals regarding service quality, communicate them throughout the organization, measure regularly, and reward for achieving and penalize when goals are not met.
• Transparency. I've seen some great examples of companies with SaaS offerings who give you a pretty unique view of how they're performing. Salesforce.com for example publishes their availability status on their customer portal, as well as historic availability metrics so you can judge for yourself whether their performance will meet your needs. Also think about the value you want your customers to place on your service, if you want to be the mission-critical guy to them, then you need to give them what they need to feel comfortable at a moments' notice. Yes, sometimes it hurts when things aren't going well, but it's healthier in the long run for your customer and for you.
• Communication. I touched on it before, but communication within the organization is critical, not just for SaaS companies, but when trying to put the square peg of a service business into the round hole of a product company. Transforming the identity of a company is hard work, and communicating effectively from the beginning is critical.
• Simplicity. Making it easy to do business with you is always a good start. For many ISVs, ordering services, ordering additional services, canceling services, reviewing and understanding the bill, speaking to a human when you have questions, etc., are all so often overlooked as part of the customer experience. But with a services model, thoughtful consideration should be given to the various touch points the customer may use to experience your company – outside of the application itself – and take advantage of those opportunities to provide easy and excellent levels of service. I sometimes equate this to a new restaurant, the kinks haven't been worked out yet, but as long as the food is good and the place is clean, you'll likely be given a second chance.
• Performance counts. Gone are the days that you can wash your hands of network latency problems, slow page load times, etc. Business buyers are consumers too, and their biases towards crappy and excellent service come to work with them. Think about how the service will look from their perspective.
• Capacity Planning and Scalability. Without taking a completely purist view of SaaS, most ISVs with SaaS offerings provide the service delivery infrastructure as part of the overall value proposition. Remember, though, by taking on that responsibility, you're now responsible for knowing your customer well enough to have enough capacity – of everything you offer – on hand to meet their needs, and for you to generate revenue.
• Relationships. Whether you price based on the number of users, volume of data or transactions, or some other metric, the relationship you have with your customer has to be managed. This is not to say you have to dedicate a resource on a 1:1 basis, but thinking less in terms of a one-time sale and more in terms of a long-term, growth-oriented relationship is a higher level of service most product oriented companies don't practice today, and which requires commitment to get right.
• Service Level Agreements. I bet that in the past the closest most ISVs came to offering a service level guarantee was their warranty, which we all know isn't worth that much. But with a service, the trend is heading in the direction of having to put some real guarantees behind the quality of the service you provide, guarantees that are backed up by cash payments or credits if you fail to meet the quality metrics you agree to.
• Stuff that probably shouldn't be your problem, now it is. I spent quite a few years with companies that offered managed services, and in my case they were hosting, security, and networking – all pretty important in a SaaS based business – and I always found myself in the middle of what we thought was the customers problem. Blocked email servers, inefficient LAN routing, application configuration problems. Playing the role of a service provider, especially one that takes a turnkey approach to delivering an application service, be prepared to address a wide range of topics considered to be part of the application delivery chain, regardless of whether or not you had or have anything to do with it.
• Account Management versus Sales or Business Development. Instilling a commitment to building a healthy, ongoing service relationship, with financial incentives from continued growth, is another important transition to a services mentality for the company. For the ISV, much of the financial growth in the account comes from increased usage of the service, which means that you have to pay closer attention to the customer throughout their lifecycle as a customer, and not just until the application has been handed over.
• Change things up. While there are a lot things to consider as you adopt a more services mentality within the company, one positive aspect is that you are constantly getting feedback from your customers, and have the ability to tinker with the service to make it better. The closer relationship you've built will therefore help you be more responsive to your customers needs versus using a patch or bug fix release every month to six months to fix issues.
What do you think? How have you made a transition to a services model from a product model? Any interesting experiences?
