Tip

Happy customers through high-performing service level agreements (SLAs)

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

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:

  1. Header: Clearly states the parties involved in supporting the SLA and application.
  2. 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. "
  3. Parties and Responsibilities: A table works well here with columns entitled: Party, Responsibilities, Response Time, Coverage Hours.
  4. Swim Lane Process Flow: This is an optional item and can be used to visually describe who does what and when.
  5. 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.
  6. 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?
  7. 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

There are Comments. Add yours.

 
TIP: Want to include a code block in your comment? Use <pre> or <code> tags around the desired text. Ex: <code>insert code</code>

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
Sort by: OldestNewest

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

Disclaimer: Our Tips Exchange is a forum for you to share technical advice and expertise with your peers and to learn from other enterprise IT professionals. TechTarget provides the infrastructure to facilitate this sharing of information. However, we cannot guarantee the accuracy or validity of the material submitted. You agree that your use of the Ask The Expert services and your reliance on any questions, answers, information or other materials received through this Web site is at your own risk.