I love the formal expression, “how may I be of service?” It conjures an image of a suited server with a silver tray and inspires the enjoyable anticipation of being pampered. For me. For some (looking at my best friend), it conjures the image of Tim Curry in his role from Clue.

At first glance, it’s the same general idea, but on closer inspection, it’s clearly very much not the same thing. (Those are not implements of pampering he’s carrying on that tray.)

A Definition: Service Level Agreement (SLA) prevents that kind of disconnect. It details the time and attention the service provider will provide to end-users, including to resolve issues with the app or site. The SLA defines how we will be of service.

In my last developer position, the suite of apps I supported had different SLAs. The primary one had a normal operating cycle of 23/7, down (inaccessible by end-users) for one hour per day for backup. The Disaster Recovery priority was high, and got higher over my 8+ years with the company, as the app became tied in to more and more business systems. Issues required a response time of a couple of hours, over the weekend as well. Kind of difficult to maintain when there were only five of us on the team, only three able to provide technical support, but we did it, providing all tiers of support to a user group of 200+. Which is good because, while the SLA wasn’t formally captured anywhere that I ever saw, it was definitely communicated to our key clients/ stakeholders. Like Legal. And they let us know if and when we failed to live up to it.

The paragraph above is a basic SLA. It details the who, what, where, and when issues will be addressed. Missing from the above is how, specifically budgeting, and why.

How	Methods for delivering Support – email, phone, etc. Budgeting – who pays for the support All tiers of support
What	Normal operating parameters Uptime Services provided What we’ll fix Tiers of support Services that are out-of-scope Escalation process
When	Response time to initial request Escalation timing
Where	Support contact method Environment for deliverables
Who	Support providers “Us” User community – who can request Support “Them” (kidding!) Escalation path How it gets from the initial Support request to developers releasing an app change
Why	Not an existential question! Business priority of the app will determine why it is supported Prevent loss of revenue? Provide service to employees?

The answer to “Why” is fed by the business criticality of the service. If decisions on Uptime, Backup and Retrieval process, and Disaster Recovery priority have already been made, the reasons behind those decisions are the “Why” we have this SLA.

…Yes I’m in the process of writing an SLA for a client. Why do you ask?

More reading

• ITIL® Training and Preparation: SLM, Designing SLA Structures, and SLA Content by Simplilearn