Choosing an IT support partner: a practical guide

Work out what you need before you ask anyone to quote

Most selection processes start with a search and three phone calls. That's the wrong way round. If you can't describe what's not working today, every provider will describe a package instead, and you'll end up comparing brochures.

Spend an hour on this first. It doesn't need to be a formal document - a page of notes is enough - but it should answer five things:

What frustrates your team most? Ask three or four people, not just whoever handles IT. The answers are usually specific and repetitive, which is exactly what you want.
What have you got? Rough numbers: people, laptops, servers, sites, the main systems the business runs on, and which of them are getting old.
What has to keep working? If one system going down stops the business earning, it needs different treatment from the rest.
What's coming in the next year? A move, a merger, a new site, a system replacement, headcount growth. This changes what "good" looks like.
What are you spending now? Support, licences, hardware, and any subscriptions individual departments pay for. It's rarely one number and it's usually higher than expected.

The single most useful artefact in a selection process is a list of the last ten things that went wrong and how long each took to sort. It cuts through sales conversations faster than anything else.

Decide what shape of support fits

There isn't a single model of IT support, and providers will usually lead with the one they sell most of. It's worth knowing the options before you're shown a package.

Fully managed suits organisations with no internal IT, or one stretched person doing IT alongside another job. The provider owns the service end to end.
Co-managed suits organisations that already have IT people. You keep ownership and get overflow cover, specialist input and project capacity. Ask about it explicitly - it's often not offered by default.
Pay-as-you-go, or time and materials, is cheaper until something goes badly wrong. It works for very small teams with simple setups and low tolerance for fixed cost, and it means nobody is doing preventative work.
Project-only, where day-to-day support stays in-house and you bring in help for migrations or security work. Fine, as long as somebody is still watching the routine things.

If you already have an internal IT person, be straight with providers about it. The good ones will talk about how they'd work alongside them. The ones who talk about replacing them are telling you something useful.

Compare proposals that look the same

Two quotes at similar prices can be very different services. The gap usually sits in what's bundled and what's extra, so the useful comparison isn't price against price - it's each proposal against your own list of needs.

Build a simple grid. Down the side, the ten to fifteen things you need. Across the top, the providers. Then fill it in from what's written in each proposal, not from what you remember being said in the meeting.

Help desk hours, and what happens outside them.
Monitoring and patching - included, or an add-on with its own line?
Security as standard: multi-factor authentication, endpoint protection, email filtering, awareness training.
Backup, including Microsoft 365 data, and how often restores are tested.
On-site visits: how many, and what triggers a charge.
Microsoft 365 administration and licence management.
Documentation and asset records, and whether you get a copy.
Review meetings and reporting - how often, and with whom.
Onboarding: what happens in the first ninety days, and whether it's charged separately.
Project work: rates, and who decides when something counts as a project.

Then multiply everything out over three years, including the add-ons you know you'd buy. The cheapest monthly rate frequently isn't the cheapest arrangement, and the difference is usually visible by year two.

A clear exclusion list is a good sign, not a warning. It means someone has thought the service through rather than hoping the edge cases don't come up.

The questions worth asking

Ask all of these, and ask them of every provider so the answers are comparable. Note how they answer as well as what they say - hedging on a straightforward question tends to predict how the relationship goes.

About the day to day

Who will we actually speak to, and will it be the same people each time?
What are your response times, how are they measured, and what happens when you miss one?
How do you handle an issue that's been reported three times by three different people?
How does someone report a problem when email is down?

About the work we won't see

What's included for security as standard, and what costs extra?
When did you last test a restore for a client, and would you show us the result?
What does your leavers process look like, and who checks it happened?
How do you decide what needs patching, and when?

About the relationship

What does onboarding look like in the first ninety days?
How often would we meet, and what would you bring to those meetings?
Can we speak to a client of a similar size who's been with you two years or more?
If we wanted to leave, what would you hand over and how long would it take?

That last question is the most revealing one on the list. A provider who's comfortable explaining how you'd leave is usually confident you won't want to.

The contract terms worth reading twice

Nobody enjoys this part, and it's where most of the future arguments are decided. You don't need a lawyer for a support agreement, but you do need to read six things properly.

Term and notice. A twelve-month term with three months' notice is common and reasonable. Anything longer should come with something in return.
Auto-renewal. Check whether it rolls for another full term and when the window to give notice opens. Put that date in a shared calendar the day you sign.
Price review. Annual increases are normal; uncapped ones aren't. Ask for a stated cap or a link to a published index.
User count changes. What happens when you grow, and - more importantly - when you shrink mid-term.
What counts as a project. The fuzziest boundary in most agreements, and the one that generates surprise invoices.
Exit and data. Who owns the documentation, the asset records and the admin credentials, and what's handed over on exit. Get this in writing rather than in a reassuring email.

One more thing to check: who holds the administrator accounts for your Microsoft 365 tenant, your domain name and your backups. They should be yours, with the provider granted access - not the other way round. This is the single most common reason a switch takes longer than it should.

What good onboarding looks like

The transition is what most organisations worry about, and it's the part that's most predictable when it's run properly. Expect four to eight weeks of organised work, with your team barely noticing most of it.

Weeks one to two: discovery. Systems, licences, admin accounts, suppliers, contracts and renewal dates, all written down and shared with you.
Weeks two to four: access and tooling. Monitoring in place, backups verified, the outgoing provider's administrator accounts removed at an agreed point.
Week four: the support route changes once, with clear communication to your team. Two desks running in parallel indefinitely is a sign of a plan that hasn't been made.
Weeks four to twelve: the known problems get picked up, so the change is visible to your team quickly.
Day ninety: a review against what was promised, with numbers rather than impressions.

If nothing your team complained about in the selection process has changed by day ninety, raise it then. It's far easier to reset expectations at three months than at eighteen.

Warning signs during the process

A quote arrives before anyone has asked what your business does or looked at what you've got.
Security is sold with fear rather than priorities. Good advice sounds like "here's what's worth doing first", not "here's what could happen to you".
Every answer comes attached to something to buy. A partner worth having will sometimes tell you not to bother yet.
Vague exclusions, or an unwillingness to put the inclusion list in writing.
No named contact, or a different person at every meeting during the sales process. It rarely improves after signature.
Reluctance to discuss exit terms.

None of these are automatically disqualifying, and a small provider being honest about a gap is worth more than a large one glossing over it. But if you're seeing several, the relationship is telling you how it will run.

Making the decision

Three providers is usually the right number. One gives you no comparison; five turns into a project of its own and the proposals blur.

When it comes to deciding, weight it roughly like this: does the proposal cover what's actually on your list; do you believe they'll do the preventative work; do you want to speak to these people every week; and is the three-year cost something the business can carry comfortably. Price matters, and it's rarely the thing people regret. What they regret is choosing a service that didn't cover the thing that broke.

If two proposals are close, ask both for a reference from a client of similar size and sector, and ask that client one question: what's it like when something goes wrong? That answer decides more selections than any comparison grid.

Choosing an IT support partner

What's in this guide