What the SLA?

You may or may not have heard the term SLA before in your work. This may be because you’re working more on the arts side of things, for festivals, or short-run installations and events. On the long-term and permanent installation side of things, SLA’s are a key contract in the pipeline that you’ll need to define. An SLA stands for Service-level agreement. You can do a web search to read more about it or read the Wikipedia page for general overview of it. It’s the contract that dictates how work (mostly service, maintenance, and bug fixes) is dealt with after the project is delivered and finished. This time frame is the main difference between the normal contracts/SoW’s you’ll sign when starting/working on a project, and the SLA that you prepare and sign as you approach the end of the installation. So if you’ve never signed or made an SLA, let’s bang through a bunch of things you need to know when digging into an SLA.

Key things to know

I’m going to go through a bunch of notes that are most pertinent to SLA’s and how they apply to our industry of immersive installations and interactive technology like TouchDesigner. SLA’s in general can become quite technical and full of jargon, but when it comes to our industry, it can be a little simpler and more focused.

Define everything

I can’t really say anything more important about any contract, as you should try to make contracts as detailed as possible whenever possible. You should define four key things:

• What is included in the service vs what will incur additional costs
• How much the SLA costs to keep active (usually you’ll sign an SLA with a term and then you have to renew it. Yearly is pretty common)
• The time frames/availability for your service and response times
• Protocol for requesting service

The first point define what is included in your SLA and what isn’t. Depending on the size of the project, where it is, and how much you’re charging for the SLA, what may or may not be included will change. For example, it’s very common to include email support, phone support, remote access support, 90-days bug-free warranty (if the bug is because of your work, not because of user error or etc), and more. Some things that may or may not be included are things such as on-site assistance (which if not included means you’ll do it but you’ll charge for it), hardware replacements because of wear and tear, etc.

The second element to define is the cost of an SLA. I’ll talk about under the next heading!

The third element to define is the time frame/availability for service and response. As I mentioned, things like email support, phone support, remote access, and bug fixes are commonly included in the SLA, but you need to define how fast your response time is and when you’re available. For example, if phone support is included, during what hours are you generally available and taking calls? Are you in the same time zone as the installation? How quickly will you respond to a missed call? These are the types of things you need to define when it comes to time frames and availability. You’ll want to do the same for email support, such as next-business day response time on emails (maybe including weekends or not, up to you), and remote access login times (can you login after hours when no-one is around or can you only login during business hours?).

The final element you’ll want to outline is protocol for requesting service. This might sound dumb, but there’s nothing worse than someone emailing you saying “there’s a bug, it’s not working” and nothing more. No details, no time of issues, no pictures, no videos, just a blank email or voice mail that doesn’t actually help anyone. So it’s useful to write some dead-simple instructions on how clients should request support. Usually including things like:

• take note of the time the issue happens
• take a picture or video if possible
• explain what the installation was doing before the issue happened
• if they’ve noticed any other weird behaviour

Even these few notes will get the client thinking on the right track when they reach out for support.

Figure out your pricing

SLA’s are a bit weird when compared to our normal work, because you may or may not even need to actually work on the installation again. If it runs smoothly and there’s no issues or maintenance required, it might feel weird to charge money for that. Depending on your clout, you can approach pricing an SLA in a few different ways. As mentioned above, SLA’s usually have a term and when that term is up, you’ll need to renew the SLA with the client to ensure that you’re available and can support any maintenance quickly and efficiently. There are generally two ways you can price the SLA:

1. Pre-allocate a certain amount of development time that sits idly around for the SLA term, and you just deduct against that for any work you do. The client would usually “pre-buy” these development days and pay for them up front, and you’d keep a tally for them of your time spent on maintenance. If you run out of days, you can open up the discussion about pre-allocating more days
2. Charge a percentage of the project fee yearly for the SLA. This percentage is usually quite low, something like 1-8% a year. This route is more common on larger projects, not so much on small projects. If you’re going this route, there are 2 different paths you can take. The first is the charge more percentage and include more services like hardware swap outs, same-day 24/7 response times, free on-site visit if needed (depending on where the installation is). The second path is to charge a lower percentage fee but then use the percentage as a retainer for response and diagnosis, then you’d charge separately (or pull from pre-allocating days) for the actual work you need to do.

The reason I mentioned clout earlier is because 1-8% of large projects can still be quite a hefty fee to charge and some clients might not be into the thought of paying that much yearly. In their mind the project is finished, so paying a percentage every year is not ideal. You’ll have to play the pricing by ear based on client and project size. Something you can do is offer them both options and let them decide. Either way is pretty fair and works for you, so it’s really about finding what the client is comfortable with and will go along with.

Know your client

What you may not realize with many permanent installations is that your SLA will most likely be signed with a different company than the one you may have worked on the project with (unless you were already directly working with the end client). You should start asking whomever brought you on the job about who will be signing the SLA with you. In some cases, if you’re working with another AV integrator, architect, designers, agency, etc, they may want to keep the relationship with the client in their own control, so they’ll likely sign an SLA with the end client, and then they’ll either sign an SLA with you or they’ll just tell you “we’ll call you if it stops working.” In other cases, partners may want to wash their hands of the project once they’re done, at which point you may be redirected to send your SLA to the end client or whomever owns the system/installation at the end of the day. It’s goo to start asking early on in the project, just so you know what to expect.

Wrap up

It’s hard to get deep into SLA’s in such a short post, but I hope these quick notes at least give you a bit of primer on what to add and look for if you’re setting up your own SLA contract for a project. Just remember the important things you want to do: define everything, figure out pricing, and know your client. From there you should have quite a bit of flexibility to define the SLA as you think is fair and professional. Enjoy!