The smart MSP's guide to Service Level Agreements

We’ve all been there. You get the call to fix a customer problem, hurry to resolve it as quickly as you can, but somehow the customer is still unhappy, because they think it took you too long. Or what about the time you fixed a problem that wasn’t even part of the scope of work you normally do and they weren’t satisfied with the work, so, somehow you still look like the incompetent idiot. 

None of us wants to be in this situation. And, in reality, sometimes the issue most definitely isn’t the work you do; instead, it’s about the customer’s perception of the work you do—whether they think it was fixed in a timely and professional manner, etc. 

The real problem is simply a disconnect between how you think you should be servicing your customer and how they do. Communication is certainly key here—and can resolve some of the problem—but memory always fails us and, sooner or later, you’re going to be back at a point where your customer says, “This was included in our [verbal] agreement” and you’re saying, “No it isn’t.” 

What you need is a Service Level Agreement (SLA). The SLA serves as the core document that defines the services you’ll provide and sets the customer’s expectations around those services. At its most basic level, the SLA is the documentation of what each of you are looking to get from each other. 

In this article, we’ll cover why you need an SLA, when you should—and shouldn’t—have one, what should be included, considerations when writing an SLA, and how to make your SLA measurable. 

You need an SLA

Now, despite those bad support scenarios that we’ve all been through to one degree or another where the customer is unhappy, despite you providing them a service as promised, some of you may still think you can run your business without one. The most successful MSPs will adamantly disagree with you. There are some very compelling reasons why you need an SLA: 

• Improve customer perception
  There are many unprofessional IT support firms around who document badly and fail to work according to best practice. Even the smallest customer is unlikely to see the need for an SLA as an exercise in excessive formality. Instead, it sets your company apart as one that takes their business and their obligations seriously.
• Clarify partner obligations
  While, as an MSP, you are probably responsible for all your customer’s key hardware and software infrastructure, there are likely to be various systems that do not fall under your remit. These could include line-of-business applications that have their own support contracts or print devices that are supported by a copier supplier. By making sure that your SLA lists what is included and detail what is not, you can ensure your company isn’t called upon to support troublesome items that are not your responsibility.
• Clarify user obligations
  Writing an SLA well can go a long way to mitigating some of the commonly contentious issues between IT and users. These can include installation of unauthorized software, the importance of logging problem calls in the correct manner, and the need for accurate communication of error messages. After all, how often do technicians begin to fix a problem with no more information than “my computer isn’t working properly?” Establishing what’s expected from users will help ensure your customer is doing their part to make your work efficient, and them productive. 
• SLAs protect your time and sanity
  There are invariably one or two users at every company who will have unrealistic expectations and place unfair demands on your time. If your SLAs make clear exactly which days and hours you have agreed to provide support, you can step away from phones and emails at the end of the day and be free to enjoy your personal time.
• SLAs provide protection
  Good SLAs can give you protection and peace of mind if your company is unlucky enough to become embroiled in a legal dispute with a customer. If, for example, you have a customer who fails to pay, you will find it far easier to prove that you met all your obligations if you have a signed agreement detailing your business relationship. 

In order for your SLA to provide this protection effectively, a trained legal professional should check its content.

• SLAs help you resolve disputes
  When occasional disagreements occur, having a detailed SLA that is accurately reported on helps you support your case. For example, if a troublesome user complains about your service, you may be able to prove that your company does, in fact, consistently respond to and resolve problems within agreed timeframes. In the event of a serious dispute with a customer, a good SLA could represent the difference between a simple resolution and a protracted legal or political battle.
• SLAs prove your value
  Customers’ opinions of your company’s service can vary day-to-day based on the current mood or on any ongoing system issues. Reporting performance against agreed SLAs allows you to periodically present your customers with an indisputable big picture view. Sadly, IT consultants are often judged on the most recent system problem—even if they have ensured consistently perfect system performance for months previously. Being able to show your customers, in black and white, that you are meeting your obligations and ensuring excellent system uptime, can be enough to bring them back to your side and prevent them shopping around for a new support provider.

An SLA definitely serves a purpose to make the MSP successful while allowing the customer to hold the MSP accountable. But, are there scenarios when an SLA isn’t necessary? To find out, let’s first outline when one is prudent and then when you can forego an SLA. 

When do I need an SLA?

To boil it down, an SLA is absolutely required for computer repair in the mid-market and enterprise space, and often in the SMB space where the customer demands it. But your typical small business looking to engage an MSP that specializes in SMBs may see an SLA as more trouble than it is worth. 

Small businesses typically deal with small MSPs because they want a trusted relationship. There is certainly a need for MSPs to set a customer’s expectations so that they don’t come to expect you to deal with every service request at the drop of a hat. This means you may need to either provide a much simpler SLA for the very small business, or stick to a standard SLA for every customer and run the risk of needing to pass on that SMB customer.

When should you NOT use an SLA?

It may seem strange (given this is an article on SLAs) to suggest that, in some cases, it may be best to avoid SLAs. However, in some situations (and with some customers) this can be a sensible strategy. Here are some examples:

• Unstable networks
  All experienced IT professionals know what it’s like to take on an infrastructure that has been neglected or badly managed. If you are in the process of picking up the pieces after the departure of a previous support provider, it may be best not to agree to work to an SLA—at least not at first. It is only fair to expect a certain amount of time to get the infrastructure back on an even footing. Quite often your customer may need to spend some money to achieve this. In these situations, you may wish to declare that you can only work to an SLA once certain prerequisites are met—otherwise your life may become unnecessarily stressful while you correct your predecessor’s mistakes.
• Difficult customers
  All MSPs find themselves working for difficult or unrealistic customers on occasion. Some customers are never satisfied and some can be a complete chore to work for—rude, demanding, and constantly tinkering with settings they don’t understand! Ironically, it’s often these customers who pay invoices late too! When you find yourself doing business with customers like these, it’s worth asking yourself if you really want to be tied to an SLA—after all, an SLA is an agreement, not a stick to beat you with—but will customers like this truly understand that? So, if you feel like an SLA will only be used to squeeze more work from you, either engage with this kind of customer on an hourly basis or write an SLA with more detail to outline the levels and limits of your service.
• Informal arrangements
  You may find that your business ends up providing IT support to some companies on an informal basis—perhaps you swap services with your accountancy firm or manage the landlord’s network in exchange for reduced rent. These customers probably don’t need an SLA given the informality of the arrangement. Obviously, you should ensure that your contracts and insurances cover you for the work you are doing on their systems, but these are probably not customers with whom you need to clearly define service levels.

It’s important to be clear that, in most circumstances, the use of SLAs is a wise business practice and not one that any MSP should ignore. However, there are always exceptions to rules. Instinct is a powerful tool in business—if it warns you to be on your guard about any particular customer, it is sensible to take notice.

While the correct reaction to this instinct is usually to get a detailed SLA in place, on occasion the best strategy may be the exact opposite!

Now that you have a better understanding of when and where an SLA is appropriate, we’ll outline what needs to be included in your SLA.

What should be in an SLA?

Generally, anyone who has been exposed to the concept of SLAs has a basic idea of what is included—lists of hardware/software supported, response times, etc. But, as the saying goes, the devil is in the detail… and you should plan on having quite a bit of detail in your SLA to ensure everything is spelled out. 

Services definition

Scope of services

It is important to clarify the exact scope of the services you provide as part of every SLA. Detail exactly what servers and software systems come under your remit and make sure any exclusions are made clear. For example, if a customer has a bespoke database or CRM system, they may go directly to the software company for support. Spend time defining the service accurately to avoid future disagreements.

Support hours

What are the normal support hours for your business? What about outside hours? Will additional charges be incurred if calls are made outside of normal support hours?

System uptime

System uptime targets are a common metric to include when writing SLAs. Usually measured as a percentage, system uptime readings allow customers to review how reliable their IT infrastructure is over a period of time. It can be quite difficult to monitor system uptime manually. Thankfully, software solutions are available that serve this purpose. 

It is wise to monitor uptime for all key systems separately. For example, try to provide an uptime percentage for email, file services, and remote access separately, as well as provide customers with a combined figure. This helps you and the customer identify if a particular service is causing problems, which may lead to recognition that some additional work or investment is required.

What to do when there’s a problem

Problem reporting

What does the customer do if there is a problem? Do they send an email? Fax? Carrier pigeon? Whatever the method, make sure you are specific.

Problem response times

SLA response times usually refer to how quickly you will respond to a technical issue being raised via phone, email, or other methods.

Telephone response targets are sometimes measured in number of rings. Alternatively, and perhaps more relevant to the smaller MSP, response times may refer to how quickly you pledge to reply to an email or call back to respond to a voicemail message.

When agreeing upon suitable response times, it is important to clearly define working hours and ensure customers know that only these working hours are included in a response time.

For example, if operating hours are 9am to 5pm, Monday to Friday, and a call is logged at 4.55pm on a Friday evening, then a response to this at 9.05am on the following Monday morning is a 10-minute response time—rather than three days—because it's based on your business hours.

The kind of response you can offer really depends on the nature of your MSP business. The higher your staffing levels, the more likely it is that you can promise an answer within a number of rings or minutes.

Problem resolution times 

Defining how quickly problems should be addressed from the time an issue is logged until it is fully resolved is an important part of every SLA. Usually, it makes sense to assign a level of severity to each problem that occurs, ranging from top-priority, urgent issues, usually resulting in one or more staff being unable to work, down to routine nice to have improvements to the system. 

Once the priorities are defined, you should agree upon a realistic resolution time for each type of problem. For example, four hours for an urgent issue and 72 hours for a low priority request. After these timings are agreed, you should use a call logging system to track the progress of each issue and report back your performance compared to the SLA.

As with response times, it is important to ensure that resolution times are only calculated based on agreed working hours. It is also wise to stipulate that a resolution time only begins from the point that a call is correctly logged using an agreed method.

In order for problem resolution to be accurately tracked and measured as part of a service level agreement, it is essential that all users know the correct way to report and prioritize problems. Sometimes making individual users understand that a system-wide mail flow problem is of higher priority than their low toner cartridge can be awkward!

The most important thing is to agree upon targets that are achievable. For example, if you intend to offer a four hour fix time for urgent server issues, you must have adequate staffing, hardware service contracts, and system redundancy to make this possible. If your customer does not have a sufficiently solid infrastructure to facilitate this, then it is unwise to agree to an unrealistic target.

Setting SLA targets provides you with a valuable opportunity to manage your customer’s expectations and protect your business. Telling a customer that you cannot agree to a four hour resolution because their servers don’t have enough resilience features may even prompt them to upgrade their infrastructure! Most importantly, however, it gives you a chance to present a realistic view of what can be expected of you.

Other issues to address

Support constraints

Sometimes, the specifics of a particular customer will not allow you to meet response or resolution times. For example, if there is no access to the customer building on Sundays, it needs to be noted in the SLA that you will need to meet modified response and resolution time should an issue arise on Sundays. Another example is if the customer’s hardware warranty includes replacement parts the next day, you obviously cannot meet a four hour critical SLA for a server if the parts won’t be there until tomorrow.

Customer responsibilities

What sort of burden is on the customer? Do you need them to keep their systems up to date to prevent malware? Or will you be doing this as another part of your service? What type of content can they download/host on their websites?

Confidential information/data protection

How long will records be kept? What happens to them when they are no longer needed? How will you protect your customer's personal and financial data?

The topics above are by no stretch of the imagination a comprehensive list. There may very well be additional sections that address a specific customer need. Every SLA is different and what might be important in some SLAs will be unnecessary in others. The most important thing is to make sure everything you and the customer are agreeing upon is in your SLA. 

Considerations when writing your SLA

Many times an MSP is eager to sign another customer, making promises of what, how, and when you’ll deliver without ever looking at the specifics involved in supporting that new customer. Blindly handing out an SLA—even if it’s your standard SLA—to a customer isn’t smart. Doing so may cause you to find yourself in a position where you can’t make good on what you promised.

So, both as you write your SLA, as well as before you consider giving the standard SLA to a new customer, consider the following SLA factors:

• Your staffing levels
  The kind of service you can deliver, especially in terms of response and resolution time, will differ considerably based on your staffing levels. If, for example, you are a one or two-man band, you are unlikely to be able to offer the same response time as a larger firm, because the larger firm probably has a team of people permanently manning its helpdesk.
• The stability of the customer’s network
  Imagine two customer infrastructures: one with nearly new, well-configured servers, multiple redundancy features and a tested disaster recovery solution, and another that is showing its age, with a fileserver that frequently falls over and various stability issues. It makes little sense to agree to the same uptime percentage and resolution times on both networks, as achieving SLA targets on the first network would clearly be more realistic than achieving them on the second.
• The customer’s working practices
  Every customer works differently and has different priorities. A traditional firm of accountants or surveyors may religiously work from 9am to 5pm, Monday to Friday, and have no interest in home and remote working. A cutting-edge media company may have people hot-desking and logging on from airports, and require support during rather more unsocial hours. As you can see, the same SLA is unlikely to be realistic for both of these companies.

Once you have a good idea of these factors, you are then in a position to discuss exactly what you can realistically offer to your customer.

Some compromises are likely to be necessary. Only the largest firms can offer high quality, 24/7 support—businesses that need it also need to be ready to pay for it. It is vital to only offer what you can deliver—this will save heartache and potential for disagreement further down the line.

Once you’ve properly defined what should be in your SLA, it’s time to think about how to make it work for you. In the next section, we’ll discuss how you can use your SLA as the basis for measuring the quality of the service you provide.

Making your SLA measurable

Customers engaging you to manage their network aren’t just wanting the problems to get fixed quickly; they also want to know that you are providing the services promised for the monies they pay you each month. They, in essence, want a way to hold you accountable. But rather than look at the SLA as a tool for the customer to use to your detriment, instead proactively write it so that you can use the service definitions to properly measure your work product and demonstrate that you are providing excellent service.

So, how do you make your SLA measurable?

Step 1:  Define the SLAs precisely

For SLAs to be truly measurable, you must go beyond vague pronouncements such as 99% uptime and four hour resolution time. For example, what exactly is 99% uptime? 99% of ALL time or 99% of working hours? If it is working hours, what exactly are the agreed upon working hours? Are there some agreed upon maintenance and upgrade windows that are excluded?

When it comes to resolving problems, does the resolution time begin when the problem starts or when it is reported? Does the resolution clock then tick until the moment the problem is resolved, or does it pause at 5pm on Friday and restart the following week?

Until these details are determined, it is impossible to measure performance in anything other than a subjective way.

Step 2: Involve the customer

It is worth taking the time to ensure that customers understand the reasons for SLAs and the technicalities involved in delivering them. For example, few customers realize that with only a nightly backup, there is often the potential to lose one day’s worth of data if a system failure occurs at the exact worst time. They probably don’t realize that if a drive fails, the server manufacturer may take a day to deliver a replacement.

By explaining these things to customers, they can gain an understanding of the challenges that face the average IT department, and can then decide if additional purchases or changes to IT operations need to be made. For example, if the customer decides that loss of a day’s data or 24 hours of downtime is too much for the business to risk, they can then support the capital spend required to develop the backup infrastructure further, by increasing backup frequency and building in redundancy features. 

Step 3: Use software

Measuring SLA performance properly really needs software; otherwise, you will spend a lot of time calculating uptime and resolution times. The two essential pieces of software are a helpdesk/call logging system and an SLA monitoring system. There are plenty of solutions available for both, most of which are relatively inexpensive.

Step 4: Report and adapt

Reporting to a customer monthly or quarterly on your SLA performance can be an effective customer satisfaction tool. If your SLA contains achievable performance targets, and you consistently meet them across your customer base, you can use these statistics to prove your competency and value to your customer.

SLA performance data can also be used as an effective marketing tool when shown to prospects. If a potential customer is comparing two service companies and yours can show documented proof of consistent compliance to SLAs, it is likely to put you at a significant advantage.

If you find that you are not meeting SLAs, measurable and detailed SLA reports will at least allow you to pinpoint where problems exist on the infrastructure, highlighting where issues need to be resolved, where the system needs further spend or development, or where your business can improve on its service.

You only need to work through the process of creating fully measurable SLAs once. Subsequently, defining them for other customers should be far more straightforward, as you will already have a process in place, as well as tried and tested software you can use to measure them.

Conclusion

Your goal is a satisfied customer and a happy, profitable services business. To accomplish both, you need to set expectations of what you can do, what you will do, how you will do it, and what you need from the customer to be successful for them. Building an SLA is the foundation for a long-lasting and fruitful relationship between you and your customer. 

An SLA will allow you to effectively establish with the customer what services will be provided, along with the limitations and constraints of providing them. It will also empower you to measure your own execution, acting as the basis for both improving when needed, and for demonstrating the value you are bringing to the customer.

By taking into consideration the capabilities of your organization, the needs of your customer’s network, and spelling out where the two intersect (in as much detail as is necessary), you will set both yourself and your customer up for success. 

Some useful links

• Creating an SLA
• Very generic SLA template