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.
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:
In order for your SLA to provide this protection effectively, a trained legal professional should check its content.
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.
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.
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:
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.
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.
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.
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 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 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.
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.
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.
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:
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.
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?
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.
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.
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.
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.
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.