How to judge IT support before you switch provider

Changing IT provider is disruptive enough that a polished proposal should never be the only evidence behind the decision. Service descriptions tend to sound similar. The differences appear when a real issue crosses teams, systems, and supplier boundaries.

The aim of a provider review is to understand how the relationship will work on an ordinary Tuesday as well as during a serious incident. That requires a conversation about behaviour, ownership, and judgement, not just products and ticket targets.

Test the model with a real scenario

Choose a recent issue that mattered to the business and ask each shortlisted provider to talk through it. It might involve a new starter who cannot work, a suspicious sign-in, an intermittent site connection, or an application problem involving another supplier.

Listen for the route the provider takes:

• How would the user make contact?
• Who decides the priority and explains what happens next?
• When would an engineer become directly involved?
• How would the provider handle a third party or unclear root cause?
• What would the user and business lead be told while work continues?

A useful answer should be specific enough to picture the experience. If the response stays at the level of a ticket workflow, ask who remains accountable when the workflow no longer fits.

Follow one issue from opening to closure

A fast acknowledgement is not the same as progress. Ask how the provider keeps ownership after first contact, how stalled work is surfaced, and how users avoid having to repeat context at every hand-off.

Then look beyond resolution. Who checks whether a recurring issue has a wider cause? How are patterns brought to the business? What happens when the right answer is a policy change, supplier conversation, or planned improvement rather than another ticket?

This is where managed IT support becomes an operating relationship. The provider should be able to join users, devices, Microsoft 365, connectivity, security, and external applications into one coherent response, even when another party ultimately performs part of the work.

Check the depth behind the service desk

The support team will encounter decisions that reach beyond day-to-day troubleshooting. Ask who can advise on identity, Microsoft 365 administration, networking, backup, security controls, and hosted workloads, and how that expertise is brought into an active issue.

Avoid turning this into a hunt for the longest product list. The important test is whether the provider can recognise when deeper input is needed and retain ownership while it is obtained.

Security is a useful example. Ask how a support concern becomes a security investigation, who coordinates containment or remediation, and how the business is updated. Our article on making cyber security controls operational sets out the routines that should sit behind those answers.

Inspect the transition before signing

Weak transitions create the conditions for future service problems. Before choosing a provider, ask for the sequence from contract agreement to steady-state support.

The plan should identify how access and documentation will be obtained, how the existing estate will be understood, how users will learn the new support routes, and how risks discovered during onboarding will be prioritised. It should also distinguish immediate continuity work from improvements that need a separate decision.

Ask what the provider needs from the outgoing supplier and from your own team. A realistic plan will acknowledge dependencies and decision points instead of presenting the switch as frictionless.

Compare evidence, not adjectives

Use the same shortlist questions for every provider and record the answers in plain language. Four areas are especially revealing:

Access: Can users reach the right help without navigating an unnecessary maze?

Ownership: Is one party accountable for moving the issue forward, including across suppliers?

Judgement: Can the team distinguish urgency, risk, user impact, and longer-term improvement?

Visibility: Will leaders understand recurring problems, unresolved risks, and agreed priorities?

References, service examples, onboarding documents, reporting samples, and role clarity can all support the assessment. Treat claims without a clear operating explanation as questions still to be answered.

Choose the relationship you want to operate

The final comparison should describe how each provider will behave, not how many features appear in the proposal. Ask which team made ownership easiest to understand, dealt most honestly with dependencies, and connected support to the wider technology estate.

A switch is worthwhile when the new relationship is designed to make IT calmer and clearer: straightforward to reach, accountable through resolution, connected to the right expertise, and capable of improving after onboarding. If that picture is still vague, the shortlist needs another conversation before the contract needs a signature.