Managed services or an in-house admin: how to decide honestly

The question usually arrives already framed as a cost comparison. Somebody has a proposal from a managed services supplier on one side and an idea of what an experienced admin costs to employ on the other, and the meeting is about which figure is smaller.

That comparison settles nothing, because the two figures do not buy the same thing. One buys a person who will spend a year learning how your organisation actually works and will then be very hard to replace. The other buys access to a spread of skills you will use unevenly, from people who will never know your business as well as an employee would. Both are legitimate purchases. Neither is a cheaper version of the other.

We sell Salesforce managed services, so we have a commercial interest in one of the two answers, and you should weigh what follows accordingly. We publish it anyway because an article with this title that ends in a purchase is worth nothing to the person reading it, and because a client who bought the wrong model from us costs us more in the second year than the sale was worth in the first.

#Why price is the wrong axis

Employment and supply have different shapes, and the shapes matter more than the rates.

An employed admin is a fixed commitment against a fixed capacity. You pay the same in the quiet month as in the month of a go-live, buying availability rather than output, which is a reasonable thing to buy. In the busy month you cannot get more of them at any price.

A supplier is variable capacity against no accumulated knowledge. You can turn the volume up for a migration and down afterwards, and the money tracks the work. What you cannot buy is the thing an employee accumulates for free: several years of knowing why the pricing model carries that one exception, and who will be upset if it changes.

So the honest question is not which is cheaper. It is which of those two properties the organisation needs more of, and that turns on things nobody puts in a business case.

#The variables that actually decide it

Five, and worth settling before anyone opens a rate card.

Is demand predictable or spiky? An org with a steady trickle of small changes has a shape an employed person fits well. An org that does very little for four months and then runs an acquisition, a data migration and a compliance deadline in the same quarter does not, and hiring for the peak means paying for the trough.

Is the work judgement about the business, or specialist platform skill? Deciding whether a new territory model reflects how the sales teams really cover accounts is a business judgement, best made by somebody who sits near the people doing the covering. Rebuilding the assignment logic underneath it is a platform skill, best done by somebody who has built twenty of them.

Is the org changing or stable? A stable org needs stewardship: releases read and triaged, access reviewed, small things kept from becoming large ones. Much of that is recurring and bounded, which is why triaging a Salesforce release in thirty minutes is a routine rather than a project. A changing org needs build capacity instead, and build capacity is what an internal team runs out of first.

How much risk can you carry if one person leaves? Not whether they will leave. Whether the organisation can absorb it when they do. If Salesforce runs a process the business cannot pause for a fortnight, a single admin is a risk that has already been accepted without ever being priced.

Can anyone internally hold a supplier to account? This is the condition most often missing, and it decides more outcomes than the other four. A supplier with no informed counterpart drifts towards whatever is easiest to invoice, not through bad faith but through the absence of anybody asking why the same problem has been ticketed nine times. If nobody internally can read a proposed change and say that is not what we asked for, outsourcing has not removed the management burden. It has hidden it.

#The in-house case, at its strongest

The case for hiring is stronger than suppliers usually admit, and none of it rests on cost.

A good internal admin knows things that are not written down anywhere and never will be. They know that the finance team's month end makes the third working day a bad time to deploy. They know which director asks for a new field whenever they are frustrated and will not want it a week later. They know that the report the board actually looks at is the one with the odd filter, and why. A supplier cannot buy any of that: it is acquired by being present.

Proximity does more than that. Requirements reach an internal admin before they have hardened into a request. Somebody mentions a problem in passing and it is solved as a small change, rather than arriving three weeks later as a specification for the wrong thing. The loop is short enough that mistakes stay cheap.

Then there is trust, which is the part most easily underrated. Users bring an internal admin the things they would never raise a ticket about: the workaround they have quietly run for months, the field they have been putting the wrong value in. That flow of unflattering information is worth a great deal, and it goes to a person rather than to a company. An admin who is trusted can also refuse, and refusal from a colleague who has to live with the consequence lands very differently from refusal by a supplier who looks like they are defending a scope.

#What an external team is genuinely better at

The honest counterpart is a shorter list, but not a small one.

Breadth of exposure. An internal admin has solved your problems. An external team has watched dozens of organisations solve the same problem and knows which of the obvious approaches led somewhere unpleasant. That is not intelligence, it is sample size, and it cannot be acquired inside one org at any speed.

Cover. Leave, illness and resignation are absorbed rather than survived.

Peak capacity. The migration month does not require you to have been paying for migration capacity all year.

Specialist depth. Integration architecture, release engineering, large data volumes, anything with a security review attached: an admin either does these occasionally and slowly, or does not do them. A team with somebody who does them weekly is a difference in kind, not degree.

#How managed services fails, honestly

Five ways, common enough that you should assume they will happen unless the arrangement is deliberately written against them.

Ticket-shaped thinking. The unit of work is the ticket, so the ticket gets closed. The same fault returns next month under a different reference and is closed again. Nobody is incentivised to ask what is producing the pattern, because a root cause is not on anybody's queue. The org receives support indefinitely and never gets better.

No institutional memory. Suppliers rotate people. The consultant who understood your quoting model moves to another account, and what they knew leaves with them into a system that records ticket resolutions rather than reasons. You then pay again, in slower work, for a rediscovery you already funded once.

The account manager problem. You get regular contact with somebody articulate whose job is the relationship, and irregular contact with the person who actually did the work. Detail is lost in translation in both directions, and the person best placed to tell you that your request is a bad idea is not in the room.

Hours rather than outcomes. Most contracts sell capacity. Capacity is consumed, a report confirms it was consumed, and nobody agreed at the outset what should be measurably different a year later. An organisation can spend three years fully supported and no better run than when it started.

The incentive problem. This is the uncomfortable one, and it is structural rather than a question of ethics. A supplier paid for effort does better out of an org that stays complicated than out of one that gets simplified. Nobody has to act on that consciously for it to shape what gets proposed. The defence is to ask explicitly for the work that reduces the supplier's own future revenue, and to notice whether that work is ever suggested unprompted.

#How an in-house admin fails, honestly

The same treatment, applied the other way.

One person is one point of failure. Everything runs until it does not, and the failure is total rather than degraded.

No cover. Annual leave becomes a freeze. Illness becomes a backlog. A resignation becomes a quarter in which nothing happens except firefighting, and the handover is whatever fits inside a notice period.

No outside exposure. A capable admin who has only ever worked in one org will solve a problem competently in a way that several other organisations abandoned two years ago, and nothing inside your walls will ever tell them so.

A ceiling on specialist work. Integration, release engineering and anything carrying a security review sit above where one person can reasonably operate. What happens instead is that the work gets done anyway and slightly wrong, or does not get done and the business routes around the gap. Both are expensive, and neither appears as a line item.

The career problem. A good admin outgrows the role. They learn the platform, want to build, want a team, want the next salary band, and a single-admin org has none of those to offer. The better they get, the more likely they are to leave, which means the model quietly punishes its own success. Organisations that keep good admins have built a path for them deliberately, and that path costs money too.

#What each model costs, beyond the rate

Both sides carry costs that never make it into the comparison.

Internally: recruitment, including the time the vacancy stays open and the work that does not happen while it is; ramp, because a new admin has to learn the platform and the business at the same time; cover for leave and departure; tooling and licences an external team already owns; training and certification upkeep; and the time of a manager who is usually not technical enough to review the work.

Externally: onboarding, because the first months are partly discovery and you are paying for it; context loss every time the supplier rotates staff, which you pay for more than once; change-order friction, where anything outside the agreed scope requires a conversation that can cost more than the change itself; and the floor, because most agreements carry a minimum you pay in the months when you needed very little.

None of these are reasons to pick one model over the other. They are the reason the two headline figures were never comparable.

#The hybrid, which is where most organisations land

Past a certain size the answer is usually both, and the split is not arbitrary.

An internal owner holds the business context and the priorities. They decide what gets built and why, they are who users bring things to, and they are accountable for the state of the org. They do not need to be the person with the deepest platform skill, and in a well-run hybrid they usually are not.

External capacity takes the specialist and the peak work: the integration, the migration, the release engineering, the month when three things land at once. It also supplies the one thing an internal person cannot get for themselves: a straight account of what other organisations did about the same problem.

The supplier now has an informed counterpart, the condition that stops ticket-shaped thinking. The internal admin now has cover, an escalation path and outside exposure, which between them are most of the reason good admins leave.

#What must not be outsourced

One thing, and it is the thing most often handed over by accident: the decision about what gets built and why.

A supplier can tell you how to build something and roughly what it will take. They cannot tell you whether it is worth building, because that requires knowing what the organisation is trying to do this year and which internal argument the request came out of. When that decision drifts across, what gets built is what was asked for, which is not the same as what was needed, and the org accumulates the kind of debt that stays invisible until somebody goes looking. A technical debt audit you can run on your own org is a reasonable way to find out how much of what you have nobody can now explain the reason for.

The same applies to the access model. Permissions granted one urgent request at a time, by whoever happened to be available, produce a structure nobody owns, and permission set debt is what that looks like a few years in. A supplier can execute an access review. They cannot decide who in your organisation should be able to see what.

#Situation, model, and the condition that must hold

Read the right-hand column as the load-bearing one. Every row works only while its condition is true, and most disappointing arrangements are a row where the model was chosen and the condition was never checked.

#Making the decision

Two questions get you most of the way, and neither is about price.

First, what proportion of the next twelve months of work is judgement about your business, and what proportion is specialist platform skill? If it is mostly the first, you are hiring, and any supplier you use should be there for the second. If it is mostly the second and the volume is uneven, you are buying capacity, and the person you still need internally is an owner rather than a builder.

Second, who will hold the arrangement to account, by name? If the answer is nobody, or a manager with no platform knowledge and no time, that is the problem to solve first, because it will defeat either model. An unmanaged supplier closes tickets. An unmanaged admin builds whatever was asked for loudest.

The decision is not which model is better. It is which failure mode your organisation is better placed to manage: the one where the knowledge is concentrated in a person who may leave, or the one where capacity is available but nobody is accumulating knowledge at all. Answer the five variables honestly, be truthful about the fifth in particular, and the model that fits is usually clear before anyone opens a rate card.