Automation of sales process in SaaS (part 2)
Automation of the on-boarding of new users on a SaaS platform is quite important and new. This is the kind of problem that does not exist in the traditional on-premise delivery model. So, it drives the SaaS vendor to “think differently” – and accumulate some costs in the process (!).
It’s not just about “on-boarding”. If we discussed this issue more widely, we would talk about automation of the entire sales process. And while we are at it, we could also expand the discussion on the automation of the after-sales process, too (customer support, in this case).
Let’s see some more challenges:
Since there is no license sold but there is obviously a SLA, how can this be documented? In the traditional on-premise, license-based model, the buyer signs a contract that they have actually purchased and own this or that piece of software. In the world of SaaS, the buyer does not own anything… Well, that’s not true! They own, at least, their data, which are inputted on the remote, hosted SaaS application. Anyway, how do you automate the “purchasing of SaaS services” with the absence of a written contract? A SLA? Something! Do you activate a simple “pay with your credit card and enter the site” process? And what are lawyers saying about this? I will not go into legal details, as I am not the right person to do so. Anyway, it seems that not even lawyers can agree amongst themselves. The message being here: Should/Can the SaaS vendor create a mechanism where potential users pay through their credits cards and just “enter the site”?
Now, let’s assume that you, the customer, have overcome the previous problem. You somehow paid for the service and now you have a user name and a password. What do you do with this? (!) If you bought the service on-line, you are obviously not getting any training from a trainer. This is another problem that the SaaS vendor has to solve: training of the remote, anonymous users. There is a number of ways to do this: provide extensive user manuals (and not just a typical “quick-reference guide”) or e-Learning modules (CBT’s, we used to call them!) or extensive on-line help inside the application itself. Everybody can understand that all of the above will incur more costs and increase time-to-market for a new SaaS venture. On that, you have to add the – logical – assumption that, exactly because of its SaaS nature, the application needs to be very parametrical with a lot of configuration options; stuff that a simple stand-alone application may not have included in the first place.
One of my favorite examples is this: A credit note of a sales invoice should debit the sales account or credit it with a negative sign? Do not try to answer this question! Accountants are divided to 50%-50% on that matter. No technical guy can ever solve this problem… unless you gave them a system parameter/option that controls this behavior. That way, everybody will be happy! Do you see where I’m getting at?
Let’s see now the issue of customer support: After you have concluded the sale and the users are trained (or self-trained), problems/issues arise. They require some customer support. How does the SaaS vendor organize their customer support function? First of all, let’s try to remember that this, being a SaaS application, will be spread to users, all over the globe (if you are lucky enough!). Therefore, your Customer Support team must work on 24h shifts. This will drive costs sky-high and that’s why you need another (additional or primary – you choose) mechanism for customer support: Some kind of web system where users will post their comments/issues/problems and they will be handled in a proper manner (whatever you decide “proper” is). Therefore, the challenges here are to actually have and maintain a “customer support” web system, different from the actual SaaS platform and of course providing instant access to newcomers on your cloud.
In the SaaS world there are new issues emerging, from the side of the vendor, too. It’s not just about building an application and getting it to work… Nobody said it’s going to be easy; but it’s going to be a lot of fun!
It’s not just about “on-boarding”. If we discussed this issue more widely, we would talk about automation of the entire sales process. And while we are at it, we could also expand the discussion on the automation of the after-sales process, too (customer support, in this case).
Let’s see some more challenges:
Since there is no license sold but there is obviously a SLA, how can this be documented? In the traditional on-premise, license-based model, the buyer signs a contract that they have actually purchased and own this or that piece of software. In the world of SaaS, the buyer does not own anything… Well, that’s not true! They own, at least, their data, which are inputted on the remote, hosted SaaS application. Anyway, how do you automate the “purchasing of SaaS services” with the absence of a written contract? A SLA? Something! Do you activate a simple “pay with your credit card and enter the site” process? And what are lawyers saying about this? I will not go into legal details, as I am not the right person to do so. Anyway, it seems that not even lawyers can agree amongst themselves. The message being here: Should/Can the SaaS vendor create a mechanism where potential users pay through their credits cards and just “enter the site”?
Now, let’s assume that you, the customer, have overcome the previous problem. You somehow paid for the service and now you have a user name and a password. What do you do with this? (!) If you bought the service on-line, you are obviously not getting any training from a trainer. This is another problem that the SaaS vendor has to solve: training of the remote, anonymous users. There is a number of ways to do this: provide extensive user manuals (and not just a typical “quick-reference guide”) or e-Learning modules (CBT’s, we used to call them!) or extensive on-line help inside the application itself. Everybody can understand that all of the above will incur more costs and increase time-to-market for a new SaaS venture. On that, you have to add the – logical – assumption that, exactly because of its SaaS nature, the application needs to be very parametrical with a lot of configuration options; stuff that a simple stand-alone application may not have included in the first place.
One of my favorite examples is this: A credit note of a sales invoice should debit the sales account or credit it with a negative sign? Do not try to answer this question! Accountants are divided to 50%-50% on that matter. No technical guy can ever solve this problem… unless you gave them a system parameter/option that controls this behavior. That way, everybody will be happy! Do you see where I’m getting at?
Let’s see now the issue of customer support: After you have concluded the sale and the users are trained (or self-trained), problems/issues arise. They require some customer support. How does the SaaS vendor organize their customer support function? First of all, let’s try to remember that this, being a SaaS application, will be spread to users, all over the globe (if you are lucky enough!). Therefore, your Customer Support team must work on 24h shifts. This will drive costs sky-high and that’s why you need another (additional or primary – you choose) mechanism for customer support: Some kind of web system where users will post their comments/issues/problems and they will be handled in a proper manner (whatever you decide “proper” is). Therefore, the challenges here are to actually have and maintain a “customer support” web system, different from the actual SaaS platform and of course providing instant access to newcomers on your cloud.
In the SaaS world there are new issues emerging, from the side of the vendor, too. It’s not just about building an application and getting it to work… Nobody said it’s going to be easy; but it’s going to be a lot of fun!
THANK YOU FOR THE INFORMATION
ReplyDeletePLEASE VISIT US
erp management system