Most businesses sign a managed IT services agreement after a couple of meetings and a reference call. The meetings go well and the reference is a happy client, because nobody hands you the other kind.
None of that is dishonest. The trouble is that what decides whether the relationship works in year three rarely comes up in the first two meetings. Below are the questions I'd ask. For each one, I've noted what it tells you and the answers that should slow you down.
We wrote this to be used on us too. If a provider is uncomfortable being asked these, that tells you something on its own.
Day-to-day work
Who will actually do our work, and will it be the same people each time?
I'd ask this to find out whether you are buying a relationship with people who know you or a place in a queue. Both models exist and both can work, but they're different products, and the difference doesn't show up on a proposal.
Slow down if the answer is about the size of the team instead of who will know your environment. When each call goes to whoever is free, nobody builds up knowledge of your systems, and recurring problems never get recognized as recurring. That's one of the most common reasons businesses eventually leave.
What is included, and what will we be billed extra for?
This tells you whether the line between covered support and billable project work is written down anywhere.
Slow down if the answer changes depending on who you ask, or comes as a reassurance instead of a document. In my experience, this is the most common source of arguments between businesses and their IT providers, and it's easy to prevent at this stage.
How will we know what you did?
This is about reporting. Most of what a good provider does goes unnoticed when it's working, so the only way to tell quiet, competent work from no work is a report that arrives without you asking.
Slow down if reporting means a list of tickets. A ticket list shows what went wrong, and it says nothing about what was prevented.
Who do we call when it's urgent, and what happens outside business hours?
I ask this to see how a bad day actually gets handled.
Slow down if you get a promise about speed instead of a description of the process. What you want to hear is how a request reaches a person and what happens after that.
When things are not going well
What happens when we disagree about whether something is your fault?
Mostly I'd be testing honesty under an uncomfortable question. Every provider gets something wrong eventually.
Slow down if they cannot picture the situation. A provider with a real answer has had that conversation before and thought about how to handle it.
Can we talk to a client who left you?
Every provider has lost clients. I'd put more trust in a provider who has thought honestly about why than in one who claims it has never happened.
Slow down if the question makes them visibly uncomfortable. The answer does not have to be yes, but it does have to be straight.
The contract and the money
This is the part people skip, and it matters most in the years you can't picture yet.
Who owns our domain name, licenses, data, and administrator accounts?
This tells you whether you're buying assets or renting them. More often than it should, a business finds out years in that its domain name is registered to its provider, or that software it thought it owned is licensed to someone else.
Slow down if the answer is complicated. It should be simple, and the owner should be you.
If we leave, what exactly do we get, and how long does it take?
This is how I'd find out whether documentation exists. A provider who documents your environment properly can hand it over quickly. One who hasn't leaves you paying the next provider to work out what you have.
Slow down if nobody can describe the handover. I wouldn't sign an agreement that's painful to get out of.
What is the notice period, and what happens automatically at renewal?
This tells you whether the contract renews on its own and for how long. It also tells you what you have to do, and by when, to stop it.
Slow down if you only get a verbal summary. Read this clause yourself. It is short, and in my experience it's the clause most likely to cost you a year.
What is the price per unit, and what counts as a unit?
This tells you whether you'll be able to read the bill, including what happens when your headcount or device count changes. If you can't see the units, you can't check the invoice, and unchecked bills tend to creep up. We wrote about how to read an IT invoice if you want to run this check on your current provider today.
How much notice do we get before a price increase?
This is about predictability. Price increases are normal, and I expect them. A surprise increase is a choice the provider made.
Your own environment
What did you find when you looked at our systems, and what would you do first?
I'd weight this question most heavily. A provider who has actually examined your environment gives a specific answer, and one who hasn't gives a general one.
Slow down if the proposal could have been written for any business your size, because it probably was.
Will you tell us if we don't need you?
I'd ask this to find out whether you are being sold to or advised.
Slow down if they say yes, but the assessment only comes with the sale. The test is whether you keep the written findings no matter what you decide.
How to use these questions
I wouldn't read all thirteen off a list in one meeting. Pick the six that matter most to your situation and ask them in a normal conversation.
I'd listen for specifics more than for the right answer. Dates, documents, names, and processes mean someone has thought about it. General reassurance means someone is answering from a script.
If you'd like these in a form you can take into a meeting, we keep a short guide to the questions worth asking before you sign an IT contract. If you'd rather start with a written read on what you already have, that's where we begin too, with an assessment that changes nothing and commits you to nothing. Or book a free 15-minute call and ask us these questions directly.