This site is part of the Global Exhibitions Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 3099067.

Informa

The Peer-to-Peer blog is a forum for Channel Partners readers with the goal of stimulating discussion among partners about important issues impacting their business. The opinions expressed here are those of the authors and not necessarily those of Channel Partners editors or publishers. If you are interested in submitting a blog, please contact Editor-in-Chief Lorna Garey, lorna.garey@informa.com.

Meeting That SLA? Prove It

- Blog

Mike BurkeBy Mike Burke

For the most part, service providers do a good job delivering the service levels agreed on in the SLAs issued to customers. Still, is your documentation such that you can prove that to an IT team questioning who is at fault for performance problems?

Infrastructures today are so complex, with so many components, that any element that isn’t working correctly could result in the customer having a bad attitude toward the platform that you sold and a service provider put into place.

For the customer, it could be a situation where every time they drop into a database and do a data dip, they don’t get a response within the expected timeframe of seven to 15 seconds. Instead, they’re getting a timeout error. Maybe you’re doing a SIP refer to hand the call to the company’s designated outsourcer. Even though the SIP refer works great, the call gets lost while it’s being routed into the other environment.

Unfortunately, your system is the voice of the environment, telling the customer that the information isn’t available. On the surface, it seems like you aren’t fulfilling your end of the bargain. It’s a classic example of “don’t shoot the messenger."

As a service provider or MSP, make sure you can demonstrate that everything on your end is working properly. That means having a testing and documentation process that demonstrates you’re providing the capacity your clients have come to expect. There are a number of ways to put that process in place. What’s important is that you show you’re doing exactly what you’re supposed to do, backing it all up with appropriate metrics.

Even if there are no problems, you never know when a client might have a question about the level of service they are receiving. You don’t want to be rocked back on your heels, resorting to a response like, “Hmm, I’ll have to get back to you on that."

Instead, be proactive so that you already have the relevant data at hand. Then you’ll be able to confidently state that everything is working exactly the way it’s supposed to. For example, perhaps you would show that the systems are answering phone calls within two rings.

Sign on the Dotted Line

A testing process is also important in sales and fulfillment. As a service provider, it can be challenging to get a customer to sign off on the initial implementation that says that everything is functioning at the expected capacity. The customer needs to feel confident enough to write the check, but it can be extremely difficult to come up with a rigorous acceptance process that they feel comfortable executing.

This is where you have an opportunity to go into the environment and explain the plan step by step. With the client’s participation and the right tools and process, you can prove that the system has the intended capacity and can perform under load, even if any adverse situations should occur unexpectedly. For example, if a server or network segment goes down, you can run through a high availability drill and prove that everything still works as intended.

As a result, expect the customer to say, “I’ll check off all these requirements on the list." The stress-test implementation will turn into a definitive acceptance event. That goes a long way toward smoothing out the relationship between the service provider and end user. You proved that it simply isn’t about the interpretation of data. Instead, you have concrete documentation reflecting that the system ran at certain rates for a given period of time. You did the fault injection and recovery that shows it does everything it’s supposed to do. The customer can then sign on the dotted line with confidence, allowing everyone to go toward the future with a great relationship.

Mike Burke is director of IR Testing Solutions. Mike has banked more than 40 years in telecommunications, contact centers and networking while working at Honeywell, GTE, PNC Associates, Verizon, IQ Services, and now, IR Testing Solutions.

Print
Comments

comments powered by Disqus