Working With an MSP Without Losing the Plot

Ticket 48213 went to the portal on the third of the month. It got a number, and an e-mail that said the number, and a line that said someone would be in touch. Nobody was. Lena, who had raised it because the finance export failed every Monday, worked around it for three weeks by running the export on Tuesdays. On the first of the next month the service report arrived. It showed every ticket responded to within target, 97 percent resolved within target, and ticket 48213 marked resolved on the twelfth. Lena had not been asked. The export still fails on Mondays.

Nobody in that story did anything wrong, which is the problem. The engineer closed a ticket that had gone quiet. The report counted what the contract told it to count. Lena found a workaround, because that is what people do. The contract measured a portal, and the plot is the person. A managed service provider, or MSP, is an outside company that runs some or all of your IT for a recurring fee. And this article is about working with one well: not fighting it, not trusting it blindly, and not letting the plot wander off into a monthly report. It is the third in our Sourcing Support series. If you are still deciding whether to use an MSP at all, start with The Three Sourcing Models, Plainly.

It covers the relationship stated plainly, then SLAs that mean something, with the measures the MSP will propose and the ones to add. Next come the ticket handoff and which queue is the queue of record, who tells the user, and keeping your own copy of the knowledge. Then we cover the monthly review in fifteen minutes and the escalation path on both sides. We finish with a war story from Acme and a review sheet to copy.

The Relationship, Stated Plainly

The MSP works to the contract. Not to your intentions, not to the deck, not to the warmth of the kickoff meeting. This is not cynicism; it is how a company with forty customers stays fair to all forty. The good providers are good because they are disciplined about the contract. That means the contract has to say what you actually need, in words that can be measured. Otherwise you will get something else, measured beautifully.

Three things follow. First, the engineers are peers, doing the same job you do with less context. Treating them as adversaries costs you the only people who can help. Second, the account manager's job is the renewal, which is a fine job, but it is not the same as your job. The word "synergies" in a meeting is a cue to look at the numbers. Third, every gap between what you need and what the contract says is a gap you will pay for in user patience. So the work of the relationship is closing those gaps in writing, one review at a time.

If you have not yet decided which functions stay yours whatever the contract says, read What to Keep In-House No Matter What first. This article assumes the five things are yours and gets on with the rest.

SLAs That Mean Something

A service level agreement, or SLA, is the written promise of how fast each step of a ticket happens. The MSP will arrive with a standard one, and it will be measurable, achievable and almost entirely about their portal. Three measures mean something to a user, and they are the three to put in.

Response to a human means a named person has read the ticket and replied. The reply says what they understand the problem to be and when the next update will come. The portal's automatic acknowledgment is not a response; it is a receipt. Ask for the target to be measured from the ticket's creation to the first human reply. And ask that the reply name the engineer and the next update time.

Resolution confirmed by the user means the ticket counts as resolved when the user says so. Or it counts after a stated number of working days of silence following a resolution note that asks them. An engineer marking a ticket resolved is a claim, not a resolution. Measure the claim and you get a desk that is excellent at claiming.

Update intervals are the longest a ticket may go without the user hearing something from a human, whether or not there is news. One working day is a reasonable interval for ordinary tickets. Without it, a ticket that is waiting on a part, a vendor or a change window goes silent, and silence is what users remember. Ticket 48213 was silent for three weeks and met every target it had. It did not have this one.

Targets for priorities, business hours and what counts as a breach belong to the SLA design pillar. The point here is narrower: whatever the numbers are, make sure they are attached to the person, not the portal.

The Measures They Will Propose, and the Ones to Add

Here is what the standard proposal usually measures, what each measure actually counts, and what to add or replace it with. Use it in the first contract conversation and again at every renewal, because standard SLAs regrow between renewals like hedges.

None of the proposed measures is dishonest. Each one is easy for the provider to count from inside their own tool, which is why it was proposed. The replacements are harder to count, which is why you will have to count some of them yourself. The monthly review later in this article is where that happens.

The Ticket Handoff and the Queue of Record

The queue of record is the one system in which every ticket exists, whoever is working it. There are three ways to arrange it. Your system, with the MSP's engineers as agents in it, which is best. Their portal, with your desk working inside it, which is workable if you have read access to everything and a quarterly export. Both, with tickets copied between them, which is the arrangement most contracts default to and the one that loses tickets at the seam.

A handoff in the queue of record is a status change, not a new ticket. Your desk triages, decides the ticket is for the MSP, and writes a handoff note. The note covers what the user reported, what was tried, the impact, and the next update promised to the user. The status changes to "with provider". The MSP's engineer works it, writes notes in the same ticket, and sets it back when the fix is in. Your desk confirms with the user and closes. One number, one history, one place to look when someone asks where it is.

If two systems are unavoidable, make the copy a rule rather than a habit. In that case, the MSP's ticket number is written on your ticket within fifteen minutes of raising it. And your ticket number is in the title of theirs. It is not elegant. It is the difference between losing tickets and merely duplicating them, and duplication is the cheaper failure.

This is the one place in the series that touches a tool decision. So: QuerySolv sells help desk software, and we would like your queue of record to be ours. Weigh that before trusting the next claim. A system that gives the MSP's engineers their own department with scoped permissions is the shape to look for. It must also record every ticket action and never let a ticket be deleted. QuerySolv has twelve granular permissions with four presets and keeps that record. Any tool that does the same will do the job.

Who Tells the User

Your desk tells the user, always, even when the MSP is doing the work. The user has one front door, and it is yours. The MSP's updates are written for the ticket, in the vocabulary of the ticket. And a user who reads "awaiting change window for port reconfiguration" learns only that something is awaiting something.

Here is the handoff with a clock on it. Marcus at the Northgate Retail Harbor Street store calls the in-house desk at 09:12 on a Tuesday: the till will not take cards. Sam raises ticket 7310 at 09:14 and sends Marcus the receipt. At 09:20 Sam has checked the till and the store's connection. The store network is the MSP's under the contract, so at 09:22 he writes the handoff note and sets the status to "with provider". At 09:25 he e-mails Marcus: "This is with our network provider; I will update you by 10:30 either way." The MSP's engineer, Tomas, picks up the ticket at 09:41, well inside the one-hour human-response target. He notes at 10:15 that the store switch is logging port errors and he is replacing the configuration. At 10:50 Tomas sets the status back with "config replaced, cards tested from here". Sam calls Marcus at 10:55, Marcus runs a card, and at 11:00 the ticket is resolved. Marcus confirms at 11:05 and it closes. One hour and fifty-three minutes, three messages to Marcus, all of them from Sam.

If the desk is fully outsourced and there is no Sam, the contract names who talks to the user, in what words, and how often. The automatic acknowledgment does not count. A user who hears from nobody assumes the worst. A user who hears from two people with different stories assumes something worse than that.

Keeping Your Own Copy of the Knowledge

Every fix the MSP makes is documented in your knowledge base, not only in theirs. The clause reads: "fix notes for every resolved ticket are recorded in the customer's knowledge base within one working day of resolution, in the customer's template." The template is short: symptom, cause, fix, and the ticket number. Ninety words is plenty.

Keep your own copy because the knowledge otherwise accumulates at the vendor and leaves with the contract. That is the single largest hidden cost of the MSP model and the reason the previous article exists. Keep it also for a nearer reason: the third time the store till rejects cards, the engineer on shift will be someone new. And the fix is either in your knowledge base in ninety words or it is two hours of rediscovery.

Make it cheap to comply. Give the MSP's engineers write access to the agents-only part of your knowledge base. That way, they can record the ugly version without worrying about users reading it. Read what they write once a week; correcting a draft takes a tenth of the time writing it does. A knowledge base nobody reads is a diary. A knowledge base the provider writes and you read is the handover pack you will one day need, written in advance, by the people who know.

The Monthly Review: Fifteen Minutes, Four Numbers, One Change

The monthly review is fifteen minutes, four numbers and one change. Longer and it becomes a presentation; more numbers and it becomes a report nobody reads; more changes and none of them happen. The provider's service manager and your desk lead attend. The account manager may attend, and may not steer.

The four numbers are the ones from the SLA section. The first two are human response within target, as a percentage, and user-confirmed resolution, as a percentage. The next two are tickets that went past the update interval, as a count, and reopens, as a count. The age of the oldest open ticket is noted beside them. The provider brings the first two from their system. You bring the second two from yours, which is one reason your queue of record matters.

Here is Acme's review for one month. 212 tickets. Human response within target: 94 percent, flat. User-confirmed resolution: 71 percent, down from 78. Tickets past the update interval: 23, up from 9. Reopens: 9. Oldest open ticket: forty-one days, a printer lease question waiting on a vendor that nobody had chased. The one change: a rule that any ticket in "waiting on vendor" is chased by the engineer every three working days and the user told each time. Owner, the MSP's service manager; due, next review. The silence count was 6 the following month. Nobody made a slide.

The one change is the point of the meeting. Pick the number that moved the wrong way, agree one thing that would move it back, and name the owner. Check the agreed change first thing next month before looking at anything new. A review that produces no change is a reading, and readings are cheaper by e-mail.

The Escalation Path on Both Sides

An escalation path is the written list of who is told, in what order, when a ticket is not moving as the contract says it should. It has names and direct numbers, not role titles and shared mailboxes. And it has triggers. A high-priority ticket not acknowledged by a human within thirty minutes goes to the lead engineer. If it is not resolved within four hours, it goes to the service manager. A second miss in a month goes to the director on each side.

The account manager is not the escalation path. That role exists for the renewal. An escalation routed through a renewal arrives as a relationship problem rather than an engineering one. That is slower and more expensive to fix. The path needs an engineer's number on it. A relationship problem is what you get when the engineering problem has waited long enough.

The path runs both ways. The MSP needs to be able to escalate to you when a user will not take the reboot that fixes it. It also needs to do so when a change needs a decision only you can make. It also needs that route when your named approver has not answered the access request in two days. Give them a name and a number too. A provider that cannot reach you when stuck will stop being stuck in the way that costs you least, which is to close the ticket. Ticket 48213, in a way, was escalated. It was escalated to the monthly report.

A Short War Story: A Year of Green at Acme

Acme's MSP met every SLA for a year. The monthly reports were green from the first page to the last. In the same year the users rated the desk five out of ten. The comments said the same three words in different orders: nobody tells me. Dana, who coordinated IT at Acme, read the contract properly for the first time at renewal. She found that first response was measured to the portal. The automatic acknowledgment counted, and a ticket could sit for two weeks after it with every target met. She ran a one-question survey for two months to get the number in writing. She took it to the renewal with the three measures from this article. And the renegotiated contract measured human response, user-confirmed resolution and a one-working-day update interval. The ratings rose to eight within a quarter. The engineers were the same people throughout; nobody had been slacking and nobody was replaced. The measure had changed what the queue was for.

I have been on Dana's side of that renewal. The hardest part was not the negotiation. It was admitting that the green reports had been telling me what I asked them to.

The Monthly MSP Review Sheet

Here is the sheet. Print one per month, fill it in before the meeting, and keep the stack. Twelve of them in a row are the only renewal preparation you will need.

MONTHLY MSP REVIEW          Month: ________   Provider: ______________
Attendees: ____________________________   Fifteen minutes. Four numbers. One change.

THE FOUR NUMBERS                      This month   Last month   Target   Trend
1. Human response within target        ______ %     ______ %    ____ %   up / flat / down
2. Resolution confirmed by the user    ______ %     ______ %    ____ %   up / flat / down
3. Tickets past the update interval    ______       ______      0        up / flat / down
4. Reopens                             ______       ______      ____     up / flat / down

Oldest open ticket: #________  ____ days  with: us / provider / user / vendor
Escalations this month: ____   Reason for each: _______________________________

WHAT USERS SAID (three comments, verbatim)
  - ___________________________________________________________________
  - ___________________________________________________________________
  - ___________________________________________________________________

KNOWLEDGE
Fixes documented in our knowledge base this month: ____ of ____ resolved

LAST MONTH'S CHANGE: ___________________________   [ ] done  [ ] not done
Effect on its number: ______________________________________________

THE ONE CHANGE FOR NEXT MONTH
What: _________________________________________________________________
Which number it should move: ____   Owner: ____________   Due: __________

The sheet has no room for a slide, which is deliberate. Ticket 48213 would have appeared on it in the first month, as one of the tickets past the update interval. Lena would have been running her export on Mondays by the second. That is the whole method. Measure the person, keep one queue, keep your own copy of what was learned, and meet for fifteen minutes to change one thing. The plot stays where you can see it. A co-managed arrangement adds a seam to all of this, and Designing a Co-Managed Support Desk is about the seam.

Frequently Asked Questions