Decision guide · IT support model

Helpdesk, MSP, or hybrid isn't a satisfaction question. It's a sourcing decision.

Most organizations inherit their support model from whatever was available at the time, then judge it informally by how ticket resolution feels this month. The actual decision is who covers what, at what cost, and what should trigger a change - reviewed on purpose, not by accident.

Frame the sourcing question

A support model chosen once rarely gets revisited on purpose.

The first arrangement - a generalist hire, a starter contract with a support provider, or some of each - usually gets set early and then just continues. It gets judged informally: are people annoyed this week, did the last outage get fixed fast enough. That's a mood reading, not an evaluation of fit.

Meanwhile ticket volume and complexity rarely stand still. A model that worked for twenty employees and one office often quietly stops working at eighty and three locations, long before anyone frames it as a decision rather than a growing source of frustration.

Treated as a sourcing decision, the question separates cleanly: what does each model need to deliver, what does it actually cost in cash and in leadership attention, and what should trigger revisiting it - independent of which vendor or platform ends up running the queue.

Boundary

This is a sourcing and oversight decision, kept separate from fractional IT leadership. Running the helpdesk, staffing the queue, and day-to-day ticket handling are managed-support work, not something delivered from this site.

Coverage shapes

Three shapes, three different things to verify.

Model	Where it tends to fit	What to verify before choosing	Common blind spot
Internal helpdesk	Stable headcount, or a specific case for direct control over support staff.	Coverage during PTO, turnover, and a busy week happening at once.	One generalist quietly becomes the entire support function.
Outsourced MSP	Variable ticket volume, or a need for after-hours and specialist coverage.	Response-time terms as actually written, not as described in the pitch.	Assuming the contract covers scope it never actually named.
Hybrid split	Distinct tiers of work - routine tickets versus specialized systems.	Exactly where the handoff happens, and who owns an issue that crosses it.	A gap between "internal" and "outsourced" that nobody is actually covering.

Decision lenses

Six questions before the next renewal or hire.

Ticket realityWhat do volume, complexity, and aging actually look like - not the impression left by the loudest complaint?
Response-time evidenceIs there a written commitment, and does anyone check it against what actually happens?
Coverage during gapsWhat happens during PTO, turnover, or a spike, without relying on one person's goodwill?
Escalation pathWhen a ticket needs specialist work, is the next step defined, or improvised each time?
Cost per outcomeIs total cost compared against tickets resolved and downtime avoided, not just a monthly invoice?
Review triggerWhat event - headcount growth, a bad quarter, a contract renewal - should force this decision to be revisited?

Working process

Test the current model before defending it.

Baseline current coverage
Ticket volume, category, and aging as they actually are, not as remembered.
Test it against a real incident
A recent outage, spike, or absence shows what the model can actually absorb.
Decide the split
Name what stays internal, what's outsourced, and exactly where the handoff sits.
Set the review trigger
Agree in advance what change - growth, complaints, a renewal - forces a second look.

This connects to the broader structure decision - which functions stay internal at all

Hypothetical pattern

A ticket queue nobody agreed to own past 5 p.m.

A growing forty-person company still runs support through the same generalist hire from its ten-person days, supplemented by an MSP contract signed for a narrower scope. Neither arrangement is wrong about what it covers - nobody has actually compared the two against current ticket volume, or decided who owns a problem that needs both. The useful decision isn't blaming whichever model is in place; it's testing whether the current split still matches the size of the company answering to it.

See how a single-person support model gets priced as a risk

Next step

Bring the support model nobody has tested against this year's ticket volume.

A focused brief can turn an inherited arrangement into a named split, a coverage test, and a clear trigger for revisiting it.

Build the sourcing brief

A support model chosen once rarely gets revisited on purpose.

Baseline current coverage

Test it against a real incident

Decide the split

Set the review trigger

A ticket queue nobody agreed to own past 5 p.m.

Bring the support model nobody has tested against this year's ticket volume.

Get IT decisions made, and made to stick.

Related services