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
Requires Free Membership to View
When you register, you'll receive targeted emails designed to keep you informed of the most relevant information on Agile development, application security, testing & QA, software requirements, and more.
Hannah Smalltree, Editorial Director
environment. Or reach out to friends in other companies and
see what they are doing. What works for them and where are they having problems? You do not have to
pay an arm and a leg for this software. Just make sure you can get the reports you need when you
need them. Managing by data (vs. managing by gut) will change how you work with your customer. If
your data shows you have not met your SLA, tell your customer what you are doing to meet the
measurements. Maybe your goals were too lofty. If they were, renegotiate the SLA to be more
realistic. Customers like honesty. The data will make you more legitimate in your dealings with
your customers. This is also a great tool for your customers and will help your internal teams know
where the problems are and will assist them in their root cause analysis.
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
Join the conversationComment
Share
Comments
Results
Contribute to the conversation