What is an SLA? How to Use Service-Level Agreements for Success

What is an SLA? How to Use Service-Level Agreements for Success process.st/sla-service-level-agreement November 8, 2019

Adam Henshall November 8, 2019

Services, services, services.

We seem to be in a world of managed services.

Everyone’s outsourcing nowadays. And when they’re not outsourcing, they’re insourcing in an outsourced way.

It’s all very confusing.

That’s why we’ve decided to break down the core document which tends to regulate and organize this kind of service provision: the humble service-level agreement (SLA).

Service-level agreements, amongst other things, bolster trust in and between organizations – making it clear what needs to be done, to what standard, and when.

Trust is a hugely important thing in business. Accenture’s Competitive Agility Index found:

following a drop in trust, a company’s index score drops 2 points on average, negatively impacting revenue growth by 6% and EBITDA by 10% on average.

One of the main ways to keep trust alive in your business is to know what is expected of people and to hold them to it. Enforce reliability.

SLAs are one mechanism to help you in that battle.

In this Process Street article we’ll answer the following questions:

1/9

What is a service-level agreement (SLA)?

An SLA, or service-level agreement, is a document created together by two or more parties to specify services that a provider will deliver to a customer.

It’s a specific kind of contract which determines the scope of work and aims to keep performance levels to an agreed standard.

Service-level agreements are broad-ranging and can apply to a range of different use cases. The idea of the customer and of the service provider are pretty fluid. This means that SLAs are often used as internal tools where one department acts as the customer and the other as the service provider.

SLAs can be pretty useful in both internal and external organization and goal setting, and are fairly standard practice for companies the world over.

However, not all SLAs are of equal value. A poorly determined SLA may prove useless in the duration of a client relationship.

An SLA which gets signed and shoved straight into a filing cabinet is unlikely to provide much positive impact on the service provision.

We don’t need to just know what an SLA is, we need to know how an SLA is best leveraged.

Why do you need a service-level agreement?

Source

Anyone who has provided services or paid for services probably already knows the high-level reason here.

In simple terms, milestones get missed, quality isn’t always at high standards, requirements get changed, etc etc.

One of these problems will appear in any project or service provision at some point in time. The purpose of a service-level agreement is to overcome these problems as best you can.

By defining the requirements, everyone knows what the scope of work is, it can’t be changed last minute, and the service provider can more easily meet the targets – targets are hard to meet if you don’t know what they are.

In a former life, I managed service provision for a small IT company. We did software builds, ongoing maintenance, and managed services. Some contracts would span all three, others only one.

2/9

As we were a small company, I pretty much ran operations. I ran the sales, support, and all other client-facing work.

I hated it.

I liked the company and my colleagues, but dealing with clients and things going wrong was hell. It wasn’t necessarily the clients’ fault, even if some were difficult. Looking back, it was kind of my fault.

You see, my processes weren’t strong enough. The agreements I drew up with clients were often too one-sided in the client’s favor, lacked sufficient clarity, and weren’t living documents.

Moreover, those documents didn’t really have much bearing on the actual work itself. The agreements weren’t built-in to our processes. They were adjacent – maybe.

And these same organizational issues were present across the company, unfortunately. It meant that clients were often left dissatisfied and contracts not renewed.

This is why things like service-level agreements aren’t just useful to have, but should be prominent and part of your operations in a meaningful way.

I can see why they’re useful for clients – but what about internal SLAs? Ron Carucci, in his article 4 Ways Lying Becomes the Norm at a Company for Harvard Business Review (2019), highlights how small day-to-day issues in a company’s organization can erode the trust which holds the whole thing together.

He identifies, in his words, 4 key areas which contribute to the erosion of trust: A lack of strategic clarity. When there isn’t consistency between an organization’s stated mission, objectives, and values, and the way it is actually experienced by employees and the marketplace, we found it is 2.83 times more likely to have people withhold or distort truthful information.

Unjust accountability systems. When an organization’s processes for measuring employee contributions is perceived as unfair or unjust, we found it is 3.77 times more likely to have people withhold or distort information.

Poor organizational governance. When there is no effective process to gather decision-makers into honest conversations about tough issues, truth is forced underground, leaving the organization to rely on rumors and gossip.

Weak cross-functional collaboration. Silos aren’t just annoying to work across; they’re an impediment to honesty.

When cross-functional rivalry or unhealthy conflict is left unaddressed, an organization is 5.82 times more likely to have people withhold or distort truthful information.

So how do we go about tackling these problems?

There are clearly a host of variables at play here and you can tackle each one of those problems as an independent issue. But if we take the last one – cross-functional collaboration – we find that Carucci has some specific recommendations:

A 25% improvement in cross-departmental collaboration, as evidenced by employees reporting that efforts were effectively coordinating efforts across organizational boundaries, led to a 17% improvement in truth telling behaviors. Establishing trust and fostering shared commitment to a broader mission is key to ensuring integrity. Cross-functional relationships must be focused on creating value for the organization, with service-level agreements that define what each function contributes. It’s also important that departments have cooperative, mutually beneficial relationships, and built-in processes that allow an exchange of honest feedback.

The emphasis above is mine, but it equally could have appeared in the original text. If you read that quote again you will see that the use of service-level agreements is the only solid material action item Carucci specifies.

Service-level agreements can’t solve everything on their own, but if done well they can contribute effectively to the smooth running of your business.

I think it’s important to pull out the next line:

It’s also important that departments have cooperative, mutually beneficial relationships, and built-in processes that allow an exchange of honest feedback.

3/9

… because I believe that line gives us useful guidance as to how our SLAs should operate. They should be cooperative and mutually beneficial if you’re going to get team buy-in from both sides. They should also be a truly built-in part of your process, not an after-thought.

What are the different types of SLA?

Source

We’ve already touched on the idea that there are multiple different types of SLAs which might be used.

Let’s have a quick look at the 3 main types.

Customer-based SLA Service-based SLA Multi-level SLAs These sound complex, and many explanations online only serve to make them sound more complex.

Take this explanation from Master of Project Academy:

A service-based SLA covers one service for all customers. Let’s consider that the IT service provider provides customer query service for many customers. In a service-based service level agreement, the service level of the customer query service will be the same for all customers that will be using this service.

We can make this simpler, I’m sure.

A customer-based SLA is a bit bespoke. This is about the service provider giving you a specific service.

A service-based SLA is more off-the-shelf. This is about you signing up for a specific service that the provider offers.

So the customer-based setup will have the one customer, where a service-based one might have many customers. The servicebased one is more like accepting the terms & conditions, whereas the customer-based one is more like a Sandwich Artist™️ asking you what you want on your footlong.

So what’s a multi-level SLA? A multi-level service-level agreement is an everything burger.

Imagine you’re a big company and you’re going to partner up with Process Street on an enterprise package.

4/9

Process Street is superpowered checklists that you can run all your company processes from. So you want to use Process Street in every department.

You’re going to have each department have access to all the cool features – conditional logic, role assignments, stop tasks, etc – but you also want one specific team to have a special degree of API access, so this team can do all the reporting for the whole company – to assess company performance.

There are three elements to this relationship: James in Customer Service needs to be able to use the service normally, like any other Process Street user.

Jane in the Continuous Improvement department needs special API access and all the assurances which go with that.

Sara who runs Operations needs to be able to review Process Street’s performance in the company and discuss that progress with Process Street.

Or, in SLA language: James needs a service-level SLA relationship Jane needs a customer-level SLA relationship Sara needs to be involved in SLM, service-level management, which we might call a corporate-level SLA relationship.

Those three forms of SLAs come together under the banner of a multi-level SLA. This allows you to have comprehensive SLA arrangements which serve the needs of the whole business.

What is in a service-level agreement?

The answer: exactly what you’d expect.

Sometimes you might see service-level agreements which are 100% legalese. In my humble opinion, these should be avoided – or, at the very least, two SLAs should be drawn up; one for the lawyers and one for the people who need to execute it.

It’s nice to have things clear and agreed upon in simple everyday English – or whatever language you do business in. Yo no puedo escribir sobre un acuerdo de nivel de servicio en español; esto es demasiado complicado. Lo siento.

The other advantage of writing things clearly is that it reduces the chance of any misunderstanding between provider and customer. Always go simple. No one needs to know how good your vocabulary is.

Source

Language and communication hurdles aside, the SLA needs to cover what services are being provided and to what specifications. Moreover, it needs to establish what the ongoing relationship between the provider and the customer is going to look like, how that’s going to function, and what would happen in the instance where the relationship came into difficulties or was unsuccessful.

In short…

The key components of a service-level agreement 5/9

The type of service The required performance level Monitoring and reporting Complaints processes Issue resolution process Repercussions for poor service

What kinds of companies use an SLA? The honest answer is that loads of companies use SLAs. Internally and externally.

Your mobile phone provider will presumably have an SLA going which you’re signed up to. Even if you don’t remember the signing.

Below, we’re going to look at a couple of different segments and how SLAs function in their business.

SLAs for Managed IT providers Lots of firms use managed IT services now. Given the rise of cloud computing, there’s less need to have a dedicated IT department in your firm with all of the necessary specialisms you might need.

Instead, many companies will have a generalist in-house and establish a relationship with a managed service provider which can provide specialists on demand. A much more efficient way to maintain those skills on staff.

This might be a company like Process Street customer TechMD, which creates the secure and scalable infrastructure a business needs to keep moving forward and then makes sure that infrastructure continues to purr.

SLAs for SaaS products SaaS is seemingly taking over the world, but we shouldn’t be surprised to see it in this list – Software as a Service is a service industry, after all.

Loads of software services you use are SaaS-based: Trello, Slack, Process Street, Salesforce, Quickbooks, HubSpot, and more. I assume you’ve used at least one of these tools.

When you sign up to one of the regular plans or products offered by these firms, you’ll likely be entered into a service-based SLA. This means the companies make some general commitments about the product or service they offer.

However, if you were to sign up for an enterprise plan, you’d get something a lot more custom. Instead of just getting Process Street’s superpowered checklists to manage all your recurring processes, you might also want API access, SAML-based Single Sign-On, full personalized onboarding and training, etc.

For that, you might sign an SLA which bears more resemblance to a customer-based SLA, as you’re getting bespoke services.

SLAs for Outsourcing firms With outsourcing companies, from large staffing companies to virtual assistants abroad, you’ll have an SLA based around slightly different metrics. Human labor is very different and more variable than software or hardware performance.

You can’t manage a bunch of workers based around their “uptime” – that’s just showing up to the office.

So in an industry like this, the SLA would be different. You’d have to specify certain details surrounding roles and responsibilities and determine appropriate metrics in a targetted manner.

What are some SLA examples or SLA templates?

We’ll make this quick because SLAs are often far too big to do a full walkthrough.

But it depends. All SLAs will look different because there’s no single standard for how they should appear. And… everyone’s offering different services. Of course they’re different!

6/9

What I’ll do is give you these 4 PDFs which you can review as examples (or templates, if you wish) for how your SLA could look:

What are the alternatives to SLAs?

Source

As Peter Bendor-Samuel lays out for CIO in the article Why service level agreements are dead, based on commentary from Nipa Chakravarti, service-level agreements are all they’re cracked up to be.

Nipa found that her company TransAlta was using managed IT services in a way which didn’t necessarily provide optimal business value.

The problems were that the service provider was incentivized to provide the minimum specifications for the service outlined in the SLA at the minimum cost. This meant the service would rarely go above and beyond in terms of delivery, and that the constraints of the SLA resulted in the service provider not being nimble enough or incentivized enough to react to rapidly changing business needs – the reality of modern business environments.

Nipa advocates more for improving SLAs to be more flexible than for scrapping them wholly, and for making sure the SLAs are fully tied in and in tune with the regular business processes.

Yet, this does make us ask what the alternatives are if SLAs are not performing to the standards required.

Operational level agreements One thing to consider could be an OLA – operational level agreement. This isn’t really separate from an SLA, more like a constituent part of an SLA. Nonetheless, you could structure your SLAs to be more focused on the OLA. These are more informal ways of establishing the relationships between different supporting partners or stakeholders involved in an SLA process.

This would be one way to try to sync up a service provider and a customer to allow for greater flexibility. Though, the results are likely not that different.

Performance standards When it comes to internal SLAs – department servicing another department – you could choose to do away with SLAs all together.

7/9

The way to do this would be to simply ensure you had sufficient performance standards in place across the organization, and particularly across the specific teams which serve as service providers within your company.

Establishing KPIs or OKRs which these teams are expected to hit could be a better way of focusing your efforts.

Internal guarantees One suggestion for internal SLAs would be to do away with the contractual nature of them and, instead, load the emphasis on the penalty side – the repercussions for needs not being met.

Christopher W. Hart, in his classic article The Power of Internal Guarantees for the Harvard Business Review way back in 1995, argues that more creative penalizing is the route to meeting business needs.

He proposes that when someone doesn’t do what they said they would do, they should have to pay compensation to the other employees whom it impacted.

For example, if a C-Level employee was late to a meeting, they would have to pay $100 to each person at the meeting who was waiting for them. If an hourly employee on the shop floor was late to a meeting, they’d have to buy each other team member who was waiting for them a soft drink. The crucial point here is that the fines are informal, personal, and relative to an employee’s earning potential.

So if department X fails to deliver a project on time for department Y, then the involved employees of department X might have to pay for the impacted employees of department Y to go out to dinner.

The emphasis is therefore not on the contractual nature of the SLA but on the incentive nature of personal responsibility.

There is the danger this could cause resentment in the company, but if done well it can also boost dialogue and reconciliation.

Like most things, it all depends on execution.

How you can use SLAs with Process Street Process Street is superpowered checklists and your central location to manage all your recurring processes.

As we’ve seen throughout this article, there are a couple of pain points which we need to resolve in order to make SLAs more successful: Flexibility of SLAs via regular review.

Communication of services rendered between provider and customer.

The need for SLAs to be built-in to a company’s normal business processes.

Service-level agreements need to be living documents.

This all comes down to: Following processes Actionable procedures Regular review processes SLAs on their own are useful but not that useful. They do not guarantee success nor do they work automatically.

They need to be employed within a functioning and successful process management environment.

And that’s what Process Street helps you do.

You can create process templates for all your recurring processes and run them as checklists each time the task is undertaken.

You can build in conditional logic, required fields, and rich work instructions using text and media files.

When you enter information into form fields, this gives you data you can pull out of the checklist. With Process Street‘s API, webhooks, or Zapier integration, you can make all of this data actionable.

Ultimately, if you’re not using a tool like Process Street for your service-level management, your SLAs will be so much less effective. Don’t miss out on great service provider and customer relations. Sign up to Process Street for free now.

8/9

9/9