When Should You Not Use an SLA?

When Should You Not Use an SLA?

May 23

We’ve spoken about service-level agreements in Mark Crall’s great post Objectives, Requirements and SLAs, oh my! (part two is coming soon), but there are situations where you might not want to be held responsible for providing certain services. There are situations that will require you to put in extra man-hours that your monthly fees don’t effectively account for. You run a business, so making sure you get paid for additional work is obviously essential.

Before we get into scenarios you’ll want to consider before entering into an SLA with a client, ask yourself whether you should take clients without an SLA at all.

SLAs create a level of security for you in knowing exactly what you provide and how much recurring revenue you’ll receive from providing it, and they also let the client know exactly what they should expect from you.

While they can be very effective, some would argue that it’s not worth the effort to take on clients with whom you wouldn’t feel comfortable entering into an agreement. Is it worth the hassle to handle questionable clients at all? Or is there a chance that fixing an unstable network will end up resulting in more revenue? Certainly, a service-level agreement affords you the opportunity to decide which services you’re providing to clients, and they can be flexible, so keep that in mind.

There’s probably a type of SLA that will work for any type of client. In questionable situations, keeping your agreement at a bare-bones level might help you mitigate the risk of doing extra work you might not be compensated for. That way anything not outlined in your agreement will result in an additional fee.

For those that want to work for clients without an SLA in place (and with a little help from an article in MSP Business Management), let’s have a look at when you should avoid using SLAs.

Bad Networks

There are all sorts of people out there. In IT managed services, like any trade, there are those that are excellent and those that fall short. If you’re taking on a new client that previously had a poorly managed network, you might be asking for trouble. There’s a lot to account for as you determine what you can do for a new client, but you don’t always want to agree to something you find out you can’t handle later on. As you assess the network of any new client, look at what kind of shape it’s in, you don’t want to end up needing to meet agreements that are overly time consuming as you attempt to cleanup someone else’s IT mess. Help out the client, but don’t make any firm agreements until certain standards are met. Things like hardware warranties and network systems and solutions that just can’t be replicated fall in this category as well. Again, make sure you’re getting paid for any extra work you’re doing.

Clients With Complex Needs

There are clients that have very simple needs. For example, a small business might just need some simple POS systems and phones, while a larger company might need server arrays and much more complicated networks. Consider how complex a network is and how much service you can feasibly deliver a client—especially those with more complicated needs like those in the medical field. You can’t spend all your time attending to a single client, so evaluating their needs alongside your abilities will allow you to decide whether or not an SLA is really the most effective path to take to service them.

Software without Support

As an MSP, you’re an expert, but even the best of the best occasionally need support. If a prospective client doesn’t have support contracts with vendors for the software they’re using, you might be in trouble when you need to call them for help. Without help from support, you can spend hours trying to figure out a problem that a simple support call could help you fix in minutes—if your SLA ties you to service that takes you too long to complete, you’ll lose money. Make sure software has support, and if not, an SLA might not be effective for that particular client.

Internal IT

Some clients will want you to handle everything, while others will have internal IT departments to handle the day-to-day operations. If the internal IT employees for a client don’t quite know what they’re doing or don’t seem trustworthy, you’ll spend extra time bailing them out when they do something wrong. You don’t need that, so if you don’t trust the internal IT staff members, an SLA might not be the right route for the client.

External IT

If you’re taking on a new client, it’s very important to make sure that you’re the only IT firm working for them. That means only you and your client should have access to networks and critical infrastructure items. You never know what can happen if another IT shop has access to systems. There are all kinds of people in the world and giving the wrong person access to important information is a bad idea—their goals and agendas can easily conflict with yours. Before you enter into any agreement, make sure you’re the only firm with access. Where applicable, create new access credentials and delete old ones so you know only you and your client can access the systems.

Difficult People

Remember what we said about different types of people? There are those that understand the limits of technology and will peacefully accept that things need to happen the way they needed to happen, while others will needlessly buck the system. Some simply have no idea what they’re doing when it comes to even simple computer-related tasks, and some expect way more than you can effectively deliver. Given the nature of humans, it’s not worthwhile to get into an agreement with any client that seems unruly, rude, or will nitpick and call you with questions every time Java needs an update. It’s not worth your headache so don’t get into an agreement that you’ll regret later on.

Informal Arrangements

There are situations where you may decide to do some trade work, perhaps you do IT for a tax firm that will help you out around tax season in exchange for your services or you help your mother with her POS system at a small boutique. These situations don’t always require an SLA because they tend to be casual understandings rather than contractual obligations.

Be sure your contracts and insurance cover you in any case, but you may not need to clearly define your service with casual relationships like these.

Also, depending on the size of your business, and the size of business you’re supporting, you may still want to consider SLAs for these situations anyway, but it could depend on what type of service you’re talking about. If it’s simple things it might not be worth your effort to draw up something formal, but if you’re handling major things like backups and security, you’ll probably want to have something in place—especially where liability could be an issue.

Client Stability

How long will a client business survive? Are they growing? Shrinking? Bleeding money? If you’re providing someone with service and they run out of cash, who will they pay first, the power company or the IT person? As you’re evaluating a new client, it’s important to also evaluate them as a business because you need to be paid for services you render. If you’re not sure, or their revenue stream seems questionable, you certainly don’t want to be locked into an SLA—the dead horse says, “Don’t do work you won’t be paid for.”


SLAs are great for both the client and the service provider in the right situation. Ensuring you aren’t entering into contractual obligations that will bite you later is a lesson from business 101. Take a very close look at a client and their needs before you decide if an SLA is right, and be sure the SLAs you do enter into are realistic, while also covering the client’s needs.

Alternatively, you can charge hourly for services. In many of the situations above, hourly is an excellent route because you’ll be paid for any nitpicking or when you’re cleaning up the internal IT department’s mess. Whether or not that’s a direction you’d like to go is completely up to you.

For more about how to actually create an SLA (with special focus of backup and disaster recovery offerings), be sure to read part one of the two part series, Objectives, Requirements, and SLAs, oh my!

Photo Credit: milos milosevic via Compfight cc