Automation of sales process in SaaS (part 1)

Can the process of boarding new users in a SaaS application be automated? When deploying a big on-premise ERP or a customized CRM etc. one can surely expect that the system installation, parameterization and deployment will not be a matter of minutes! It will take consulting and the provision of other services before you can say that you have a truly operational system.

In my opinion, SaaS is (should be) trying to tackle this issue, too. It’s not just about a different delivery and charging method. It is also about the ease of use and the streamlined way of “doing things”. And part of “doing things” is the way the environment is boarding new users and giving them the initial working environment.

So, what are the challenges for a SaaS vendor who is trying to move towards an automated activation process? And is this “automation” a panacea that every vendor should pursue? (Don’t be hasty and answer “yes”, because there is a catch to that…!). Let’s have a look at those challenges:

First of all it’s the sales process itself. In the traditional model, sales are accomplished by marketing actions, mailing lists, telephone contacts etc. When the application has a relatively wide scope, then sales calls, meetings and live demos are essential for the closing of the deal (Do you know anyone who has bought SAP or JD Edwards, just by browsing through their web site?) SaaS will challenge that! It is now possible to buy your SaaS subscription through a credit card, after having seen a live demo, a youtube video or in some cases after having a free trial period yourselves. That’s great, but how were these vendors able to provide you with a working environment, just seconds after your credit card or PayPal payment? Answer: They have invested in mechanisms that allow the environment to be “auto-generated” and populated with the very first and basic parameters that it needs to work. And these mechanisms simply do not exist in the traditional on-premise delivery model.

Then, it’s the start-up services and fees. After signing up and having a working environment, the customer may require some customization, some help with the parameterization, an expert opinion in some operational matters etc. The challenge for the vendor, here, is that the more expandable their application is, the more parametrical (and “plastic”) it is, the more options it gives to the end-user, the more complicated it is to setup. And this stands in direct opposition with the previous target of automated boarding of new users. It is a fine line between creating a wide-scope application and trying to keep it simple at the same time. Here is a good example: I had a look at a very well-known and successful SaaS Accounting product. I saw their customer file and found everything that you would expect from a typical customer record. So, as soon as you pay with your credit card, you are “ready to launch”. But what if that customer file needed to be expanded with new fields, additional validations and some design changes? Can this product do it? And if so, at what cost? And how fast? And will it require the provision of some “professional services”?

Another pain point in any migration (SaaS or no-SaaS) is the old data migration. Even if the product has been designed for immediate “embarkation”, you would probably be able to only do just a few things, if you didn’t have your old data, on-line. Imagine boarding a new sales system and not having your existing customer file; or an accounting system without your chart of accounts. The challenge here is that the SaaS environment should provide you with the tools for uploading critical data, by yourself. It must give you file layouts, examples and probably sample files to guide you through the process; ideally, without having to talk to any technical personnel of the vendor. Why is that a challenge? Because, typically, this process was usually undertaken by the vendor’s consultants or business analysts and in most cases they also performed a preliminary check of the files and they gave feedback on problems, as they came up. Now, the whole process must be executed by non-expert staff (that is you, the buyer) and all possible problems need to be reported before feeding false data inside the database. And I can tell you from experience that this can a pain in the… stomach!

There are more challenges on the endeavor of automating a SaaS environment and actually achieving “zero-effort” on boarding new users, which I shall comment on in my next post. Until then, all you SaaS architects need to remember that the application design and functionality is NOT the only wager!