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