The Three Sourcing Models, Plainly

"We become your IT department." The sentence is on slide four of the deck, under a photograph of three people smiling at a server. The deck came with a proposal. The proposal came from your director. The director's note says "thoughts by Friday". You are reading it at 17:20 on a Wednesday, between a printer ticket and a password reset. And you have noticed something the deck has not. You are the IT department. The deck is proposing to become you.

That is not a reason to throw it away. Some organizations are better served by an outside company. Some are better served by their own people, and a good many by a mix. Which is right depends on things the deck cannot know: your size, your hours, and the skills you rent. It also depends on who, right now, knows how the business actually works. This article is the first in our Sourcing Support series, and it defines the terms the others use.

It covers the three sourcing models in plain words. It explains what each costs in three currencies (money, control and knowledge) and who each fits, with a worked example. It covers the hidden costs that never make slide four and the one question that decides more than cost. It also provides a comparison table for Friday. There are no prices in it. The shape of the bill matters more than the number, and the number changes every time you ask.

The Three Models, Defined

A sourcing model is the answer to one question: whose people run your IT, with whose tools, holding whose knowledge, under what contract. There are three honest answers. Everything else on the market is one of the three wearing a different name badge.

In-house means your people, your tools, your knowledge. Employees on your payroll answer the tickets. The ticket system runs on licenses you hold. The knowledge of how things work lives in your staff and, if you are disciplined, in your knowledge base. The contract is an employment contract. The risk is the familiar one: people can leave, and what they know leaves in the same car.

A managed service provider, or MSP, is an outside company that runs some or all of your IT for a recurring fee. Under the MSP model their people answer the tickets, usually through their tools (their portal, their remote-control agent, their monitoring). The knowledge of your environment accumulates in their heads and their systems. What you hold is a contract, which says what they will do and how fast. By default, the contract is the only part of the arrangement that is yours.

Co-managed is a split, usually by tier, by hours, or by domain. By tier: your people take the first line and the MSP takes the deep technical work, or the reverse. By hours: your people cover the working day and the MSP covers nights and weekends. By domain: your people run the desk and the MSP runs the servers, the network and the backups. Each split creates a seam, the place where a ticket crosses from one side to the other. The seam is where co-managed arrangements succeed or quietly do not.

The diagram shows the four things every model allocates, people, tools, knowledge and the contract, and whose column each lands in. Every cost in the next three sections is one of those four moving out of yours.

What Each Model Costs in Money

Money is the currency everyone argues about, usually about the wrong thing. The number on the proposal is a guess that will be revised. The shape of the bill is a fact that will not. Shape means what you pay for, what makes the bill move, and what is not on it at all.

In-house money is salaries, and salaries are fixed and lumpy. One administrator costs one salary whether the queue holds ten tickets or two hundred. A second administrator doubles the line in one step. Around the salaries sit licenses, training, and cover when someone is away, usually paid in overtime or in tickets that wait. The bill does not move when volume moves. It moves when headcount does.

MSP money is a monthly fee per user or per device, with a list of what the fee includes and a rate for everything it does not. The fee moves with your headcount, which finance departments like. The list of what it includes is shorter than the deck implies, which they discover later. Project work is billed separately. Every MSP proposal has a line called "out of scope". Budget for it as if it were in scope, because it will be.

Co-managed money is both shapes at once, plus a third cost that appears on no invoice: the time your people spend at the seam. Chasing a ticket that crossed over, explaining the warehouse network to a new engineer, sitting in the monthly review. Real hours, never itemized.

What Each Model Costs in Control

Control is the ability to decide something and have it happen today. It sounds abstract until the afternoon you need a firewall rule changed before the 16:00 payroll run. Then it is the only currency that matters.

In-house control is complete, and so is the responsibility. A change happens when you walk over to the person who can make it, who is sometimes you. Nothing stands between the decision and the keyboard except your own change process, which on a small desk is often a conversation. Nothing stands between a bad decision and the keyboard either. The firewall remembers.

MSP control is contractual. You can ask for anything. What you get is what the contract says, as fast as the contract says, by the route the contract describes. A request goes to the portal. The portal assigns it. The assignment waits for a change window, and the change window is theirs. None of this is malice. The MSP has forty customers, and the only fair way to serve forty customers is to serve the contract. The response is to the contract, not to your Tuesday.

Co-managed control is split, and the split needs writing down. Your side of the seam moves at in-house speed, theirs at contract speed. The rule to write first is who may change what. That is because the engineer who tidies up your group policy on a quiet Friday is helping. The help is what you will be explaining on Monday.

What Each Model Costs in Knowledge

Knowledge comes in two kinds. The first is how the technology works: joining a machine to the domain, clearing a stuck print queue, restoring a mailbox. It is portable, and any competent engineer brings it along. The second is how your business works. This includes which three accounts must never be touched and why the warehouse label printers have fixed addresses. It also includes who to call when the till at the Harbor Street store rejects cards. This kind is not portable. It is learned on your premises, one ticket at a time, and it decides whether a sourcing model works.

In-house knowledge lives in your people and leaves one person at a time. That is survivable if the desk writes things down. The one-person desk is the hard case, which is why the solo administrator has a pillar of this library to themselves.

MSP knowledge accumulates at the vendor and leaves all at once, on the day the contract ends. Every fix their engineers made and every oddity they learned about your network are in their ticket notes, their documentation system, their heads. So is every supplier contact they looked up. None of it is yours unless the contract says so, and the contract rarely does. I have never seen a contract end with the knowledge in the right place by accident.

Co-managed knowledge is split along the seam. The half on the MSP's side is the half you think about least, because it is the half that is working. The fix is one knowledge base, yours, where every fix lands whoever made it. What to Keep In-House treats this as the most important of five things, and I think that is right.

Who Each Model Fits

Four things about your organization decide the fit: size, hours, skills and regulatory posture. None of them is the number on the proposal.

Size sets the floor. Below about fifty users there is rarely enough work for one full-time administrator. The MSP model fits at that size because it sells a fraction of a person. Above a few hundred, the volume justifies an in-house core. The zone between, where one or two administrators need help but a third is not justified, is where co-managed arrangements come from.

Hours decide the shape of the help. If the business runs 09:00 to 17:30, one in-house desk covers it. If the warehouse starts at 06:00 and the last shift ends at 22:00, in-house cover means two shifts or one tired person. After-hours cover is the thing MSPs sell most honestly, because it is the thing hardest to staff with two people.

Skills decide what you rent. Skills you use every day (desktop support, accounts, the business applications) are cheapest in-house, because every day is a lot of days. Skills you use twice a year (a server rebuild, a firewall migration) are cheapest rented. That is because the person who does it twice a year for you does it twice a week for everyone else. Regulatory posture decides what you may not rent at all. If an auditor will ask who approved an access change, "our provider" is rarely an answer they accept.

Take Meridian Parts as a worked example. Head office and a warehouse, 140 users, the warehouse running 06:00 to 22:00, and Dana is the whole IT department. The queue takes about 190 tickets a month, eleven of them last month arriving after 18:00. Twice last year a server fault needed skills Dana does not have. Fully in-house means a second hire, which covers Dana's leave and the daytime volume. But it still leaves 06:00 to 08:00 and 18:00 to 22:00 to voicemail. Fully outsourced covers the hours and the server faults, at a monthly fee per user for 140 users. It moves the knowledge of the warehouse scanners and the carrier integration into someone else's ticket notes. Co-managed by hours and by domain fits. Dana keeps the desk, identity, the vendor list and the business knowledge. An MSP takes after-hours cover and the server estate. The seam sits at 18:00 and at the server room door. Eleven after-hours tickets a month and two server faults a year are exactly what an MSP is good at. Everything else is what Dana already does.

The Hidden Costs of In-House

The hidden cost of in-house is that it is cheap until the day it is not. A small in-house desk is one or two people, and one or two people are a single point of failure with a pension plan. Leave, illness, a plane, a better offer: each one takes the desk's capacity to zero or to half, with no contract to fall back on.

Cover is the cost nobody budgets. A two-person desk cannot send both to training or let one take three weeks. It cannot lose one without the other doing two jobs for months. The desk looks fully staffed on the org chart and runs at a person and a half for most of the year. The skills ceiling is the other hidden cost: an in-house desk knows what it has seen, and a small desk has seen less. The first time a thing happens, it happens slowly. Most of the expensive things happen once.

The Hidden Costs of an MSP

The first hidden cost of an MSP is the knowledge that leaves with the contract. The second is subtler, and it is the one that makes users unhappy while every number is green. The response is to the contract, not to you. Consider a ticket's journey. The user e-mails the MSP's address, which creates a ticket in a portal. The portal assigns it to a queue. An engineer in another time zone picks it up. The engineer has never seen your building. The engineer is competent and polite, and the ticket is acknowledged within the contracted hour. The user hears a number. The engineer does not know that "the scanner" means the one by bay three. The user does not know to say so. And the ticket takes four exchanges and two days to do twenty minutes of work. Every exchange met the SLA, the service level agreement, which is the written promise of how fast each step happens. The SLA measured the portal, not the person.

The third hidden cost is the tools. The ticket history, the documentation and the monitoring live in the MSP's systems. When the contract ends they are the MSP's to keep or to export, on the MSP's timetable. The onboarding deck has forty slides. The exit is one paragraph, on the last page. Working With an MSP is about getting the contract to say what you need, including the part about leaving.

The Hidden Costs of Co-Managed

The hidden cost of co-managed is the seam, and it is paid one ticket at a time. A ticket that crosses the seam needs a number on both sides and a status that says who has it. It also needs someone whose job it is to tell the user what is happening. A seam without those three things produces the sentence every co-managed desk learns to dread: "I thought that was with you."

Two queues make it worse. If your desk has a ticket system and the MSP has a portal, every crossing ticket exists twice. In that case, it has two numbers, two statuses and two ideas about who owns it. Neither side's report counts the tickets that fell between. The fix is one queue of record: a single system in which every ticket exists, whoever is working it. The MSP's engineers work inside it as agents holding only the permissions they need. Whose system that is matters less than that there is one. We sell help desk software, and QuerySolv's departments and per-agent permissions are built for this arrangement, so discount our enthusiasm. The split and the seam rules have their own article, Designing a Co-Managed Support Desk.

The Question That Decides More Than Cost

The question is: who knows how the business works, and where is it written down? Not the technology. The business. When the warehouse scanner at bay three dies at 06:40 on a dispatch day, somebody has to know which supplier holds the support contract. They also have to know what the contract number is and that the spare is in the cabinet by the loading door. And they have to know that the dispatch system needs restarting after the swap. That knowledge was learned on your premises over years, and it is the only knowledge that cannot be hired.

Ask it of each model, honestly, and choose the one in which that knowledge stays in your hands, in writing, whoever does the work. In-house, that means Dana writing things down. With an MSP, it means a contract that brings the knowledge home. Co-managed, it means one knowledge base for both sides of the seam. If a model cannot promise it, the fee is irrelevant. You would be paying someone to forget your business on your behalf.

A Short War Story: What Northgate Retail Got Back

Northgate Retail ran forty stores and outsourced its whole desk for three years. The MSP's technicians were excellent; the store managers knew them by name and said so. When the contract ended and Northgate moved to a new provider, the handover pack was a spreadsheet of hostnames and a list of open tickets. The reason store fourteen sat on its own network segment had lived in the old MSP's ticket notes. So had the supplier for the label printers and the workaround for the Harbor Street till that rejected cards after an update. None of it came across. The first six weeks with the new provider were spent relearning what the old one had known. Northgate's next contract opened with a knowledge clause: every fix documented in Northgate's own knowledge base. The clause also required a quarterly export of the ticket history in a format readable without the MSP's software. Nobody was blamed, and the old MSP's engineers had done nothing wrong. The contract had never asked them to leave anything behind.

I have sat on both sides of that table. The side that signs the contract reads the response times. The side that delivers it reads the whole thing.

The Comparison Table

Here is the table for the director: the three currencies, the fit, the hidden cost, and the question that decides it. Copy it and add a column headed "Us" with the honest answer for your own organization in each row.

When Friday comes, the deck will still say it becomes your IT department. Take the table in and ask which column it is proposing. Ask who in that column will know which supplier to call at 06:40, and where that will be written down. If the answer is a pause, you have found the clause to add. Either way, the deck has stopped proposing to become you and started proposing to work with you, which is a better slide four.

Frequently Asked Questions