Service Level Agreements (SLAs) can be long, tedious, and exhaustive. They can leave a reader crossed-eyed and a writer with full-blown Carpal Tunnel Syndrome. But, they might be some of the most important documents in a post-launch plan – and it’s possible you never use them.
So What Is an SLA Anyway?
An SLA is a document in which you formally define the services to be provided by the vendor in support of a client’s project, specifically post-launch. The list of services can range from performance expectations to issue/support triage. Well-defined SLAs should leave few questions for the vendors or client when a problem arises.
The value of an SLA is two-sided. The client has an assurance that they are covered in emergencies or new OS version releases, while the vendor has a contract that states what they are expected to support and in what time frame.
For a vendor, think of the letters CYA (Cover Your A#%), because that’s precisely what an SLA does. It covers you for all of the post-launch questions that inevitably come from your clients. This document helps you establish what you will and will not support and should also contain every scenario for your project – even the ones that seem far-fetched.
For example, let’s say you’re developing a web-based application for a client. You certainly cannot make the app compatible with every possible combination of OS, browser, and mobile device, so set the ground-rules when you are gathering requirements from the client. Add them into the SLA. When the client comes back after launch and says the app won’t run on Netscape in Windows 98, you can point back to the SLA in order to CYA and say, “Hey, we never agreed this would work on that platform.”
What’s in It for the Client? Peace of Mind.
For a client, having a well-defined support process with clear time windows to promote to customers is paramount. Let’s say a client contracts a call center to support them and then they promote these hours on a website. If that call center is closed during the promoted operating hours, without an SLA to hold their call center vendor accountable, the client has little recourse and will ultimately pay the price of lost customers.
SLAs Are Mutually Beneficial.
All of the items in an SLA should be discussed between the client and vendor. There can be a lot of give and take, but like many important documents, SLAs are meant to be written and rewritten … and rewritten. As new and unforeseen issues arise around a project in its post-launch phase, the client and vendor should revisit the SLA. This helps the client to maintain an updated level of support and it also helps the vendor to CYA.
About Mike Robbins
Born and raised in Philadelphia, Mike came to Arizona by way of Fordham University in New York City. Mike is still in love with his hometown sports teams almost as much as he loves not having to shovel snow in the winter. In his free time he loves playing softball and taking photographs.