On Managed Service Providers

Many companies have abandoned the notion of internal IT departments and competency centers in favor of third-party providers. This ranges from onsite and remote help desk support to network administrators and application support for both novice and advanced users. Indeed, MSPs constitute most of the vendors I manage every day. I've had the opportunity to interview (and manage relationships with) dozens of these businesses, and have some boxes to check when it comes to selecting and maintaining the right partners.

Master Service Agreement

The first thing I review is their Master Service Agreement. In it, I'm immediately scanning for a reasonable description of what's in scope, what they can't/don't touch, and how they plan to support my organization. This blanket agreement should include Service Level Agreements ("SLA"), billing details, and what constitutes regular support versus "a project."

I find it perfectly acceptable for things that are bigger than, say, four hours to be considered a project to which a resource needs to be assigned to complete the work; the obvious caveat is that the issue can become "planned work" instead of a higher-urgency issue that needs immediate attention.

Service Level Agreements

Nothing gets me more than the phrase, "initial response time." Saying that, "All issues will be responded to within 30 minutes," as your only SLA is tantamount to representing that you have a monkey in a cage instead of an email auto-responder. What you will want is representation of not just initial response (and classification) of a reported issue, but also escalation procedures, resolution timeframes (though there will be many caveats on this), and communication expectations.

The best vendors have something like the following:

• Initial response and categorization: Should be minutes, not hours, and never the only time-based metric. (See "Resolution timeframes" below.)
• Escalation procedures: Should include tiers of support which vary according to complexity and impact. This can be aligned with the issue ("Priority 3, 2, 1") or the staff they assign ("Level 1, 2, 3"), but either way should be formally defined.
• Resolution timeframes: Your tolerance for waiting may be different than mine. If you want everything resolved within the hour like its the most important issue of the day, you're in for disappointment or, potentially, an appropriately huge bill. You should be provided some basic timeframes for various issue types, with the understanding that levels of complexity may impact these timeframes. That - complexity - is a tricky word. That's why having example issues is important, for example, "Change network password: immediate, Email login: within hour, Remote software installation: next business day, Troubleshoot application issue: Varies," is a far cry better than, "Will respond within the hour." The latter is unmeasurable, which we'll get into in a bit.
• Communication policy: You must have the option of making your issue reporter aware - to the minute - when the issue has changed status. Escalation to different personnel (whose internal departments may have their own SLA, by the way), results of investigation, and steps taken to resolve should be available to you and your staff.

Security

Get simple explanations of the things they do to proactively secure your organization's data and/or systems. Access to a risk audit report isn't too big of an ask, and is typically provided under special NDA. If your MSP doesn't have even a basic security policy, take Monty Python's advice and promptly run away.

Ticketing and Reporting

Your MSP needs to have a system for tracking and reporting, not a monitored inbox. Period. (I know it sounds de rigueur, but if you don't ask you don't know.)

Each month, you should expect a report that outlines much or all of the following:

• Initial response time
• Average time to resolution/repair
• Ticket counts by class or priority
• Percentage of tickets requiring escalation of any kind

In addition, if your MSP is charged with, say, the health of your workstations or systems, get health reports for every managed asset. Again, it's a light lift and they can likely automate this standard request.

Billing

This is where it gets complicated, and harkens back to reporting. Some MSPs charge a flat fee for the services contracted under their MSA. Most, however, itemize their fees particularly when specific assets are being supported instead of just "users."

Billing for December in the November bill that's due by 11/15 is, well, problematic. I've gotten around this quagmire by having a point person in charge of tracking all asset on-/off-boarding and a badger in accounts payable comparing month-over-month bills.

In practice, if an asset appears on the schedule of covered items during that month, it's billable for that month. If you want to get into the business of pro rata billing, be my guest - frankly, if you have that many changes every month to the point that those several days matter, you might have the wrong support model. In general, I recommend working with organizations that can post-bill for months, flipping the worst-case above to billing for November on 12/1.

If your MSP summarizes some line items, make sure to get a monthly "breakout report." For instance, a line like this...

167 PC Workstations...............  $40  $6,680

...deserves something to which you can compare your own asset list. They should match 100% of the time for the billed period.

Summary

There are lots of gotchas in this space, and the endless contract clauses that are only good for the MSP could take several blog posts to begin to even summarize, but the above should make for good conversation starters before you start interviewing the most important people: a few of their customers.