The cloud business brings some very interesting and unique characteristics in the way customers and vendors are engaging: For the first time in computer history massive amounts of data are processed and stored outside the physical boundaries of the enterprise (its LAN or WAN). Also, vendor companies can reside thousand miles away from the customer premises and they are run by people that most probably the customer will never meet in person or maybe even talk on the phone.
These unique characteristics make the customer/vendor relationship very interesting and also somewhat difficult to describe. Such relations are typically governed by the Service Level Agreement (SLA) which the customer signs or in some cases just “accepts” with the click of a button on the web page of the cloud service they’re subscribing to.
Many times there is no option to “discuss” or “negotiate” such a document the way an “end-user license agreement” was negotiated in the past, when a piece of software was “sold”. Customer may or may not accept the terms (and move on to the next available choice). This very fact builds pressure on customers to accept a document that perhaps it does not find them exactly in accordance and also to vendors to come up with a collection of technical and legal terms that are “safe” for them but also not “intimidating” for the customers: something that can persuade customers to get on board the service instead of driving them away. These two “opposite forces” tend to reach some kind of equilibrium and this post investigates what this equilibrium point is.
One way to describe the customer/vendor relationship is to have a very detailed SLA, defining all possible outages or out-of-service conditions and that’s what many customers are looking for. But I would argue that the more detailed an SLA is, the more safe it may become for the vendor, leaving the customer uncovered (or, better, inadequately covered) in some cases. How can this be? Here is an example: The customer asks for specific provisions when there is data loss in the cloud service. This raises the question of what will the vendor’s obligation be for damage caused by such data loss? Obviously, it can’t be a number many times larger than the yearly fee that the vendor collects, otherwise the vendor has built a high-risk business, which makes no sense. And then, it can’t be a number too low, otherwise the customer doesn’t have adequate insurance for their data. In the hypothetical case where the SLA does not provide anything for this case, then the customer might ask for astronomical figures making the case that the data loss has seriously damaged its business. The vendor, on the other hand, could argue that they owe nothing to the customer, since the SLA did not include any specific clauses. A real mess in the customer/vendor relationship, I’m sure, and a real deal-breaker. But what is the mitigation for such risks? Perhaps a very detailed SLA that includes specific provisions for each distinct case? I wouldn’t agree that fast! You see, analyzing every little detail will work not only for the customer’s benefit but also for the vendor’s. The vendor might use these clauses to limit their risks to an absolute minimum. So, it is probable that in the above example of data loss, the vendor is obliged to offer some discount or re-imbursement on the next invoicing period and they are “off the hook”, that easy.
The point here is the following: A very detailed SLA covering all possible cases of risk, quantifying each and every small detail is not the “holy grail” of customer/vendor relationship that all customers should seek. Instead, customers should also look for other ways to make sure that their selection of vendor is correct, like investigating the “word of mouth”, asking for real-life references, and in general performing due diligence on the vendor selection process.
Popular posts from this blog
The relationships between customers and providers in the cloud business are generally governed by the Service Level Agreement or SLA. In a previous post I made the point that a really “tough” SLA is probably not the “holy grail” of the cloud business, which every customer should be looking for. In this post I will continue the same line of thought, focusing this time in the impact that a strict SLA has on the customer organization itself. For this purpose, I will use the term “Reverse SLA”.
In the organization’s journey from an on-premise Business Application setup to a Software as a Service one, one of the key factors of success is data migration. Of course, one starts with basic questions like “do I want or need to move to the cloud?”, “Which is the best SaaS solution for my case?”, “Does it address my special requirements?”, “am I content with the reporting/BI capabilities that it offers?” etc. But having answered all of the above, you should take into consideration the data migration issue. This post will point out some very significant issues around this subject, which you need to address and examine; probably in close co-operation with the SaaS vendor of your choice, before accepting their financial proposal and start the journey.
In an older post (http://goo.gl/jXGmOi) I discussed how web-based or cloud Financial ERP can help you unlock new possibilities for your Business Processes. The basic argument there was that an open system (like a cloud-based system is, by definition) could involve your customers in a specific business process (like sending a Sales Order, posting a comment that needs subsequent action from within your CRM etc.). The reaction I got from a number of readers was that new best practices could be devised and applied in a very important, so to speak, business process which is of everybody’s interest, big or small: that of invoicing the end-customer. We shouldn’t forget that many small and medium enterprises are focusing their I.T. operations on Accounts Receivable, inside which the invoicing cycle represents a significant part. Therefore, in this post I’d like to focus on this specific issue: how can your invoicing change when you’re using a web-based Financial ERP.