How to Craft Contracts, SLAs and Master Services Agreements for MSPs

msp-contract-agreement-big

You might think the root of MSP revenue is services, and that is true. But it is contracts that define these revenues and, properly written, ensure the money you earn keeps rolling in on a regular basis.

In fact, contracts are a cornerstone to any thriving MSP, serving many essential functions, including serving as a bond between client and provider. As such they should be treated and crafted with care.

Mastering Master Service Agreements

Many MSPs prefer a Master Services Agreement (MSA), which is a more detailed style of contract. Because MSAs tend to be highly technical, some half of these contracts are prepared without help from an attorney, according to the MSP Alliance. The main issue is the cost of legal counsel.  However, MSPs sometimes believe these MSAs are good to go because the MSP professionals who wrote them understand their business and technology.

But a good MSA also covers many legal issues not normally dealt with in simpler contracts – which is another reason legal oversight is critical.  These legal issues are far beyond purview of MSP staffers.  Consequently, whether it’s a simple contract or a richer Master Services Agreement, a lawyer and an experienced accountant should take a deep look at the documents before any signatures are placed.

In addition, MSAs and Service Level Agreements (SLAs) don’t just help the relationship run more smoothly ─ they can be a key part of the sales process. That’s because they should detail for the clients the precise value they will obtain from your services as well as your commitment to deliver them.

Contracts such as MSAs are also a key way to build and sustain revenue, and increase the value of your business. “The contracts an MSP has with its customers represent the primary component of the business’ value. The reason the contracts are so vital is the value of the business is determined by some multiple of the monthly recurring revenues,” wrote attorney Robert J. Scott in A Legal Guide to Managed Services. “Strong monthly recurring revenues generated under sound contracts are the key ingredient of business valuation.”

Scott & Scott detailed key items that should be in the MSA’s Statement of Services, including:

  • “Term of Agreement
  • Holiday Availability
  • Proprietary Rights
  • Intellectual Property Rights
  • Independent Contractor
  • Client Covenants
  • Insurance
  • Taxes
  • Non-Solicitation
  • Warranties
  • Limitations of Liability
  • Termination of the Agreement
  • Integration Clauses”

Here is one example of a provision that could or should be in your MSA, according to the law firm:

MSP will provide the following services:

  • Perform necessary remediation steps associated with the daily alerts and tickets
  • Prepare and implement a maintenance checklist.
  • Make recommendations based on weekly reports
  • Review and maintain all network related documentation
  • Review monitoring scripts/tools required for daily review and make recommendations for improvements”

The Importance of a Rigorous SLA

SLAs are the other key contract an MSP may have with a client. Because the MSP is committing to a particular level of service, and penalties are attached, these contracts should, obviously, be well thought out.

Partner advocacy organization CompTIA agrees. “One of the most contentious issues in managed services is availability. No matter what you think the verbal agreement was, don’t be surprised if the customer later develops a different understanding about your availability. Maybe they’ll want 24/7 support, or have unrealistic expectations about response and resolution times,” CompTIA explained. The only answer is a contract that clearly establishes SLAs and protects both parties.

Meanwhile, here is a quick legal SLA checklist from Robert J. Scott:

“There are a number of ways to calculate a service level for purposes of an SLA. Successful availability provisions will include:

  • The definition of availability, including any exclusions
  • The time period that will be used to measure availability (e.g., monthly, quarterly, etc.)
  • The method in which the availability will be calculated, and what, if any computers will be excluded from the calculation of availability
  • The percentage of availability the MSP is promising
  • Consequences for availability failures
  • If monetary credits are available for availability failures, the method by which the credit will be calculated and the maximum credit available for the applicable time period”

May the “Force Majeure” Be With You

Projects are not always 100% predictable. You could make a good faith effort to complete a project, and have the effort delayed through no fault of your own. This, in legal terms, is called “force majeure” and if your contract has this provision, you should still be paid for the work despite the unforeseen delay. Of course, the best approach is to keep the client in the loop –they probably want the work done at least as much as you.

Protecting Your Intellectual Property

You may not realize just how much of your intellectual property ends up in clients’ hands. It may be as simple as scripts to drive automation, or larger pieces of software your team has developed. Some of these items could, or may already, be patented.

To protect this, the contract should specify that that intellectual property belongs to you, and you alone.

Protecting Confidentiality and Trade Secrets

The same protection is critical for trade secrets such as pricing, discounts, SLA terms, warranties, and special technologies. Your contract should include a non-disclosure clause to protect these secrets. And since fair is fair, you should consider a similar clause protecting client confidentiality if asked.

CompTIA Lends a Hand

CompTIA has significant resources to help service providers with contracts, with some free and others, such as contract templates, available to registered or premium members.

 The partner organization also has a useful free overview of why you should use contracts (many MSPs don’t and usually come to rue that decision) and the basics of how to go about it in How Written Contracts can Help your Business.

CompTIA argues that contracts are an essential protection for MSPs, and should be dispensed with only in limited circumstances – such as ultra-simple engagements. Partly, this is because of the implied contract in doing work for another party. “Most people believe there is no contract if they didn’t sign something. But there is. It is called an oral agreement and they are just as enforceable as written ones. The problem is you won’t necessarily be the person deciding what the terms of an oral contract are, if there is a dispute. A judge or jury will do that for you. The question is:  do you really want to accept that risk?” the group asked.

Another issue is that if you don’t craft a contract, your customer may do so anyway in the form of a PO. “You may have been in the position of agreeing to provide services to a customer, and shortly thereafter the customer sends you a purchase order. You turn it over and notice a full page of legal terms on the back,” CompTIA mused. “You now have a written contract whether you wanted one or not. It’s highly unlikely the terms on the PO are to your advantage. They were drafted from the customer’s perspective. But if you had a written agreement it wouldn’t be an issue.”

Such a contract, crafted by you and representing your interests, can negate and void the items listed in legalese on the client PO.

A contract should not be one-sided. Instead it should treat clients with respect, spelling out what you are responsible for, where those responsibilities end, and do so in a multifaceted way.

Here are some areas CompTIA suggests your contracts cover.

  • “If you install software how long is it expected to function?
  • If you do break/fix work, how long will the equipment remain up and running?
  • What level of service are you guaranteeing? Are you promising absolute perfection, or merely that the work will be in accord with generally accepted IT standards?
  • What happens if the customer starts doing things that you feel should void the warranty? For example, what about customers who decide to tinker with software or hardware you installed, and wind up making a problem worse?”

How to Say Goodbye

Breakups can come from either side, and either way you want to be protected. Sometimes you are the one to call it quits, and you want to make sure there are no negative repercussions. Your contract should specify under what circumstances you can break it. Maybe the client is slow in writing checks or refuses to pay, implements their own conflicting technology, or has employee behavior that works against your efforts. Or perhaps they demand work that isn’t called for in the contract.

On the hand, you also need to be protected if the client breaks the contract. They may back out before the duration of the contract is complete, and you are holding costs related to the entire duration. Or maybe you started a major project, made investments, and the contract was broken before the services were rendered and paid for.

Here CompTIA weighs in. “You’ve just booked new business. Say you have to make some up-front investments before you can begin the work. Maybe you need to buy equipment or perhaps license new software. Maybe you need to hire additional help, or get some additional training. What if you make these investments, and then receive a call from the customer stating he’s decided to go with another provider. You can’t demand payment for the work because you didn’t do it yet,” the organization argued. “What are your options? Without a written contract there are not many. A written contract will specify what expenses you are entitled to be compensated for. More importantly a written contract gives the road rules for how, why, and when a party is allowed to back out of a deal.”

Don’t Make These Mistakes

Gary Pica, an MSP veteran and leading pundit, has been through countless client engagements, and highlights mistakes you must avoid. The first is setting the wrong price. “If you incorrectly price and package your services, there are going to be negative ramifications for your employees and the client you’ve just signed. You may over-promise on what your employees can actually deliver, or you could end up in a situation where the client isn’t getting the level of service they were expecting,” Pica, president of TruMethods, an MSP consultancy, wrote.

Pica also believes that less is more. “Transparency is key to avoiding future lawsuits that may arise from broken MSP business agreements. The longer and more complicated your agreement is, the less your client is going to trust you. Don’t create a 10-page agreement that deals with a variety of items that will never happen or that you can’t control,” Pica argued.

While Pica advises a bit of brevity, don’t take this too far. “Sometimes an agreement covers a lot but misses a few critical items for protecting your MSP. The most important role of a business agreement is to safeguard your MSP from liability in the event that things go wrong, so including a liability clause is essential. Protecting your employees is also important, so it’s a good idea to formulate a non-compete clause. Start with the most import items to protect you and your business,” Pica wrote.

Which Brings Us Back to the Beginning

I started this blog by highlighting how essential contracts are to the ongoing health of your MSP.  Crafted well, contracts are the building blocks for successful, ongoing business engagements with your growing list of clients.  Clear, well-documented expectations on both sides mitigate confusion on service levels, and point to solutions when problems, inevitably, arise.

Contracts are not the place to scrimp – make sure your contracts, MSAs and SLAs are carefully thought out, and fully vetted by legal and financial counsel.

If you’re interested in other building blocks for a successful MSP, check out Kaseya’s whitepaper, “Your Roadmap in an MSP 2.0 World.”

 

dougbarney

Doug Barney was the founding editor of Redmond Magazine, Redmond Channel Partner, Redmond Developer News and Virtualization Review. Doug also served as Executive Editor of Network World, Editor in Chief of AmigaWorld, and Editor in Chief of Network Computing.

Leave a Reply

Your email address will not be published. Required fields are marked *