Reverse SLA

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”.

Although Reverse SLA is not a widely used term, I would define it like this: the mirror in which all vendor commitments are reflected and produce an image of the customer’s obligations in terms of response and organization, in order to smoothly receive any service that is provisioned by the SLA.

In this post I shall not analyze what the usual KPI’s are (lots of documentation for this on the net) but I intend to give some examples of some customer-side issues or challenges, which may prevent the smooth execution of an SLA. I will list the most frequent customer requirements and explain the implication that these requirements may have on that same customer’s organization. If you are thinking about using cloud services, when you are done reading this post you will hopefully have reached a good level of understanding about the impact that cloud adoption will have on your organization. You will also have understood that cloud services are not only about vendor meeting a series of obligations but also about your own part and role in the whole process.

A. Service availability and hours

The SLA includes the working hours that the service is available (typically, lots of “nines”) but also the time frame that the provider can/should serve customer requests. Focusing on the latter, this frame may vary depending on criticality (bugs, change requests, etc.). This issue sometimes becomes very important when the customer does not operate in usual office hours but spans beyond the normal hours of the vendor.

In that context, it is only about the vendor having the proper mechanism in place to process such requests but also about the customer having to be prepared to get feedback and finally assist the vendor in resolving the issue. Here are some examples that may prove problematic on the customer side:

·         In each case of issue or problem there has to be a departmental or overall representative (or manager) to be contacted by the vendor and in general be the communication hub between the two parties. If the service spans beyond normal hours then the customer has to nominate a person who will be available during all that time span.

·         Also, it must be clear that this designated person should be engaged in all circumstances and that it is not normal for end users to directly call the support center, trying to resolve the issue through non-authorized channels or procedures. In such cases, the vendor may refuse or declare inability to respond.

·         If the issue requires some user action, then a contact person must be included in the request. Otherwise, this may result to a resolved issue that the customer’s organization will not able to digest (e.g. test a new patch etc.)

·         Provide sufficient access to the vendor mechanics to look at the issue and go as far and as deep as they need to (without compromising in-house security, of course)

B. Service throughput

It is not only a matter of whether the vendor can deliver. It is also a matter of “how much” can they deliver in the unit of time. Some customers may have increased demand on this “service throughput”. But what is the customer doing to ensure that all this throughput is absorbed by its organization, as fast as it is delivered? For example:

·         There must be adequate resources on the customer side to perform User Acceptance Tests and the infrastructure to schedule, agree and monitor delivery schedules. This, among other cases in this post, is a good example of why the customer can’t do without a designated I.T. department or – at least – person in its organization.

·         In special cases where the throughput or availability needs to be higher than usual, the vendor must be informed beforehand in order to be given time to organize and be prepared for that special occasion. But the same applies to the customer’s internal organization.

C. Response times

The response times may vary depending on type of request. For example for bug-type of requests the response may be just a few hours and for Change Requests it could be days. Many times customers are pushing very hard to minimize all these times/metrics. But they must be able to respond to the issues as fast as they are asking the vendor to. There is no meaning in having the vendor respond “fast” when you don’t have the structure in place to receive the outcome of this task. Otherwise, you run the risk of:

·         Receiving extra charges for extra-hours service that you received without really needing it.

·         A problematic case that was resolved fast enough but you weren’t “there” to accept it.

·         A bug that was declared solved but you didn’t re-test and accept it in your Production Environment (with potentially disastrous effects)

D. Escalation procedures

It is probable that not all issues are resolved through the “service desk”. They may require escalation to higher authority, some management decision etc. Customers are right to ask from vendors to define such procedures. But they also need to have similar processes (and people) in place in their organization, too. Otherwise, the escalation process will not work and will most probably end up in a “vicious cycle” of “who’s to blame?”

E. Security guidelines

This is a very well-known issue that customers are pushing vendors to perform. And they are right! But what are they doing in order to meet the same standards that they are asking from the vendor and – if what they’re doing is not enough – then who’s to blame in case of problem? A few examples:

·         Are the customer’s Personal Computers equipped with up-to-date antivirus programs that ensure proper function? If not, then is the Service Desk responsible to remotely resolve a communication issue between the client and the server?

·         Is the operating system and patches installed according to the vendor initial or current requirements? Otherwise the vendor cannot be held responsible for the user’s PC not performing correctly.

·         Is the customer using the designated and tested/recommended web browsers that the vendor product supports?

I’m making the case that it is not just a matter of provider capability to “deliver” but also a matter of the customer meeting the requirements that automatically arise by the provider’s actions to “deliver” and its ability to digest the input that is created from the execution of the SLA. Also, it is now evident that abiding by the SLA requires that adequate staffing and expertise are in place, on behalf of the customer, otherwise the provider can’t be expected to “perform” above the level that the customer can “absorb”. In other words, it is probable that tough negotiation results in an SLA that can’t be monitored by the customer and, as such, has no real meaning or benefit for the customer.