Service Level Agreements: Protecting Your Client Work and Your Business’ Income
Picture the scene.
You’re in that golden period when you and your freshly-landed client are new best friends forever, and you simply can’t wait to start your journey together on that exciting brief. You’ve been chosen! You walk a little taller, you high-five strangers, and your brain is already starting to fire up.
Your client turns to you, looks longingly into your eyes, and asks what happens next. You gaze back into their eyes and utter the words they long to hear...
“Let’s sort the contract out.”
We’re in the digital business. It’s common for clients not to fully understand the processes and outputs of a digital project. And in fairness, who can blame them? We’ve got a language of our own. We “sprint,” celebrate being “agile,” and happily confirm that “the latest release has been committed to git.”
The honeymoon period, when the client awards us the job we’ve pitched for, is the time to ensure our client understands what it is they’ve bought, what the costs of those things are, and any terms and conditions associated with appointing us.
And we’re going to do it in plain English.
Get your free copy of Grow Vol. 3
From pricing projects to invoicing clients, this comprehensive guide will show you everything you need to know to drive sales, get paid, and ensure your finances are in order so your agency is as profitable as it can be.
Download today to access all 12 chapters and three bonus project management templates!
There’s a great chapter in the first volume of Grow detailing the basis of a good contract, written by Ryan Foster. There’s little mileage in repeating that chapter here. Go check it out; it’s got some handy links and useful resources.
I think the headlines are worth repeating though. Ryan notes that a good contract covers:
- Payment plan
Hard to disagree, right?
However, I want to focus on a scenario that I’ve seen variations on throughout my career. The project goes great; it launches; we get paid. Happy days! The contract remains a dust-covered document buried in a drawer somewhere, or as a PDF hidden in a folder in the cloud. We move on to the next project and the client goes back to focusing on their day job. Then their need for you suddenly spikes — a bug; an unforeseen thing; an extra feature that they need right now. How do we handle that? What’s their expectation?
One option is to use something called a service level agreement (SLA).
The service level agreement
An SLA is an agreement between you and your client (two parties) that defines how a service is to be provided. Around those definitions, quantitative measures must be in place to judge if the service is being provided successfully or not.
You’re probably holding an SLA yourself already as a client — a lot of hosting companies traditionally guarantee “99.9 per cent uptime.” Your smartphone contract, your electricity provider, your internet service provider — they’ll all have sections relating to the service being provided and the metrics on which they’ll be judged.
Wikipedia describes an SLA as “an official commitment that prevails between a service provider and the customer. Particular aspects of the service — quality, availability, responsibilities — are agreed between the service provider and the service user.”
A separate document from the contract? It can be. Part of the contract? It can be — some of the content fits nicely into the sections, as described by Ryan in above.
The topic of an SLA is a big one, but for now, let’s focus on the three key things outlined in that definition: responsibilities, availability, and quality.
1. Responsibilities and the nature of a hosted service
This may seem obvious in hindsight, but regardless of your team’s size, you’ll have a reliance on external services that are outside of your control and reach. That could be a hosting provider or it could be a hosted service, such as Shopify or Wordpress. In the event of a problem within those services (it happens to us all), does your client understand that the provision of that service is outside of your power?
In the event of a problem within those services, does your client understand that the provision of that service is outside of your power?
Regardless of it being a hosting provider or a SaaS hosted platform, the holder of the account will have contact details for support of that service. In some instances, that might be you, as you’ve agreed to manage the client's server network. In other instances, it might be that the client has the support details, as the account is held in their name (a SaaS hosted platform, for example). Either way, make sure that the support details are known and that it’s clear who would be responsible for making contact with the provider.
I’d suggest a list of suppliers that combine to make the final solution, what they do or provide to the solution, who would make contact in the event of an issue, and how to make that contact.
Discussing the issues surrounding your reach and responsibilities, and documenting them now, is far easier than trying to explain you can’t help a client who is in a state of distress during some downtime or other crisis in the future.
I like to think of this as rehearsing your fire drill — it’s always best to know where the bucket of water is kept before the fire starts!
2. Availability as a consultant
Regardless of whether you’re a multi-person agency or a freelancing team of one, this is important. Now is the time to ask the client if they want “out of office hours” support, and to define what those hours will be.
As digital folk, we’re easily found. Smartphone, email, Slack, project management tools, social channels, helpdesk software — the list is endless. During work hours and outside of them, what process would you like the client to follow? Will you charge for “out of office hours” contact? If so, how? Retained monthly? Per contact?
Keep it simple, keep it clear, and have the discussion with the client prior to moving on. Here’s an example of how you could specify this agreement in your SLA:
“For a support request, call [INSERT NUMBER], 9:00 A.M. to 5:00 P.M. Monday - Friday or via email [INSERT EMAIL]. We will respond to service-related incidents and/or requests within two hours during business hours. Calls and emails outside of this timeframe will be responded to the next available working day, and will be unmonitored until then.”
Don’t find yourself in the situation where a client is texting, calling, sending messages via Twitter, Facebook, and Instagram just to inform you that there is a typo!
3. Quality of the work completed
We’ve all been on the end of something not working as expected. Depending on the impact it’s having on us, and what we’re trying to achieve, it can range from mildly annoying all the way to us throwing a tantrum and promising never to buy anything from that company ever again. (That’s not just me, right?)
However, if it’s digital, things can go wrong. Big development teams with big budgets can still release software that has something not quite right. If they can, we can — and so can you.
How will you deal with it for the client, and more importantly, on what timescale?
I’m a big fan of the phrase “workaround and fix.” Let me explain.
A client calls with a problem — it might be impacting them or it might be impacting their customers. Within X hours of the issue being reported, we promise as a team to assess the details and establish if we’re the responsible party.
If we’re not the responsible party, we’ll suggest next steps. If we are, we’ll report on the length of time needed to provide the fix. If the initial assessment shows that it’s a small issue, we’ll fix it as part of that assessment. However, if the fix required is over X hours worth of work, we’ll provide a workaround until the fix can be properly scheduled, tested, and released.
What should X be? That depends on you and the client. If you’re a one-person team, it might need to be longer than that of a bigger team. If the client has expectations of it being shorter, then open a discussion. If they need something outside of your default, a retained support contract might be the answer.
Maybe the advice above means you want to look at your existing contract and terms. Perhaps this is all new, and you need to read Ryan’s chapter in Grow Volume 1 alongside this one.
Depending on where you are in the world, you may find online SLA templates helpful.
The template is provided as a starting point. Coupled with my suggestions and your circumstances, you may well be able to create your own. However, it’s always worth getting anything checked locally by a member of the legal industry. None of this chapter can be considered legal advice, just insights I’ve gained during two decades working in the digital industry.
One last tip: Reporting on your contracts and SLAs
Do you check in on your contracts and SLAs? If not, you should.
Consider the good times when nothing is going wrong — everything is working perfectly. Perhaps you don’t hear from the client in a month. Perhaps two. You should take the opportunity to tell them you’ve not heard from them.
At the end of every month, send them a report on the agreed key metrics. Include the number of support calls, categorize the support types, and perhaps even include the total since engagement. That response time specified in your SLA? Report on it. The agreement states two hours, yet as a team you respond within 15 minutes? Highlight it.
Consider using other services such as IFTTT, and pull some stats out of Google Analytics or other services used by the client too. Ask the client what’s important to them and what would help. It may even turn into an upsell.
A simple, automated report with your branding can really help keep the lines of communication open. Perhaps even think about using RSS to include some industry or niche news that they might have missed. Be creative, and try to avoid the scenario where you only ever talk to certain clients when things have gone wrong.
Be creative, and try to avoid the scenario where you only ever talk to certain clients when things have gone wrong.
Regular contact with clients can only ever be a good thing.
Nobody got into digital to do this stuff
...but it’ll bite you if you don’t.
Financial protection is not fun. It’s not sexy either, but you need to make sure you’re covered properly. Remember to get professional legal advice if you feel you need it.
It’s worth reminding ourselves why we have documents such as these — they aren’t there just to be read when things have gone wrong. They protect us from clients becoming a drain on billable time while driving up costs, and they set out exactly what that client is entitled to. While you may make a commercial decision to overservice on occasion, that can be a strategic decision rather than one made to continually dance for a client who makes constant demands of you.
Continued reporting on an SLA also helps keep the lines of communication open, and you never know what that can do — perhaps the client might engage you again on that new thing they’ve been meaning to talk to you about.
About the author
James Greenwood is old enough to have started in the digital industry in the previous century (but only just), and young enough that his age still starts with a 3 (but only just). He’s currently the Digital Director at UK-based agency Strawberry. He’s also slightly weirded out by writing about himself in the third person.