Managed Services Agreements Coverage Cheat Sheet (DRAFT) by [deleted]

Developing a managed services agreement (MSA) is often the first thing that a technology solution provider (TSP) does to prepare for delivering services to a prospe­ctive client. It helps you:
1. Identify what hardware, users, vendors and services are covered, as well as those that aren’t
2. Clearly document the managed service roles and respon­sib­ilities for the client and the TSP
3. Accurately represent the clients’ existing enviro­nments
4. Define enviro­nmental prereq­uisites for service
5. Establish a baseline enviro­nment
6. Create a framework to ensure profit­ability

The agreement should embody your service level agreement (SLA), priori­tiz­ation process, response times, termin­ation clause, limitation of liability and a definition of support tiers and your service desk escalation process. Plus, it should reflect your labor rates or fees for requested services that fall outside of flat-fee support.

Here are the top 11 things you should clearly outline in your managed services agreem­ents:

1. Services. Brass tacks, what is your client getting? Managed email security, teleco­mmu­nic­ations, just network security? Clearly explain what’s included in their offering (and examples of what’s not).
2. Respon­sib­ili­ties. If Johnny Recept­ionist pulls an Office Space on his boss’s printer, that shouldn’t be your respon­sib­ility to fix. Willful destru­ction of property shouldn’t be covered, but general wear and tear should be. Define what each looks like in your agreement.
3. Availa­bility. Be realistic here. What can you actually provide? Less than 2 hours of downtime per month? Think about what your clients are averaging today when you set this expect­ation.
4. Perfor­mance. You can have 99.999% uptime, but if the machines are slow as mud, it doesn’t mean much. For contracts that pertain to hardwa­re-­as-­a-s­ervice, ISPs, operating systems and bandwi­dth­-heavy add-ons, set perfor­mance expect­ations.
5. Response. In a nutshell, how quickly can a customer expect to hear back from you after reporting an issue? Be sure to factor in your hours of operation. If you commit to responding to all requests within 10 hours, be sure to define those as business hours.
6. Priories. Define what consti­tutes a priority or work stoppage. Just because a printer is jammed doesn’t mean your tech should drop everything they’re doing to go fix it.
7. Guaran­tees. These can help convert an uncertain prospect into a customer, but make sure you can absolutely follow through on whatever you promise to deliver.
8. Servic­eab­lity. If your client’s data center is underw­ater, you’re most likely going to be unable to provide on-site service. Set expect­ations around what you classify as servic­eable.
9. Operation. Define your support and escalation proced­ures, as well as your policy for providing service outside normal coverage hours.
10. Resolu­tion. Response and resolution are two completely different matters. While you may respond immedi­ately, it’s not always possible to resolve issues right away. Define reasonable resolution windows you can commit to.
11. System Requir­ements. Document the minimum standards the enviro­nment must meet in order to qualify for services.