Share this content

Five things every client should insist upon in their cloud Service Level Agreements

2nd Dec 2015
Share this content

Service Level Agreements (SLAs)* are extremely important to managing modern business relationships.  But what makes an effective SLA?  Often, the devil is in the detail.

When creating SLAs for cloud communication services, for example, it’s crucial to understand that the service is about more than just the technology platform.  It’s also about:

  • How the client connects to that platform (i.e. managed network, internet, ISDN circuit etc.).
  • How the cloud platform integrates to front and back office systems/services
  • What 3rd party platforms are integral to the delivery of the overall service

Take the example of a call quality problem.  Is that the fault of the cloud platform provider?  Possibly, but it could equally be caused by an internet/MPLS connectivity issue, a carrier latency or congestion issue, or a LAN/WAN problem.

Which is why it’s unlikely that any supplier is going to guarantee call quality within an SLA unless it has end-to-end control of calls (i.e. from desktop to termination point).

By better understanding the end-to-end service delivery process, clear demarcation points can be set, giving the client clear guidance on who to contact in the event of a service issue or query.  And clearly, it’s in the client’s interest that not only involves as small a number of contact points as possible but also defines an escalation path if an issue can’t be resolved quickly or easily.

Five key things to look for in a modern SLA

To date, in the cloud contact centre space, SLAs have been relatively basic, focused on simple measures such as service and network ‘uptime’.  The latest industry SLAs, however, are more sophisticated, focusing more on the ‘overall service experience’.

Here are five key things to look out for:

1. Does the SLA adequately describe the responsibilities of both parties?

The Service Summary section of the SLA must state the name of the provider and the name of the client/customer.  It should also describe the obligations that both parties must make in order to satisfy the SLA, e.g.:

  • On the supplier side, a description of the services provided, details on how the service will be provided, what support level was purchased etc.
  • On the client side, a description of actions the company is required to take to enable the supplier to satisfy the SLA (such as providing up-to-datecontacts, network topologies and customer escalation paths).

Sounds like basic stuff but it’s absolutely essential.  The SLA defines the provider’s responsibilities and commitments and is the document that both parties will turn to first in the event of a dispute.  And in a legally-binding agreement there is no place for vagueness.

2. Network and service uptime promises

Again, a basic undertaking, but one that’s at the heart of all successful cloud relationships. When organisations hand over control of mission-critical applications such as customer service to third party organisations, they can’t be managed on the basis of ‘best endeavours’.

Network or service downtime invariably means no service, simple as that.  As well as creating angry customers, downtime can also have revenue implications for the client.

So what is an appropriate uptime SLA?  A few cloud solution providers now give 99.999 percent uptime promises, calculated on either a monthly or annual basis.  And clients have every right to insist that all downtime is included in this calculation, including time associated with system re-boots and software upgrades.

3. Can we measure and monitor performance?

Modern SLAs have evolved beyond basic uptime guarantees to focus on broader areas such as service quality, application performance, and business-specific objectives such as provisioning timeframes.  These aren’t, however, always easy to measure:

  • Provisioning times, for example, can be influenced by work handled by both parties – service provider and client – so it’s not always easy to apportion blame when critical dates are missed.
  • Accurately measuring service quality and application performance can also be tricky. For instance, are they most effectively measured by calculating loading speed, call clarity etc. at particular points in time, or by measuring quality over time to show a service is performing consistently well.

In summary, you can’t define success simply by asking the question ‘is the cloud service on or off?’  You need to look at a broader set of criteria that influences what service the customer ultimately receives.

4. Could we benefit from service request guarantees?

Service request guarantees can also be included in the SLA.  Dependent on the nature of the contract, these may cover:

  • How rapidly requests are handled (for different ‘categories’ of request and channels)
  • How long it takes to resolve problems (dependent on their severity and business impact where relevant)

and even customer satisfaction scores relating to those contacts.  Reiterating the point above, when organisations hand over control of mission-critical applications to third party organisations, technical support and help desk operations can’t be managed simply on the basis of ‘best endeavours’.

5. Are the monitoring and reporting tools provided adequate?

Moving from SLAs that just contain ‘uptime guarantees’ to ones that take into account broader definitions of success from the customer perspective is logical.  Today, cloud service providers are generally good at providing clients with basic network information (bandwidth utilisation, uptime etc.).  However, some are not so good at providing performance data.  Ascertain the extent of your cloud partner’s monitoring and reporting capabilities.  Can they provide daily, weekly or monthly reports?  Do they deliver real time contact handling stats?  Can they provide tailored reports showing individual and team performance analysed by user-defined parameters?  What other analytical tools can they provide to analyse queues and waiting times?”

Following these five pointers will not only help clarify the responsibilities of each party within the SLA but also help create SLAs that take performance as well as uptime into account.

Some cloud vendors will initially struggle to accept modern SLAs that take into account broader definitions of performance.  Others, however, will welcome it.

Indeed some vendors whose cloud platforms sit at the heart of carrier networks (like the storm® platform does with major Service Providers such as Vodafone and KPN), are already undertaking to manage end-to-end cloud contact centre services – from agent desktop to customer termination point on behalf of their clients.  Delivering not only a single service but a single SLA and a single point of contact.

* A Service Level Agreement (SLA) is a document that describes what a client will receive from a service provider and what the latter will do (or pay) if those terms aren’t met during the contract period.

Replies (0)

Please login or register to join the discussion.

There are currently no replies, be the first to post a reply.