Delivering a SaaS Application - Part 2

In the last post I wrote that the entire business process changes for a company when it delivers Software as a Service. Lets continue on this and see what other things change.

Customer Support: Traditional software companies sell licenses and expect customer support to get a call only after some serious debugging themselves and of course there is always the blame on infrastructure, configuration etc that can be the causes for the problems. However in a SaaS based scenario, all users directly and immediately get in touch when they face problems. There is a need to enable users to get back to the provider as soon as they encounter a problem and then track the problem to closure. Not only does this mean lots of customer raised tickets but also the responsibility of availability as well as configuration now lies on the provider. Seamless and quick resolution of the problem is the only solution and traditional customer support process needs to be modified to achieve this. This is not the only change, every customer must be updated with any downtimes, any problems that is being addressed, anything that might affect the availability of the service. This is crucial to avoid customer frustration and ensure stickiness. Being transparent with the customer in explaining what exactly is happening and ensuring that information reaches pro-actively if there is a planned event or as soon as possible if there is an unplanned outage.

Managing Delinquency: Traditionally delinquency existing only in case of support and one can always stop support if customers do not pay. Whereas in the SaaS model delinquency is a major reason for revenue loss. Understanding how much a customer has to pay, how much has alrady been payed, how much can be discounted and whether to take a decision to stop the service (meaning you basically stop access to everything, the service and support) is very important. Once the decision is taken stopping access to the customer must not be a clumsy process but must be seamless.

Re-sellers: Now this is an area which is perenially mythically clouded. As far as I am concerned, partners are not only necessary but the essence of partnership radically changes when it comes to partnership on the cloud. It is always easy to re-brand and sell a CD and price it 10% higher than the original software provider.All the provider needs to do is acknowledge the partner in some manner and maintain a repository of partners. It is defintely not the case in the SaaS model. In most cases partners are the sales channels and they cannot sell as they do traditionally. what is rather required is the ability to enter into a contract with the partners, share the same infrastructure that is being used to deliver the service to the partner also and enable the partner to white-label or co-brand and then either sell pre-configured service plans or even let the partner configure their own plans! Now that is the ideal way of enabling resellers. What is interesting is the fact that a partner would be treated as a customer and billing for the partner(credit/debit) must happen automatically and without any manual intervention. In fact SAP Acknowledged that their sales of Business By Design was primarily enabled by partners who had the domain expertise to handle their customers. Though this might look like a highly-complex service scenario, this applies at all levels. Even normal services require partners to help reach out to customers and as a rule partners can do this more effectively than the provider.

Lets dicuss this further in the next post....

Technorati Tags     SDP,Business,Process,SaaS

Delivering a SaaS Application

Its interesting what it takes to deliver a SaaS application. Most people do not understand the depth of functionality that is required to deliver an application in the SaaS model. In fact most people think that an on premise can be delivered in the SaaS model as long as it is multi tenant and it can be delivered over the web. This is the first step to disaster!

If you typically look at what changes, the entire business process right from sales to payment changes drastically. In fact most traditional software companies are simply not ready enough to deliver something in the SaaS model. They usually find this out pretty late that their traditional model of leads, sales, payment, support, Operations and even their engineering process changes!

Lets take sales, the traditional model of sales people going to sell software simply does not scale for the SaaS model. What you would require is the ability for people to simply visit you website, gather as much information and probably click and subscribe to your service. You dont have big time gaps from contact to subscription. What probably would be required is the ability for your customers to try your software out. 

Subscription: Since the customer no longer requires hand holding for your product, the subscription process must be simple, self explanatory and probably would be driven through a wizard where customer requirements are gathered and the customer transparently knows how much needs to be payed and for how long.

Engineering: 9 months or 1 year releases no longer works. There needs to be continuous innovation on the product to make customers sticky. Customer feedback needs to be immediately fed back into the product. This is probably tough on the product since this requires the product to be able to support a lot of customization via configuration. Since customers are accessing the product in a single instance and the product needs to support individual customer needs, there needs to be a lot of thought on how to allow customers the flexibility of a customized process versus the trade off in having a standard product being shared by multiple customers. Continuous Innovation also brings in anoter complexity in terms of operation which I will discuss a little later.

Recurring Billing and Payment: Given the fact that there are companies like Zuora having dedicated billing and payment solutions for SaaS applications, I believe one immediately understands that this is something that is completely unique to SaaS. One needs extreme flexibility in terms of billing a service. A lot of parameters can be used to bill and simple our right fixed billing simply doesnt work in the SaaS model. You need to genuinely show your customers that you are billing them purely on their usage and they can have the flexibility in controlling the usage if they want to. This is a very powerful point in convincing customers to opt for SaaS solutions.

I will explain the othe differences in the next post...

Technorati Tags     business,process,SDP,SaaS