Nine questions that separate cloud MSPs in Australia.

We lose deals. Sometimes to a better fit, sometimes to a provider who answered these questions more comfortably than we did. Publishing them costs us something, and it is still the most useful thing we can write for someone in the middle of a selection process.

1. Where will our infrastructure code live?

The answer should be "in your repositories". If it is "in ours, and we grant you access", you are buying a dependency rather than a service.

Follow up with: if we terminated today, what would we be unable to operate on Monday? A provider who has thought about this will answer immediately. One who has not will tell you it has never come up.

2. Who is on call, and where are they?

Not "we have 24×7 coverage" — everyone says that. Ask how many engineers are on the roster, in which countries, and whether the person who answers at 2am has worked on your account during business hours.

A follow-the-sun model can be excellent. It can also mean an offshore first line whose only genuine capability is escalating to the people who are asleep. The difference is whether the night engineer knows your architecture.

3. How do you make money?

There are three common models and they produce different behaviour:

• Fixed service fee. Interests roughly aligned. The provider wants your estate stable and cheap to operate, because instability costs them margin.
• Margin on your AWS consumption. The provider earns more when your bill grows. Ask directly how cost optimisation is incentivised under that model.
• Percentage of savings. Paid more for finding waste slowly, and structurally uninterested in the attribution work that prevents recurrence.

None of these is disqualifying on its own. Not knowing which one you are buying is.

4. Show me the written result of your last customer failover test.

Redacted is fine. What you are testing is whether one exists at all.

Almost every provider will tell you they do disaster recovery. Considerably fewer have run a live failover for a customer in the past twelve months and written down how long it actually took.

5. What is your alert-to-runbook ratio?

A slightly odd question, deliberately. It reveals whether the provider treats on-call as an engineering discipline or as a staffing arrangement.

The answer you want involves refusing to accept the pager until runbooks exist. The answer that should concern you is any variation of "our engineers are experienced enough to work it out" — which means every incident is improvised, and the quality of your 2am depends on who is rostered.

6. Tell me about an engagement that went badly.

Everyone has one. A provider who cannot name a single failed engagement is either very new or not being straight with you.

What matters is the shape of the answer. "The customer was difficult" is a bad sign. "We under-scoped the discovery and it cost the customer six weeks, so we now refuse to compress it" is the answer you are hoping for.

7. What will you tell us not to do?

A provider whose recommendation is always "yes, and it is a bigger project than you thought" is selling capacity rather than judgement.

Good answers sound like: do not containerise that, it retires in eighteen months; do not buy three-year commitments before rightsizing; do not move that workload, the licence is tied to the hardware. If nobody in the room will tell you something is a bad idea, they are unlikely to start once the contract is signed.

8. What is your sub-processor list, and where do they host?

Every MSP uses third-party tooling — monitoring, ticketing, secrets management, possibly an AI assistant with access to your logs. Some of it is hosted offshore.

You need this list for your own privacy obligations regardless. How readily it is produced tells you whether the provider has thought about data residency at all, or only about the region your workloads run in.

9. How do we leave?

Ask in the first meeting, before anyone is invested. Notice period, handover deliverables, whether there is a documented exit plan and when it was last updated.

A provider comfortable with this question has built for it. One who deflects has built the opposite, and you will discover the specifics at the worst possible moment.

The two we find uncomfortable

In the interest of not writing a list that conveniently favours us:

Question 6 is uncomfortable because our worst engagement involved accepting a migration deadline we should have pushed back on. We delivered, and the customer's team paid for it in unpaid weekends. We now decline compressed discovery, which has cost us at least two engagements since.

Question 2 is uncomfortable because we are a small firm. Our on-call roster is smaller than a large integrator's, which means less redundancy in the roster itself. We compensate with depth — every engineer on the roster has worked on your account — but if roster size is your primary concern, a larger provider is a legitimate choice and you should ask them question 5.

One more, for free

Ask to speak to the engineer who would actually work on your account, not just the account director. Then ask them a technical question about your estate.

You will learn more in ten minutes than from any proposal document.