How to Choose a Managed IT Services Provider: Twelve Questions Before You Sign

Most managed services contracts are signed on price and the impression of the first meeting. Six months later the organisation discovers it bought an emergency phone number, not a party that takes responsibility for keeping its systems running. The questions below reveal the difference early, before the first real outage does.

First: questions about commitment

1. What response time do you commit to, and when does the clock start?

"We respond quickly" is not an answer. The right answer is a written number, with a clear definition of when the clock starts: when the ticket is opened? When the system detects the failure? Or at the start of the next working hour? The difference between these definitions can be hours in the middle of the night.

2. What is the difference between response time and resolution time?

Many contracts commit only to response, meaning someone will reply to you within the stated time. Ask plainly: is there a commitment to resolution time, or only to response time? And if it is only response, what stops a problem from staying open for a week?

3. What happens if the provider does not deliver?

An agreement with no consequence for non-delivery is a statement of intent. Ask about the compensation or credit mechanism, and about the right to terminate on repeated breaches. The provider's answer to this question in particular tells you how much they trust their own ability to deliver.

Second: questions about actual operations

4. How do you detect failures?

The real question here is: will you know about the failure before me or after me? A provider that waits for your call to learn the server has stopped is not a managed services provider; it is on-demand support under a different name. Ask them to explain exactly what they monitor, and which thresholds trigger an alert.

5. What happens at three in the morning?

Ask about the on-call arrangement: is there an actual team available, or a number that rings a sleeping employee? Who makes the decision if a production system needs restarting? Do they have the authority to act, or do they wait for your approval, and what if nobody on your side answers?

6. Show me a real service report

Ask for a sample monthly report (with the client's details redacted). A good report shows actual availability against the committed level, the number of incidents and their classification, the average time to close, and what changed during the month. A weak report shows only the number of tickets closed.

Third: questions about the risks nobody mentions

7. Who owns the documentation?

If the knowledge of how to run your environment sits in the head of one engineer at the provider, you carry a double risk: the risk of that person being unavailable, and the risk of the contract ending. Require written, up-to-date documentation of the environment that belongs to you, not to the provider.

8. How do we exit if we decide to end the contract?

Ask this in the first meeting, not the last. A confident provider has a ready answer: a defined transition period, a documented handover, transfer of access, and support while you move to another party. Hesitation on this question is a sign that leaving will be painful by design.

9. Who holds the top-level access to our systems?

The primary owner accounts must stay in your organisation's name, with the provider working through delegated accounts that can be revoked immediately. Any arrangement that makes the provider the only owner of a critical account turns a working relationship into a hostage situation.

Fourth: questions about backup and security

10. When did you last test an actual restore?

A backup that has never been tested is not a backup; it is an assumption. Ask how often restores are tested, when the last one was done, and how long the restore actually took.

11. What is your security update policy?

Ask about the maintenance window, how a critical update that appears outside it is handled, and how an update is rolled back if it causes a failure. A provider that "updates when needed" in practice updates after the incident.

12. Who tells us when you make a mistake?

Ask about the disclosure policy: if a mistake by their team causes an outage, will you know? And do you receive a written root cause analysis? Transparency about mistakes is harder than transparency about success, and it is the most accurate indicator of the kind of partnership you are entering.

A short list for the first meeting

• A written response time, with a definition of when the clock starts
• A clear distinction between response time and resolution time
• A specific contractual consequence when commitments are missed
• A precise description of what is monitored and the alert thresholds
• A real on-call arrangement outside working hours
• An actual sample monthly report to review
• Documentation of the environment owned by the organisation, not the provider
• A written exit plan before you sign
• Ownership of the top-level accounts stays with you
• A documented schedule for testing backup restores
• An update policy with a rollback mechanism
• A commitment to a root cause report after incidents

The bottom line

The difference between a support vendor and an operations partner does not show in the presentation, but in the details of the agreement and in the provider's answers to the uncomfortable questions. If the provider avoids numbers and prefers general phrases, you are most likely buying a promise, not a service.

And the simplest test of all: ask them to write their commitments in a single table. Whoever can do that in one sitting knows what they are selling. For what that table should contain, see Service Level Agreements: What an SLA Must Actually Contain.