Moving a Partnership to Microsoft: Three Things That Always Come Up

We see this pattern with companies large and small: a partnership that worked with Amazon or Google is moved across to Microsoft, and it does not behave the way anyone expected. The offer is the same. The team is the same. The results are not. It almost always comes down to the same three challenges.

1. Connecting into the Microsoft sales machine

Microsoft publishes its Customer Engagement Methodology — MCEM — and it is the closest thing there is to a Rosetta Stone for how the machine actually works. It connects Microsoft sales, support, industry solutions delivery and partners across five sales stages, and it sets out how Microsoft expects partners to plug in at each one.

Think of it as a universal serial bus. If you are not connected the right way, you cannot interface correctly, no matter how good the offer is. Much of the friction partners describe — sales motion that stalls, funding programs that never quite land, Partner Center plumbing that seems to swallow opportunities — traces back to that connection rather than to the product.

A concrete example: by the end of MCEM’s first stage, the partner should have a Qualified Opportunity created in Partner Center and shared with Microsoft sellers. Teams arriving from another hyperscaler often do not know that gate exists, and so they never appear in the pipeline the Microsoft field is actually looking at.

2. Balancing the account team against the channel

This is the one that catches experienced people out, because it is not a process problem. It is a measurement problem.

The Microsoft account team is measured on retiring Azure commitment. The channel and co-sell teams are measured on partner-led revenue. Those two things pull in different directions. An opportunity that looks excellent to one can look like a distraction to the other.

Shaping a deal so it satisfies both is one of the harder balances to strike in the ecosystem, and it is rarely written down anywhere. It is learned by having been on the inside of those conversations.

3. Scorecards and obligations

Every team you touch carries its own scorecard and its own obligations. The partner development manager, the account executive, the specialist seller, the cloud solution architect — each is being measured on something different, and each will help you enthusiastically when your opportunity moves their number.

This is why the commitments coming out of a joint planning session matter so much. Knowing what was actually committed, and by whom, tells you which scorecards are already in play and where to aim. Without that, you are guessing at which door to knock on.

Where this leaves you

None of these three is a capability gap. Companies that hit them are usually good at partnering — they proved it on another cloud. The gap is structural knowledge of how this particular machine is wired.

There is an old story about a retired engineer called back in to fix a machine nobody else could. He tapped it once, in the right spot, and it ran again. His invoice caused an argument, so he itemised it: one dollar for tapping, and the rest for knowing where to tap.

That is the work. Not the tap — knowing where.