There is no magic to keeping customers happy by meeting your obligations under the SLA. It's all hard work. However, if you plan well and get the right people involved up front, you can create and manage an SLA that will keep your customers fat and happy. Why will they be fat and happy? Because they will know that their application is safe and secure due to three reasons:
1.) They can rely on the automated monitoring systems that spit out relevant performance data at a moment's notice.
2.) The SLA is protected by internal, cross-functional teams that work well together based on operating level agreements or OLAs (more on these in a moment).
3.) YOU, the SLA manager who can answer the customer's questions quickly because you have the pulse on what's going on with the application due to the automated monitoring systems and your close relationships with your internal teams.
What I want to make sure you don't do as we talk about these is to look at the three reasons separately. They are very much enmeshed and need each other in order for the whole system to work.
1. Automated monitoring systems: There are many, many great monitoring systems on the market so I won't even attempt to analyze which ones work well and which ones don't. If your company does not yet have automated monitoring systems, do your homework and research what is available and what would work in your
2. Internal cross-functional teams and OLAs: So many of us charge ahead with our automated monitoring systems and SLA and think nothing about making sure the teams that support the SLA, first, understand the SLA measurements, and, second, understand their roles and responsibilities when it comes to supporting the application. Take the time to discuss the SLA measurements with your support team and create simple, one page OLAs that are agreed to and signed off by the impacted parties.
The basic components of an OLA are:
- Header: Clearly states the parties involved in supporting the SLA and application.
- Purpose: An example is: "The purpose of this OLA is to clarify roles and responsibilities for Party A, Party B and Party C for the SLA between Customer and Department/Company supporting application. "
- Parties and Responsibilities: A table works well here with columns entitled: Party, Responsibilities, Response Time, Coverage Hours.
- Swim Lane Process Flow: This is an optional item and can be used to visually describe who does what and when.
- Entrance and Exit Criteria: This criteria is very simple statements of what is needed before each of the parties can get involved and when they are moving the workflow forward to another team member. For example, a developer needs a repeatable experience on a reported bug in order to recreate the bug to fix it. This is the developer's entrance criteria. The developer's exit criteria to the testing team are instructions on how to test the bug fix.
- Term of Agreement: This term states how long the application SLA is relevant. Is the SLA for two years? Five years? How long is the team to support the application using the current SLA's measurements?
- Signatures: Always be sure to have the team member's manager sign the OLA. Team members come and go over time, so you need a manager's name on the OLA to give it support should personnel change.
3. You, the SLA manager: You are so clever. You have the automated monitoring software installed on your servers and you have great data on up time and outages. You share this information with your internal support teams and they respond quickly and are able to reduce further outages as they understand the performance measurements on the SLA and their role, as described in the OLA. Now all you have to do is take this data to your customer and work through any issues or questions that may arise from the data and work performed by your team.
As we've discussed, there is no magic in keeping a customer happy through high performing service level agreements. It takes hard work and constant communication with your support team and customers. However, once you establish your SLA measurements, train your support team on these measurements and their roles, as described in the OLAs, and analyze and communicate the data from the automated monitoring system, you will have a well managed SLA. Maybe it's not magic, but does that really matter when your application is meeting the SLA measurements and your customer is happy? I think not. A happy customer is a returning customer, which is always a good thing.
This was first published in October 2010