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

SDO and SaaS

I have always been impressed by the Service Data Objects specification and the utility value it has when generic services interact with each other. By the very fact that an object can be percieved as a self-describing message makes service orchestration/choregraphy much simpler. The specifications are implemented by ASF with Apache Tuscany(C++ and Java) as well as IBM/Eclipse(Java) - Implemented along with the Eclipse Modeling Framework. Assuming a scenario where application can send messages in any format they want but as SDO objects which self describe themselves, other applications can sucessfully retrieve and interpret the data in a highly decoupled manner. The specification enables interoperability between applications in terms of data models existing between them.

What would be more interesting is to see if any of the SaaS application platform providers actually use the SDO specification for both their integration requirements as well as Data Model Extensions. Amazingly SDO is the perfect candidate to provide extensions to data models since they are self describing and therefore metadata driven.

Technorati Tags     SDP,SaaS,SDO

User Authentication in SaaS applications

I have been working on a SaaS delivery enablement platform called Agora. I have had some insights after talking to multiple customers and most of them have always hinged on one crucial function, namely, User Authentication. It looks like this is a very common problem.

I believe Salesforce has a feature where in, the customer can implement a webservice interface given by salesforce, provide the details and Salesforce can then call the webservice for authentication. This was primarily done to abstract out the implementation/integration problems of multiple types of authentication.

The other option ofcourse is standards like OpenID. Allow users to have logins based on OpenID Providers and then use the same for the SaaS application too. But corporate customers would'nt want their user accounts to be personal email accounts. But this definitely is an option if the application is end consumer oriented.

I dont think that Federation as in replicating the user details or having a secure VPN between customer and SaaS App Provider is the right way to go, the former completely unnecessary and the later very costly.

I think the Salesforce approach does make sense. For e.g. a corporate customer can allow its users to login into the SaaS application using their corporate credentials for the first time. This action then creates a mapping between the SaaS application and the corporate user account. Subsequently any further requests for authentication can then be done seamlessly. The specifics of the implementation coule be anything ranging from SAML assertions to simple custom API's. The crucial question though is the communciation medium between the SaaS app provider and the corporate. I think either a standard auth gateway at the customer premise if already available or a standard webservice implementation like what Salesforce does.

Technorati Tags     SDP,Authentication,SaaS