Designing a Co-Managed Support Desk

"Do I call IT, or do I call the IT company?" Marcus, on the receiving dock at Meridian Parts, has asked this out loud three times this month. He has a laminated card from the outside provider with a portal address on it. He has the in-house desk's e-mail address on a sticky note. And he has a label printer that has stopped printing labels. Last time he chose the portal. The ticket got a number and went quiet. The time before, he chose the desk, which forwarded it to the IT company. It got a different number and went quiet somewhere else. Each queue is confident the other one has it. Both are right, in the sense that neither does.

That is a co-managed desk in its natural state, and it is not a failure of anyone on either side. It is a failure of design. Nobody decided where the line between the two teams goes, which queue is the real one, or what happens to a ticket that crosses it. This is the fourth article in our Sourcing Support series, and it is about those three decisions. The three models themselves, and what each costs, are laid out in The Three Sourcing Models, Plainly.

It covers what co-managed means and the three ways to draw the split. Then come the one queue of record, one front door for the user, and the seam, written as a one-page handoff contract. We follow one ticket across it with times, then cover the outside engineers as scoped agents in your system and a weekly review. We finish with a design sheet to fill in before the contract is signed, or afterwards, which is more usual.

What Co-Managed Means

A managed service provider, or MSP, is an outside company that runs some or all of your IT for a recurring fee. That fee is usually shaped as a monthly amount per user or per device. A co-managed desk is one where the MSP runs part of the support function and your own people run the rest, by written agreement. Both sides serve the same users. It is not the MSP "becoming your IT department", and it is not your team buying the occasional hour of help. It is a split, and every split has an edge.

The edge is the seam: the line a ticket crosses when it moves from your side to theirs, or back. Everything that follows is about making that line visible, narrow and dull. A seam nobody has drawn still exists. It is drawn by whichever side gives up first.

Co-managed is the right model more often than either side expects. Most organizations have some support work only their own people can do well (they know how the business works). They also have some an outside team does better (they see the same storage fault forty times a year). The question is never whether to split. It is where, and how the halves talk.

The Three Ways to Split

There are three honest ways to draw the seam, and most real desks use one with a little of a second. By tier puts first contact and the quick fixes on one side and the hard problems on the other. By hours puts the working day on one side and nights and weekends on the other. By domain gives each side a category of thing: the desk, endpoints and identity to one, the servers, storage and network to the other. Each puts the seam in a different place, and each leaks in its own way.

Tiers need a definition before they appear in a table. L1, or first line, is the first human contact: triage, the known fixes, the twenty-minute problems. L2 takes what L1 could not finish, and L3 is the specialist or the vendor. Tiers have a pillar of their own at Designing Support Tiers.

Pick the split along the thing you lack. If you lack hours, split by hours. If you lack skills in a domain, split by domain. If you lack people at the front, split by tier with the MSP at L1, and accept what comes with it. In that case, the people who first hear from your users will not know your business. They will be rotated to another customer once they do. I think in-house L1 is the better default for any organization that can staff it. First contact is where knowing the business pays off. An MSP's L1 will learn your business eventually. So will their replacement.

One Queue of Record

The queue of record is the single system in which every support ticket exists, whichever side is working it. Decide this before you decide anything else, including the split. There will be two ticket systems in a co-managed arrangement, because the MSP has one and so do you. A ticket that exists in both is a ticket that exists in neither. One of them is the record. The other holds a copy.

The record should be yours. It is the thing you keep when the contract ends and the thing you report from. It is the thing whose number the user is given, and the thing a new provider inherits. What to Keep In-House No Matter What puts the ticket history on the list of things that stay in your hands whoever does the work. The queue of record is how that happens. If an MSP insists the record must be their system, ask what happens to the history when you leave. Then ask again, slowly.

A word of honesty here, because the queue of record is a product category and we are in it. QuerySolv sells help desk software, so discount our enthusiasm and check the reasoning on its own. The reasoning is this: the queue of record should run on your side of the fence. It should record every ticket action with a snapshot of the state and let nobody delete a ticket. It should let an outside engineer work inside it with limited rights. A self-hosted desk on your own server does the first three by construction. The fourth is a permissions question, covered below.

If you do not decide, both systems fill up. Each side forwards to the other by e-mail, and each forward becomes a new ticket with a new number. The user ends up holding two numbers for one printer. The ticket that went to a portal that went to a queue that went to a person in another time zone is not a joke about MSPs. It is a description of a ticket with no queue of record.

One Front Door, Always Yours

The user should have exactly one way to ask for help. And it should be yours: your address, your form, your phone number, your chat. Do not hand users the MSP's portal address, even when the MSP will do most of the work. The user should not need to know which side of the seam their problem belongs to. A label printer that is really a switch port is still, from the dock, "my printer".

Routing is a triage decision, and triage is yours, because triage is where knowing the business gets used. When the user calls one place, every ticket enters the queue of record at birth with one number. In that case, the handoff happens inside the system rather than inside the user. Without one front door, users route themselves. The guess is wrong about a third of the time because the seam is not visible from the warehouse. The laminated card is the most durable part of most MSP onboardings, and the first thing to take back.

The MSP will usually propose their portal as the front door, because their SLA clock, their reporting and their billing all start there. That is a fair thing for them to want and the wrong thing to agree to. Give them a feed instead: a department of their own in your queue, a mailbox copy, or a hook from your system to theirs. That way, their tools see the ticket without owning it. The contract measures that make their clock start when it should are in Working With an MSP Without Losing the Plot.

The Seam: A Handoff Contract on One Page

The handoff contract is a short written agreement about what happens when a ticket crosses the seam, and it fits on one page. It has four parts: the marker that says who has it, the pick-up time, the update rule, and the handback. Write it with the MSP, keep it in both runbooks, and attach it to the service contract as a schedule.

• The marker. One visible thing on the ticket says which side holds it. If your tool lets you add a status, add one. If its statuses are fixed, the marker is the assignment to the MSP's department or to one of their named agents. In that case, a saved view shows every ticket on their side. Nothing else means "yours now".
• The pick-up time. The receiving side acknowledges inside the ticket within a stated time. Thirty minutes in business hours for anything above the lowest priority is a reasonable start, and two hours after hours. Acknowledgment is a note from a person, not an automatic receipt.
• The update rule. Whichever side holds the ticket updates the user at the interval the priority demands, inside the ticket. That way, the other side can see it without asking. Silence past the interval is a breach whoever holds it.
• The handback. The ticket comes back with a note in a fixed shape: found, changed, left to do. The in-house desk, not the MSP, confirms with the user and closes. The user should hear the ending from the place they told the beginning.

The fixed shape matters because a handback note that says "resolved" tells the desk nothing it can say to the user. It tells the desk nothing the knowledge base can keep. Three headings take the engineer ninety seconds and save the desk a phone call. The note is also the only place the MSP's knowledge enters your system.

Without a handoff contract the seam is worked by courtesy, which means by whoever is nearest, which means inconsistently. Tickets sit at the seam with no owner and no clock, and the delay is nobody's fault, which is the worst kind.

One Ticket Across the Seam

Here is the contract working, on a Tuesday at Meridian Parts, which splits by tier. Dana and Sam run the in-house desk and take every first contact. The MSP's engineers take servers, storage, backup and the network. At 09:12 Lena in accounts e-mails the desk: the finance file share has been slow for everyone in her office since the start of the day. Ticket 7731 is created at 09:12, and Lena has the number by 09:13.

Dana triages at 09:20. Five people affected, a month-end run at 16:00, so priority High. Two quick checks rule out Lena's machine and the office switch. At 09:26 Dana assigns the ticket to the MSP's department, adds an internal note listing what she checked, and replies to Lena: "This is with our infrastructure engineers. I'll update you by 11:30 either way." Tomas at the MSP picks it up at 09:41, nineteen minutes after the handoff and inside the thirty the contract allows. His first note goes into the same ticket.

Tomas finds a snapshot job that overran into the working day and is keeping the volume busy. He stops it at 10:35 and confirms the share is responsive from two machines. He hands back at 10:50 with a note in the agreed shape. It says found (snapshot job overrunning from 06:00), changed (job moved to 02:00 and its window capped), left to do (none; check again tomorrow at 08:00). Dana sees the handback in her view, checks with Lena at 10:58, and Lena confirms at 11:05. Ticket 7731 closes at 11:10 with one number and one history, after one hour and fifty-eight minutes. Of those minutes, nineteen were spent at the seam. Lena never learned which side fixed it, which is the point.

Permissions and Access

The MSP's engineers should work as agents inside your queue of record. Each should have a named account and only the access their side of the split needs. Scoped means limited to the department or departments they work, with nothing elsewhere and no rights over the system itself. This is the only arrangement under which a ticket crosses the seam without being retyped. It is the one that keeps the whole history on your side when the contract ends.

Scope the obvious things first. Their accounts see their department's tickets and the ones assigned across to them, not the finance department's requests or the human-resources form. They cannot change mail settings, create agents, or edit the SLA rules. Nobody can delete a ticket, which in a well-made tool is not a permission but a fact. QuerySolv does this with departments that are really separate, each with its own form, mailbox and SLA rules. It has twelve granular permissions per agent with four presets from Trainee to Senior. That way, an MSP engineer can be Senior in Infrastructure and nothing at all in Finance. Whatever the tool, the shape is the same: the outside team is inside the system, and the system knows which part is theirs.

Account hygiene is part of the design. One named account per engineer, never a shared login called "msp". The MSP tells you the day an engineer rotates off your account, and the account is disabled that day. Put the obligation in the contract, because it will not happen out of politeness. Review the list of outside accounts monthly. A shared login named msp is a login named nobody, with the password of everybody. Access to servers, the directory and the firewall belongs to the identity decisions kept in-house whatever the split. The rule there is the same: named accounts, least privilege, a date on which each one ends.

The Weekly Seam Review

The seam review is fifteen minutes a week, one person from each side, looking at three lists. First, every ticket that crossed the seam this week and how long it waited before pick-up. Second, every ticket that bounced: sent across and sent straight back as the wrong side's problem. Third, every ticket older than a week on either side, with its next action. Then one change, decided together, and written down.

Keep three numbers from it. Seam wait is the median time from handoff to pick-up, and it should sit well inside the contract's pick-up time. Bounces per week should be near zero; each one is a row missing from the design sheet. Tickets at the seam past the pick-up time should be zero at the moment of the review, and if not, the review starts with those.

Rising seam wait means the split is wrong or the MSP has not staffed it, and either way it is a contract conversation. Rising bounces mean the domain lines are unclear, and the fix is a sentence on the design sheet, not a meeting. The monthly review in the MSP article is about the contract; the seam review is about the operation. And the seam review is the one that stops Marcus's printer from being nobody's. I have reconciled two queues by hand. Once. It is the kind of afternoon that produces design documents.

A Short War Story: Two Queues at Kestrel Payroll

Kestrel Payroll ran a co-managed desk for six months with two queues: their own for the in-house desk, and the MSP's portal for infrastructure. Handoffs went by e-mail, and every e-mail became a new ticket at the far end with a new number. Priya, the desk lead, reconciled the two systems before the first contract review. She found forty tickets that each side believed the other owned, the oldest fourteen weeks old. They included a certificate renewal that had been quietly approaching its date from both directions. Nothing had broken yet. The next month the MSP's three engineers became scoped agents in Kestrel's queue. The portal address came off the laminated cards. And the forty tickets were closed inside two weeks, mostly by asking the user whether it still mattered. The reconciliation after that found nothing to reconcile, because there was only one list.

The Co-Managed Design Sheet

The design sheet is one table with a row for every support function and six columns. The columns are the function, who performs it, who owns it, which queue it lives in, how it crosses the seam, and how often it is reviewed. Performed and owned are different columns on purpose. The MSP can perform backup restores. You own the backup, in the sense that you decide the policy, hold the record, and answer for it. The table below is Meridian Parts' sheet for a split by tier with in-house L1. Replace the contents, keep the columns.

Fill it in with the MSP in the room, before signing if you can, and in the first month if you cannot. The rows that cause an argument are the rows that would have caused a lost ticket. Review it at every renewal and whenever a bounce reveals a function nobody had written down.

Marcus has one address now, and it is the desk's. The laminated card says "IT" and nothing else. The printer problem that is really a switch port gets one number and comes back fixed with a note that names the port. He does not know that an engineer forty miles away did the second half of it. He only knows who to call, which is the one thing a co-managed desk has to get right before anything else.

Frequently Asked Questions