Signing up and adopting a SaaS application

When we are talking about SaaS, we usually mean software applications, offered to the end user through internet and operated in a web browser. SaaS delivery model uses the “cloud space” in order to reach out to the end user. This means that when you sign up to such a service, you can’t really be sure where the actual server resides. It could be as far as the other side of the Atlantic Ocean, for all you know!

Therefore, in some cases, the traditional sales model of “salesperson demos to your premises and then fetches a signed contract to you” does not work. Local representation may not exist in your geographical area and the only way to sign up for these services is through the vendor’s web site: Typically, you will order the number of users that you wish, enter your company’s name and finally “check out” from the “e-shop” using your credit card or other payment service.

Sounds simple, as simple as buying a book from Amazon, but it isn’t! There are a number of issues that are raised; issues that simply do not exist in a typical e-shop transaction, when buying books or electronic appliances. Let’s go through of them, starting from the pre-sales stage and reaching the after-sales support process:

Sales process: When the SaaS vendor does not have local presence in your area, the only way to learn more about the product is word-of-mouth, internet research, video on YouTube or live web demos. All this is good enough, but there can’t be that face-to-face contact which always makes discussion easier and clears up issues faster and easier. Obviously, when you are buying a book from the internet, you have no need for such discussion and “eye contact” but when it comes to a long or medium term engagement, you probably need to be convinced. What the vendor can do to provide all the details on their web site and be able to answer more of your questions through email or telephone contact.

Service Level Agreement: In the traditional in-premise model, there usually is a signed contract between your company and the vendor. That contract tackles all technicalities of the cooperation between two companies. In the case of remote SaaS vendors, there is only a SLA, which is accessible through their web site and you either accept or reject. There is no room for negotiations, whatsoever. So, you have to ask yourself (and probably your attorney!) if that SLA is enough for you to base your business on.

Initial training: While system installation is not an issue in a SaaS product, training may be. In a typical in-premise proposal, there is always some reference to “training services” that your vendor offers to you, for the system start-up. In the cloud space there probably aren’t any trainers near you. Therefore, you have to do self-training or CBT or watch videos that your vendor is offering to you or simply “dive into the deep”, yourself (that last option is doable in some simple software, such as an appointment management system, light CRM etc. But what about a cloud-based ERP?)

Uploading of existing data: If you are migrating from an older system to a SaaS application, you will most probably have a wealth of data that you need transferred to the new system: customer records, accounting balances etc. You can be sure that your vendor has some uploading service facility in their software, but again you are on your own: you have to comply with given file layouts (there is probably zero maneuvering capacity from the vendor side; otherwise they would spend all of their time working on custom interfaces with their customers). You have to read and understand interface specifications and then produce the output files for these specifications. Erroneous files will simply be returned to you for amendments and re-transmission.

Fine tuning and parameterization: I’ve blogged before about how parametrical a SaaS application should be. Its mission is to cater for several and diverse business models and preferences. Therefore, I expect that any SaaS application needs a larger number of parameters to “describe” or “configure” each of the functions. This can be a real headache for the buyer, especially if they used to use a low-cost, in-premise, custom system. Again, there is the issue of how the vendor’s consultants “discover” these diversities and different requirements. From my experience, it takes exactly this: a “discovery document” that runs the business functions one by one and, while the buyer provides his business-flavored answers, the vendor’s consultant translates them into system parameters.

Customer support: It is very probable that your SaaS vendor resides in another country, speaking different languages and probably be on a different time zone. The obvious “hot-line telephone support” may not be present. You have to make sure that the vendor has in place a solid customer support web service (if not a 24h service telephone line). Especially the latter is a costly service the existence of which is not obvious. Or, you may have to pay extra fees to enjoy such a service.

The above make it obvious that in the SaaS delivery model, there is the question of local representation of the vendor. That is not to say that overseas vendors are to be rejected. You just need to research and decide what the extra effort will be for you to adopt the SaaS application and balance it with the unchallengeable pros of SaaS.