How to protect your organization with strong service level agreements

One of the most critical aspects of working with tech vendors is establishing and managing solid SLAs. Here's a look at key details and areas of service IT should hammer out before signing a contract.
Written by Mary Shacklett, Contributor
Image: eccolo74, Getty Images/iStockphoto

IT's strengths are in software, hardware, problem resolution, and working with vendors in the identification of new technologies and systems that can help their companies. However, few IT professionals will tell you that contract administration -- or having to approach vendors on more difficult subjects, like expectations for performance or service level agreements (SLAs) -- are their favorite things to do.

Vendors know this.

"I will tell you that maybe one third of SaaS (software-as-a-service ) vendors have SLAs," the CEO of a SaaS company told me five years ago. But now that's changed. Most IT vendors have some kind of service guarantees, and most corporate IT managers demand them.

But this doesn't necessarily mean that IT is keeping its eye on the ball to ensure that vendors are meeting their SLAs -- or even that those vendors have all the SLAs that companies should be asking for.

Let's look at these issues by threes.

First, there are three areas that IT departments tend to overlook.

1: Who's defining the SLAs?

Many IT'ers sign contracts without thoroughly reading the fine print of the SLAs (if the vendor has them). Or they tacitly accept that the vendor is offering best-practice SLAs so they don't need to review them. Or they think their companies are too small to challenge the vendor's generic SLAs.

When you are negotiating, everything is on the table. A vendor might say "no" to your request, which you will then have to consider, but the vendor is also highly motivated to earn your business.

Your vendor's SLAs should minimally conform with the internal SLAs you demand of yourself. If you don't have a discussion, you're failing to address what you should. When I was the CIO of a smaller company, I had to negotiate with a large, global tech company. They only became aware of our needs because I mentioned them -- and we did work the issues out.

2: Modifying contracts

When you ask vendors to include additional SLAs, they will often tell you, "I'm sorry, but legal says we can't modify the contract."

You can modify the contract -- and without changing the vendor's boilerplate text. You simply write an addendum that's added to the end of the contract and a cover letter that clearly states that both the boilerplate vendor contract and the addendum constitute the full and integrated agreement -- and that, in the case of a discrepancy between terms in the original boilerplate contract and the contract addendum, the terms of the addendum will govern. You should have your own legal counsel look this over as well.

3: Losing contracts

I have consulted with companies that ranged from fewer than 20 employees to thousands of employees. But regardless of an organization's size, one issue I've regularly come across is that IT can't find where it put its vendor contracts! Having the contract to refer to is especially important if you're wondering how much time is left on your contract or what the SLAs are. It is embarrassing when you have to go back to the vendor to get a copy of the agreement -- but I have seen IT departments do this more than once.

SEE: Will cloud vendors dominate machine learning? Early signs point to yes (TechRepublic)

Now, here are three things that you should do with your SLAs.

1: Keep a record of SLA performance

Your vendor needs to know that you are serious about SLAs, so SLA performance must be monitored on a daily basis. Aberrations in performance should be clearly documented and dated and discussed with the vendor -- immediately, if there is a production problem, and in vendor SLA meetings if performance is a trending issue.

2: Have regular SLA reviews with the vendor

SLAs should be reviewed with the vendor annually, at a minimum. Many companies opt for quarterly reviews. During these meetings, you and your vendor should review SLAs with a mutual understanding that they might need to be modified, since both business and IT continue to change. The meetings are good opportunities to discuss and to make these revisions.

3: Have SLAs defined for an exit strategy

One of the toughest IT projects is making a conversion from one vendor's system to another. The vendor that is about to lose your account might not be very cooperative when it comes to moving your data (and account) to a competing vendor. Relations may even become stormy and hostile. You can avoid these situations if you include an SLA in your contract for "deconversions" and define the expected level of performance of the vendor in that situation.

SEE: Don't overlook dispute resolution when you negotiate vendor contracts (Tech Pro Research

Finally, here are three areas of service that SLAs may not necessarily address but that are important to discuss and define with your vendor before you sign a contract.

1: Disaster recovery testing

If you're moving a mission-critical application to an outside vendor, you should have an SLA that requires at least one annual disaster recovery test and failover for the application that the vendor hosts. The SLA should specify a maximum amount of time allowed for failover.

2: Account stability

Vendors often put their best people on your account when you are first onboarded -- and then assign you to a rep who is not as strong. When you negotiate your contract, reserve the right in writing to interview and/or meet an account rep before they are assigned to you. In this way, you have some control over the person you're getting. This is important because the account rep is a vital link in day-to-day communications between your staff and your vendor.

3: Compliance

Your vendor should be able to provide you with up-to-date financial and IT audits. Certainly, your own examiners will ask you for these. Requiring the latest updates of these documents for your files or access should be written into your contract as part of the expected IT governance from the vendor.

Also see

Editorial standards