In reading a post over on one of my favorite blogs, Talkin’ Cloud, I saw a discussion that caught my attention. The post itself is titled, Top 11 Questions MSPs Ask About Cloud Partner Programs, but the discussion touched on Service Level Agreements (SLA). In particular the seeming lack of importance customers give the actual SLA service provides give them.
In my experience at NetEnrich and at OpSource prior to that, our customers would spend a lot of time on the Master Service Agreement (MSA) with many conversations between their legal team and our legal team and give and take on a number of points. Naturally, these are important conversations to have, but in this negotiation process the SLA was typically given a cursory read and accepted.
As a commenter pointed out, one can argue that the ultimate SLA is customer satisfaction and a vendor with low customer satisfaction will loose their customers. While I agree with this premise, I believe customers who do not question the SLA, miss a great opportunity to get a better idea of how the service vendor will deliver on customer satisfaction. I recommend not only reading and fully understanding of a perspective vendor’s SLA to insure it meets your needs, but also to always ask the vendor a number of pointed questions about their SLA and how they operate in a number of possible incidents and then carefully gauge their responses. This is the best way for a customer to set their expectations of how the vendor will respond to incident prior to engaging. It will also help to expose areas to negotiate on the SLA along with possible areas where you may need to augment the service to maintain that ultimate SLA with your internal or external customers.
A few things to consider in an SLA:
- Evaluate the promised response time based on the severity of the incident. Does this response time fit your needs, if not is there a way you can work with internal resources to deal with it?
- Look at the teeth in the SLA. This is what happens if the vendor does not meet their commitment under the SLA. Many vendors have great standards in their SLA, but have little or no teeth in the event they fall short.
- Understand how breaches need to be reported. Here you need to understand how long you have to report the breach and what process needs to be followed.
- Look for what we call the No Harm, No Foul SLA. In this SLA, if your team does not report the breach, it did not happen. In many cases this type of SLA works fine, however, if you are relying on the service to support a series customers, then this may not work as well because some of your customers may see problems you did not see and they may be too busy or frustrated to report it to you. In this setting, you may want an SLA where the vendor is required to report to you any and all breaches.
- Lastly, be sure you can live with the performance level defined in the SLA. If you can, then you will probably be happy when your vendor out performs it.
Let us know you thoughts and please ask questions.