Is Your SLA This Strong?

When your organization invests in new software, it pays to understand the provider’s service level agreement, or SLA.

An SLA guarantees a certain level of service and specifies what happens any time the provider fails to honor that guarantee. It’s kind of like when you buy a new kitchen gadget that’s under warranty – a blender, say. Per the warranty, the manufacturer specifies what they’ll do if your blender breaks. An SLA is like that, but for software.

Oh, and it doesn’t expire. Ever. Here’s how Wired explains SLAs:

Most people require a blueprint for architects and contractors to start building a new home and similarly would expect a new car to come with a warranty. An SLA serves as both the blueprint and warranty for cloud computing.

Defining, setting, and codifying expectations for every users’ software experience – that’s what a good SLA does.

At Rievent, we’re big believers in having a strong SLA.

Here’s how we see it: When your organization enters into an agreement with a software provider, you’re expecting a certain level of service – typically a very high level.

For our continuing education (CE) clients, a high level of service means that staff and learners can reliably use our software at any time. The SLA ensures ongoing reliability and gives those clients confidence in our product.

Ultimately, our platform is critical to their business operations. Having a robust SLA isn’t optional. It’s a must.

So, what should you expect from a “robust” SLA?

Two things: availability and redress.

An SLA should guarantee a certain level of service/software availability. This is usually expressed as a percentage of time that the service/software will be available. For business software in the cloud, anything less than 99.9% is sub-standard.

As for redress, an SLA needs to specify what happens when service/software availability doesn’t live up to the guarantee. Redress typically takes the form of compensation. A provider will issue a credit in a certain amount for any failure to comply with the SLA.

Here’s a good rule of thumb: Make sure the SLA specifies at least 99.9% uptime and, in the event of noncompliance, offers a credit that is equivalent to the prorated time the service would have otherwise been available.

That’s not all, though. There’s more to an SLA than uptime guarantees.

It also needs to specify specific activities that could be affected by non-availability. Aside from uptime, which all SLAs will cover, these “specific activities” will be different for all types of software.

For the Rievent Platform, our SLA speaks to all of the following issues that are relevant to our clients:

• Uptime: Specifically, we agree to deliver 99.9% uptime per calendar month.

• Activity access: For our CE clients, activities are the center of operations. No activity access means learners can’t access content, take tests, or receive credits. Our SLA specifies 99.9% availability of activities.

• Administrative portal access: Without access to our administrator tools, CE providers can’t add new activities, access data, or schedule new events. Compliance specifies 99.9% administrative portal access.

So, what do we offer any time we’re not compliant with our SLA? For uptime and access to activities or the administrator dashboard, we provide hourly credit entitlements for as long as the failure continues. For other issues – things like network/platform, host/security, physical security, and other emergencies – we provide daily credit entitlements for each day the problem persists.

Depending on software-specific issues you face, your SLA might include different language. Just be sure it accounts for potential service interruptions specific to the type of software you’re using.

Another consideration for your SLA: data access and ownership

Whether it’s specified in your SLA or elsewhere in your agreement with a provider, be sure you’re investing in a product with some solid guarantees about data. In particular, pay attention to data access and ownership.

Only you should own your data. Just because you’re using a software provider’s servers (or the servers of their preferred cloud vendor) doesn’t mean they can own, control, modify, or exploit the data that’s stored on those servers. Your data is your intellectual property – not the software provider’s.

A provider’s use of your data should be limited to activities such as:

• Improving their service
• Research, analysis, and effectiveness of their service
• Other actions that serve no purpose other than enhancing the service they already provide or serving as a basis for future service offerings

For example, it might be ok for a provider to consider the types of data you generate and use that information to develop helpful new platform features. On the other hand, it’s not ok for a provider to download your data without authorization and share it with others.

In short, an SLA – and your provider agreement in general – are tools for ensuring service reliability and the security of your intellectual property. The continued integrity of your data is part of the service being provided, and that needs to be codified into your agreement somehow.

A strong service agreement portends a strong working relationship.

That’s the bottom line, right? You wouldn’t buy a car without a warranty, hire a contractor who didn’t offer a labor guarantee, or open a bank account that wasn’t FDIC-insured. Those assurances speak to the type of experience you’re likely to have – that is, they speak to the service level.

Your organization should approach an SLA in much the same way. Insisting on a strong one isn’t just a good idea. It’s just good business.