A mid-sized company has four people in IT. Dana runs the helpdesk, Priya looks after the servers, Marcus is the only one who really understands the ERP system, and the fourth is a manager who also handles procurement. On a Tuesday in March, Marcus resigns. Nobody has written down how the nightly ERP job works. Two weeks later it fails at 2 a.m., and Dana spends the morning on the phone with a vendor who keeps asking, “Who set this up?”
Plenty of IT teams have a Marcus. The managed-services-or-in-house debate tends to start the week after somebody leaves, or the week after a budget cut. Which means people decide in a rush. Here’s a calmer route through it. When does each option work? What does each really cost? And what should you ask a provider before signing?
What “managed services” actually means
Start with the term. A managed services provider, or MSP, looks after a chunk of your IT on a monthly fee, against service levels you’ve agreed up front. Which chunk? Usually the helpdesk, and sometimes the network, the cloud setup, security monitoring or day-to-day support for one application. What changes is what the money buys. You’re buying a result, such as tickets answered within fifteen minutes, or an ERP that’s up 99.9 percent of the time.
That’s different from hiring a contractor, who works under your management, and different from a one-off project, which ends. And the arrangement is meant to keep going, with the provider on the hook for it.
When keeping it in-house wins
If the work is central to how you compete, keep it in-house. Take a software company: it’s unlikely to hand the systems its engineers know best to an outsider. Steady demand helps too, as does a real ability to hire and keep good people. Then there’s know-how so specific to your business that explaining it takes longer than doing it. That stays home.
The least glamorous reason is control. An internal team answers to you directly. Change its priorities in an afternoon, no contract to check.
When managed services pay off
Coverage is the obvious case. Suppose somebody has to watch the systems at 3 a.m. on a Sunday. In-house, that’s several people on rotas. A provider covers it by sharing the same people across many customers. Skills are another. A niche you need two days a month isn’t worth a full-time salary. Then there’s unevenness. A product launch or a migration creates a spike, and spikes are easier to handle with a provider than with a payroll.
Finance teams tend to like a fixed monthly number. A fixed monthly fee for a defined scope is simpler to budget than a pile of salaries, recruiting costs, training, tools and the odd emergency contractor. And leaders like what it frees up. With routine work gone, your own people get time for the projects that actually change the business.
The honest cost comparison
People often set a provider’s invoice against one salary and decide managed services are expensive, or set it against a salary they haven’t fully counted and decide the opposite. Leave anything off either list and the comparison is worthless.
On one side there’s salary and benefits, recruiting, training, licenses and tools, holiday and sick cover, and the gap every time someone walks out. On the other there’s the fee, anything billed outside the agreed scope, your own staff’s time spent managing the relationship, and the price of switching if it all goes wrong. Neither list is short. Build both for your own situation, ideally over three years, rather than trusting a rule of thumb from someone who sells one of them.
The risks nobody puts on the slide
With managed services, the big risks are dependence and knowledge. If the provider’s engineers understand your environment better than your own staff do, leaving them gets hard. Scope creep comes a close second, since anything not written into the contract tends to become a chargeable extra. Security deserves a direct question as well, because the provider will have access to your systems.
In-house has risks of its own. One person who knows everything is a single point of failure, as Marcus showed. Hiring in a tight market can take months. And teams that spend every day on tickets rarely get time to improve anything.
A contract is not a substitute for paying attention. Once a quarter, sit down and ask whether the service levels are actually being hit, whether the same tickets keep returning, and whether the provider’s people have changed.
Often the answer is both
A lot of companies settle on a mix. They keep the people with the business knowledge, who make the architecture calls, and pass the repetitive, round-the-clock work (monitoring, patching, first-line support, routine application upkeep) to a provider. Roughly speaking, the dividing line is between work that makes you different and work that merely has to be done properly.
Take a retailer with six people in IT. Two stay in-house: one who owns the order system, one who owns the architecture. The helpdesk, patching and overnight monitoring go to a provider. Now the two stop firefighting and start planning next season’s launch.
What to ask before you sign
First: what’s in scope, and what costs extra? The second half of that answer is where surprises hide. Service levels should be in writing, with a clear way of measuring them and a clear consequence when they’re missed. Who will actually work on your account? How long have they been with the provider? What happens when one of them leaves? Which security certifications do they hold, and how is your data protected? How would they hand things back, or move you to someone else? Exit terms reveal how confident a provider is in its own service. And ask for two references from companies about your size.
Making the move
If you do bring in a provider, the first month matters more than the contract. Tell your own staff early and plainly what the change means for them. People who hear it through rumor assume the worst, and they’re the ones holding the knowledge you need. Then do a real knowledge transfer: get them to write down what only they know. Overlap the old and new set-ups for a while if you can. Decide who owns which decisions. Meet weekly to begin with, then less. You’ll learn a great deal about a provider from how it handles the first few awkward weeks.
Our AI managed services are built around this kind of ongoing partnership, with AI doing much of the repetitive monitoring so that people can concentrate on harder problems. For more on how the model has changed, read how the modern managed services model supports stability, and for the scaling side, see managed IT services that reduce scaling friction.
Modernize with confidence. Build for what's next.
Talk to our team about embedding AI into the core of your business.