How to Co-Sell With Microsoft Azure: Partner Center, IP Co-Sell and MACC Explained

Microsoft’s co-sell motion is built around a different set of mechanics than AWS’s – Partner Center rather than Partner Central, Partner Sales Connect rather than ACE, and a set of co-sell eligibility statuses that gate access to the things that matter most. The MACC commit-drawdown dynamic is also more visible here than anywhere else in the hyperscaler landscape. This post maps the Microsoft-specific mechanics from program status through to live opportunity management.

TL;DR

  • Microsoft co-sell is managed through Partner Center Referrals and the Co-sell opportunities workspace, gated by Microsoft AI Cloud Partner Program membership with Azure IP co-sell eligible status as the meaningful threshold for MACC-eligible business.
  • Microsoft Azure Consumption Commitment (MACC) is one of the main motivators for enterprise customers buying through Microsoft Marketplace. ISVs without Azure IP co-sell eligible status produce offers that don’t count toward customer MACC drawdown, which by design limits enterprise traction.
  • The Microsoft field organisation is the most complex of the three hyperscalers – Account Technology Strategists (ATS), Solution Specialists across six solution areas, Cloud Solution Architects (CSA), CSMs, PDMs and industry leads. Which roles you over-index on depends on tenancy archetype – see ISV-Hosted vs Customer-Deployed.
  • ISV Success is a 12-month programme within Microsoft AI Cloud Partner Program that supports software development companies in building well-architected applications, publishing to Microsoft Marketplace and growing sales. Co-sell ready and Azure IP co-sell eligible status are governed by the separate Partner Center co-sell requirements.
  • The most significant gap most ISVs hit: being co-sell ready but not yet Azure IP co-sell eligible. The two statuses look similar in Partner Center but the eligibility gap is where enterprise traction is lost.

What Microsoft Co-Sell Is

Microsoft co-sell is collaborative engagement between Microsoft and its partner ecosystem for jointly pursuing customer business. It is managed through Partner Center Referrals and Microsoft Marketplace. For Azure IP offers, the current co-sell statuses are In-market, Co-sell ready and Azure IP co-sell eligible, while Microsoft preferred solutions is a marketplace badge rather than a co-sell status. The motion sits inside the broader cloud co-sell model covered in Hyperscaler Co-Sell; this post covers the Microsoft-specific mechanics.

The Microsoft Field Organisation

Microsoft has the most complex field organisation of the three hyperscalers. The structure is built around three distinct units and named solution areas (Azure Infrastructure, Data & AI, Digital & App Innovation, Modern Work, Security and Business Applications) with dedicated technical and sales roles per area. The result is a wider, deeper field than AWS or Google Cloud, with more named counterparts per customer account but also more navigation overhead for ISVs.

The ATU / STU / CSU Structure

Microsoft’s enterprise field operates across three distinct units in parallel on the same customer accounts:

The Account Technology Unit (ATU) manages the overall customer relationship – the commercial and executive layer. The ATU is the “front door” to a Microsoft enterprise account and the natural first point of contact for ISVs approaching from the outside.

The Specialist Technology Unit (STU) sells and technically validates solution-area-specific workloads. STU members are organised by solution area – Azure Infrastructure, Data & AI, Security, and so on – and carry quota tied to consumption in their specific domain.

The Customer Success Unit (CSU) owns the post-sale relationship, focused on adoption acceleration, consumption growth and renewal health. It is not a selling unit in the conventional sense but is a significant source of hyperscaler-led inbound, particularly where a customer has a workload problem the Microsoft portfolio hasn’t solved.

Role-level detail – what each person does, how to engage them and which matter most for which ISV type – is in The Full Role Set below.

What This Means for ISV Engagement

For customer-deployed ISVs, this structure is significant in practice in a way that is consistently underestimated. The ATU manages the relationship; the STU drives the workload; the CSU is where post-sale urgency lives. An ISV whose product solves a specific Azure workload problem – infrastructure performance, data platform migration, security posture – will find STU members both more technically engaged with the problem and more commercially motivated to act. STU members encounter customer workload problems that require third-party solutions directly; they have quota incentive to solve those problems; and they have enough technical depth to evaluate whether an ISV’s solution is genuinely fit for purpose. In practitioner experience, STU-originated customer introductions – where a Solution Sales Professional (SSP) or Technical Sales Professional (TSP) brings an ISV into an active customer pursuit – outpace ATU-originated customer introductions by a significant ratio for customer-deployed workload solutions (practitioner observation, not measured data). The implication: for customer-deployed ISVs, the right engagement strategy invests in building STU and CSU relationships alongside (or ahead of) the Partner Development Manager (PDM) relationship – the PDM brokers access to the field, but the STU is where the workload problem lives and the CSU is where post-sale urgency can produce the fastest-moving inbound.

For technically deep infrastructure ISVs in particular, the engagement sequence tends to follow a consistent pattern in practice: the AE prefers to remain at the relationship and commercial level, delegating technical engagement to the STU or the Account Technology Strategist (ATS); the ATS listens with genuine interest and then passes the ISV to the relevant SSP or TSP; and it is the SSP who becomes the primary co-sell counterpart and the deal’s internal champion. This is not a failure of the AE relationship – it is the correct routing for a product whose value proposition requires the technical depth the STU brings. ISVs that spend significant time trying to activate AEs on a deep infrastructure product, when the AE’s natural response is to hand off to the STU, are burning relationship capital on the wrong layer. The practical implication is to follow the handoff: when the ATS says “you should speak to our Data & AI SSP,” treat that as the signal to invest in the SSP relationship rather than a brush-off. A lighter-touch ISV – a broadly understood SaaS security product, for example – may get more direct AE engagement simply because the AE can grasp and pitch the value proposition without STU involvement; the deeper and more technical the product, the more reliably the STU becomes the primary engagement layer.

The same logic applies to the internal training and lunch-and-learn model. For technically deep ISVs, securing a slot on an STU or CSU team’s internal training calendar is significantly more valuable than the equivalent slot with an ATU team. STU members are actively looking for solutions to the workload problems on their accounts; a well-delivered session that matches their current domain will generate direct customer introductions to active pursuits. Cloud Solution Architect (CSA) teams in the CSU are similarly receptive for the reasons covered in the CSA role entry below. ATU internal sessions are worth running for brand awareness but are less likely to produce immediate co-sell pipeline than STU or CSU equivalents.

A Note on Naming and Pronunciation

Microsoft’s naming conventions for these roles evolve; the ATU / STU / CSU functional structure is consistent even when acronyms change. One practitioner note on pronunciation: ATU and CSU are spoken as three-letter acronyms (“Ay-Tee-You”, “See-Ess-You”) but STU is always pronounced phonetically as “Stew.” Getting this wrong in a meeting with Microsoft field is a small but noticeable signal.

The Full Role Set

Account Executive (AE). The commercial relationship owner within the ATU. Owns day-to-day account management, commercial negotiations and pipeline reporting. For technically deep infrastructure ISVs, the AE’s natural response to a third-party product pitch is to delegate to the STU or ATS – this is the correct routing, not a brush-off, and ISVs should follow the handoff rather than invest time re-engaging the AE on technical detail they will not drive forward.

Account Technology Strategist (ATS). Microsoft’s senior technical-strategic role within the ATU, blending lead-architect responsibilities with executive account ownership. Anchors the ATU’s pipeline view and typically acts as the ISV’s first substantive engagement point before routing to the relevant STU specialist. On large strategic accounts, the ATS will sometimes use the title “Account CTO” in their email signatures and LinkedIn profiles – if you encounter that title on a Microsoft enterprise account, it is the same role.

Solution Sales Professional (SSP). The STU’s commercial role, carrying quota tied to a specific solution area. SSPs are often the primary Microsoft co-sell counterpart for customer-deployed ISVs whose product addresses a specific Azure workload – they have domain quota, customer workload context and commercial motivation to include an ISV solution in a pursuit.

Technical Sales Professional (TSP). The STU’s technical role, providing deep pre-sales support per solution area. TSPs run proofs of concept, validate ISV solutions technically and act as decision-makers for whether a third-party product is viable for a customer workload. For customer-deployed ISVs, TSP sign-off is often the gating step before a pursuit advances.

Cloud Solution Architect (CSA). Microsoft’s customer-facing technical role within the Customer Success Unit (CSU) – post-sale focused, distinct from the pre-sale TSP roles in the STU. CSAs lead technical solution design and adoption acceleration on existing accounts and act as technical sponsors for ISV products that need architectural buy-in from the customer success layer.

For technically deep ISVs, CSAs are often more valuable co-sell counterparts than their seniority or nominal role might suggest. Because they sit in the CSU rather than in sales, customers tend to trust them in a way they don’t trust the selling field – a CSA recommendation carries credibility precisely because it has no direct commission attached to it. CSAs are typically highly technical, genuinely curious about new products and willing to invest time in understanding an ISV’s solution if it might help their customers. This makes them natural candidates for the internal lunch-and-learn model described in ISV-Hosted vs Customer-Deployed: a CSA who has seen a compelling product demonstration will often introduce the ISV to CSA counterparts on other accounts or in other regions, creating a peer-referral dynamic that can generate a pipeline of warm introductions entirely outside the formal PDM channel. The discipline is the same: earn the first CSA relationship through genuine technical engagement, deliver a session worth sharing and let the network do the rest.

Customer Success Account Manager (CSAM). The CSU’s customer relationship role, focused on existing-customer adoption, expansion and consumption growth. In principle a source of hyperscaler-led inbound; in practitioner experience, CSAMs are typically less technically engaged and less commercially motivated to advocate for third-party ISV products than either the STU or the CSA. For technically deep infrastructure ISVs in particular, CSAMs tend to remain peripheral to active co-sell pursuits – aware of the ISV relationship but not driving it. Worth maintaining a baseline relationship but not the primary CSU investment layer. Pronounced “See-Sam” in Microsoft field conversation.

Partner Development Manager (PDM). The partner-side relationship owner, sitting inside the Global Partner Solutions (GPS) organisation. Manages the formal MAICPP relationship, brokers introductions to the customer-facing field and gates access to partner-program benefits and MDF. For customer-deployed ISVs, the PDM relationship tends to be less productive than for ISV-hosted SaaS partners – the PDM’s metrics are driven by partner-side consumption and marketplace transactions, which a customer-deployed ISV contributes little to regardless of the commercial size of the deals it closes. The program resources the PDM relationship accordingly. The structural explanation and operational implications are covered in ISV-Hosted vs Customer-Deployed; the short version is that the PDM is a necessary gate for program mechanics but should not be the foundation of the co-sell motion for customer-deployed products.

Industry leads. Microsoft has historically maintained dedicated industry-vertical roles at theatre and area levels (financial services, healthcare and life sciences, retail and consumer goods, manufacturing, public sector, media and telecommunications), carrying industry-specific revenue goals and using partner specialisation as a primary filter for partner introductions in their verticals. The existence and structure of this layer has varied across Microsoft’s several field reorganisations since 2022; verify the current state in Partner Center or with your PDM before building an engagement strategy that depends on it.

The structural rule from Hyperscaler Co-Sell applies with particular force for Microsoft: the layer you over-index on depends on tenancy archetype. Customer-deployed products should invest in STU relationships (SSPs and TSPs in the relevant solution area) alongside or ahead of the PDM relationship. The PDM-first default doesn’t pay back for non-SaaS ISVs on Microsoft any more than it does elsewhere. The definitive reference is ISV-Hosted vs Customer-Deployed.

Microsoft AI Cloud Partner Program (MAICPP)

The Microsoft AI Cloud Partner Program was announced at Microsoft Inspire in July 2023 as the next generation of its partner programme, building on and replacing the legacy Microsoft Cloud Partner Program (MCPP). Current Partner Center documentation uses Microsoft AI Cloud Partner Program throughout. MAICPP is the membership prerequisite for all Microsoft co-sell mechanics; partners enrol once and then progress through the Solutions Partner designation structure for each of the six solution areas.

Solutions Partner designations are earned by accumulating points across three dimensions: performance (deal value, customer adds), skilling (certifications) and customer success (deployments, growth and retention). The threshold is meaningful – partners typically earn one or two designations before adding others, and achieving designations in multiple solution areas requires sustained operational commitment.

Detailed coverage of MAICPP structure, including the six solution areas and the sub-specialisations sitting beneath them, is in Cloud Partner Programs and Specialisations.

Partner Center and Co-Sell Statuses

Partner Center is Microsoft’s partner-facing portal and the system of record for Microsoft AI Cloud Partner Program membership, Solutions Partner designations, Microsoft Marketplace offer publication, benefits and co-sell opportunities in the Referrals workspace. All formal Microsoft co-sell mechanics flow through Partner Center.

Partner Center distinguishes Azure co-sell statuses from Business Applications co-sell incentive statuses. Azure statuses are In-market, Co-sell ready and Azure IP co-sell eligible. Business Applications statuses are Business Applications Co-sell Incentive Standard and Business Applications Co-sell Incentive Premium.

Co-sell ready. Co-sell ready status means the offer has met Microsoft’s co-sell-ready requirements: a PartnerID, active Microsoft Marketplace account, complete business profile, live marketplace offer, geography-level sales contacts and required Co-sell > Solutions page information including a one-pager and pitch deck. Qualified partners manage co-sell opportunities through Partner Center Referrals. Co-sell ready status exposes a solution to Microsoft sales teams, but Azure IP co-sell eligible status is required for an offer to become MACC eligible and for eligible marketplace sales to contribute toward customers’ Microsoft Azure Consumption Commitments.

Azure IP co-sell eligible. Azure IP co-sell eligible is an offer-level status for qualifying IP solutions. It allows partners to submit co-sell referrals and enables sales of eligible marketplace offers to contribute toward customers’ Microsoft Azure Consumption Commitments. The requirements for Azure IP co-sell eligible status, after achieving co-sell ready status, are: the relevant IP offer type, at least USD 100,000 of Azure Consumed Revenue or Marketplace Billed Sales over the trailing 12 months at organisation level, Microsoft technical validation for an Azure-based solution, a reference architecture diagram where required and marketplace transactability for new offers. In practice, the USD 100,000 consumption threshold is the binding constraint for most ISVs – the technical validation and documentation requirements are tractable; accumulating sufficient Azure Consumed Revenue or Marketplace Billed Sales is where the timeline actually lives. The gap between co-sell ready and Azure IP co-sell eligible is where most ISVs spend the most programme-engineering time.

Business Applications Co-sell Incentive (Standard / Premium). A separate co-sell incentive structure specific to Dynamics 365 and Power Platform partners. Standard and Premium tiers carry different incentive levels and eligibility criteria. Partners selling Business Applications products (rather than Azure-platform products) operate under this structure rather than under Azure IP co-sell eligible.

Partners report that getting to co-sell ready status is a relatively straightforward exercise, typically 30–60 days; reaching Azure IP co-sell eligible status is a meaningful engineering and commercial investment, typically 90–180 days from co-sell ready. The two are different in kind, not in degree, and partners that confuse them produce co-sell motions that look operational from the outside but produce no MACC-eligible business.

MACC: Microsoft Azure Consumption Commitment

The Microsoft Azure Consumption Commitment – referenced in practice as Azure MACC or Microsoft MACC – is Microsoft’s pre-committed Azure spend mechanism. Eligible Microsoft Marketplace offers purchased through Microsoft Marketplace or Marketplace in Azure portal decrement a customer’s Microsoft Azure Consumption Commitment for the amounts invoiced. Azure IP co-sell eligible status is required to make a Microsoft Marketplace offer MACC eligible.

Microsoft states that using precommitted cloud spend is one of the main motivators for customers to buy through Microsoft Marketplace. For enterprise customers with MACC, eligibility can meaningfully reduce procurement friction – an ISV offer that counts toward MACC drawdown is simpler in practice for the customer to buy and commercially more attractive than the same offer transacted through traditional procurement.

The mechanic flows through the Azure IP co-sell eligible gate. Customer purchases of Azure IP co-sell eligible offers through Microsoft Marketplace draw down MACC; purchases of co-sell ready (but not Azure IP co-sell eligible) offers don’t. The same is true for CSP reseller transactions, which sit outside marketplace and don’t draw down MACC – the structural reason Multiparty Private Offers exist as a separate mechanism for channel-routed deals that need to preserve MACC drawdown.

The practical implication is that Azure IP co-sell eligible status is effectively the price of entry for enterprise Microsoft business. ISVs that hold co-sell ready but not Azure IP co-sell eligible status find their offers competing with MACC-eligible alternatives from competitors and losing on procurement-friction grounds even when the technical and commercial case is comparable.

A naming reminder: always use the platform-prefixed form (Azure MACC / Microsoft MACC) in external writing rather than the bare acronym. The unprefixed MACC is heavily contaminated in search by Malaysian Anti-Corruption Commission results, which makes both SEO targeting and customer-facing communication unreliable without the prefix.

ISV-hosted SaaS and MACC: the PRACR bridge. A specific MACC mechanics issue affects ISV-hosted SaaS ISVs whose workload runs in their own Azure tenant rather than the customer’s. It is understood that standard Azure Consumed Revenue tracking only sees consumption in customer tenants – consumption in the ISV’s own tenant is billed to the ISV rather than the customer, and is therefore not visible to the MACC drawdown system without an additional reporting mechanism. Without this additional mechanism, an ISV-hosted SaaS product’s Azure consumption cannot be credited against the customer’s MACC commitment even when the customer is paying for a product that drives significant Azure spend.

Partner Reported Azure Consumed Revenue (PRACR) is the mechanism that bridges this gap. It is a joint-sales reporting mechanism for focused partners with premier Azure SaaS solutions, aligning Microsoft field incentives with actual end-customer Azure consumption. Net-new partners must hold a certified software designation for Azure or an Industry AI designation on Azure, be approved as PRACR incentive eligible and submit eligible deal data through PRACR reporting in Partner Center using the required referral ID, Partner ID and subscription GUID fields.

The operational overhead is real: PRACR requires ongoing monthly submissions, active deal registrations in Partner Center and careful data hygiene (incorrect GUIDs, format errors and mismatched referral IDs all cause submission failures). It is not a set-and-forget mechanism. For ISV-hosted SaaS ISVs pursuing Azure IP co-sell eligible status, PRACR implementation should be planned and resourced from the outset rather than retrofitted after go-live. Full mechanics in ISV-Hosted vs Customer-Deployed and in the PRACR glossary entry.

The Preferred Solutions Badge

The Preferred Solutions badge is a quality signal Microsoft surfaces to customers within Microsoft Marketplace. Eligible offers receive a Microsoft preferred solutions badge on the offer listing page in Microsoft Marketplace. Microsoft describes the badge as promoting the offer’s quality, performance and ability to address customer needs in a specific industry vertical or solution area.

Eligibility requires either Azure IP co-sell eligible status or enrolment in ISV Success with co-sell ready status as a minimum. Once eligible, the badge applies to specific marketplace offers rather than to the partner as a whole – a partner with multiple offers may have some badged and some not.

Two practical notes. First, after an offer achieves Microsoft preferred solutions status, it might take up to 30 days for the badge to display in the online store. Second, the badge meaningfully affects marketplace discoverability for the relevant offers; partners report that badged offers see significantly higher marketplace transaction rates than eligible-but-unbadged offers in the same category.

Partner Center Referrals and Co-Sell Opportunities

Microsoft co-sell opportunities are managed in Partner Center under Referrals > Co-sell opportunities. Partners can view inbound opportunities, create outbound opportunities and create IP co-sell, Services co-sell, private and partner-to-partner opportunities. The system was previously known as Partner Sales Connect (PSC); that term remains in use informally among practitioners. Partner Center Referrals is the Microsoft equivalent of AWS’s ACE – the two systems serve similar purposes but have meaningfully different submission requirements and acceptance mechanics.

Partner Center co-sell opportunities require customer selection, deal details including estimated value and estimated close date, and the relevant Microsoft solution area and solution play. Opportunity stages map to Microsoft Customer Engagement Methodology (MCEM) stages in the workflow – but the stage is a workflow tool, not the primary submission field. Submissions that don’t map cleanly to MCEM stages can stall in handover to the customer-facing field; internal enablement on MCEM is therefore a prerequisite for credible submissions.

Co-sell opportunities flow in three directions:

Partner → Microsoft (outbound). The partner creates an outbound co-sell opportunity in Partner Center and can request Microsoft help. If help is requested, Microsoft sellers have a 14-day window to decide whether to participate, though participation is not guaranteed.

Microsoft → Partner (inbound). Microsoft shares a Microsoft-originated opportunity with the partner. Similar mechanic to ACE inbound: rarer than partner-originated outbound, but typically higher-quality because Microsoft has already qualified the customer need.

Partner → Partner (P2P). Partner-to-Partner opportunities allow one partner to invite another partner in the Microsoft co-sell ecosystem to collaborate on an IP co-sell or Services co-sell opportunity. A Microsoft seller can also be invited, provided the opportunity has not reached a terminal state.

ISV Success Program

ISV Success is a 12-month programme within Microsoft AI Cloud Partner Program for software development companies building B2B applications on or integrated with Microsoft Cloud. It supports partners in building well-architected applications, publishing to Microsoft Marketplace and growing sales, with commitments to start development within three months and complete development within 12 months. Benefits include Azure credits, technical consultations, application design and publishing support, developer tools and marketing assistance.

ISV Success is a well-established on-ramp for ISVs starting their Microsoft motion. Crucially, ISV Success enrolment also qualifies the partner for Preferred Solutions consideration – an indirect benefit that often goes unnoticed but matters for marketplace discoverability.

Practitioners familiar with the programme note that partners who arrive at ISV Success with Microsoft technical validation substantially complete tend to progress more smoothly; those who try to compress the technical validation work into the same window sometimes reach the marketplace listing milestone before completing the co-sell eligibility requirements. Sequencing the technical validation work matters.

Practical Co-Sell Workflow

The two directions of co-sell produce different starting points and different step sequences. They share a common closing motion once a joint pursuit is underway.

A note on classification. The hyperscaler’s inbound/outbound distinction and the ISV’s alliance-sourced/direct-sourced distinction are measuring different things and should not be conflated. Outbound (ISV creates opportunity in Partner Center) vs inbound (Microsoft shares to ISV) describes who entered the opportunity into the portal. Alliance-sourced vs direct-sourced describes who originated the relationship or pursuit that led to the opportunity. A common real-world pattern: the ISV alliance team sets a meeting with a Microsoft Solution Specialist or ATS, the conversation identifies a target customer and the Microsoft counterpart asks the ISV to “put something in the portal” – the result is an outbound Partner Center submission, but the opportunity was originated by the alliance team’s field engagement rather than the ISV’s direct sales motion. From Microsoft’s perspective it is outbound; from the ISV’s internal attribution system it is alliance-sourced. The two classifications are orthogonal and a deal can legitimately sit in any combination. ISV reporting that treats “outbound Partner Center submission” as synonymous with “not alliance-sourced” will systematically undercount the alliance team’s contribution. This is a specific and common variant of the attribution problem covered in Cloud Alliance Team and Co-Sell Operations.

The Private vs Partner-Led Decision

Every co-sell opportunity submission requires a visibility decision that determines whether the deal is a genuine co-sell submission or a pipeline-tracking entry. Partner Center presents a dropdown: “Identify the type of help you would like from Microsoft.” Selecting any active help option – workload-specific value proposition, customer technical architecture, proof of concept, and so on – immediately exposes a customer contact section and creates a co-sell submission visible to Microsoft sellers. Selecting “No help required at this point of time” reveals a second question: “Would you like Microsoft sellers to view this deal?” This defaults to Yes, creating a Partner-led deal – visible and actionable to the Microsoft field even without a specific help request. Changing it to No creates a Private deal – invisible to Microsoft Sales, used only for internal Microsoft reporting and forecasting.

For any Azure IP co-sell eligible deal, the correct answer is an active help type or, at minimum, “No help required” + Yes to visibility. The Microsoft AE on an incentivised co-sell deal has explicit quota motivation to see it close with the ISV’s product attached – they are a commercial ally, not a threat to the pipeline. Choosing Private is refusing help from someone who is paid to provide it.

Note that once a deal is set to Yes on visibility it cannot be changed back to No. Private deals can be upgraded into partner-led or active co-sell deals before the deal reaches a terminal state of won, lost, declined or expired.

ISV-Led Outbound

The ISV identifies an opportunity and brings it to Microsoft.

  1. Opportunity identification. The ISV’s sales team identifies a customer need involving Azure consumption. The alliance team reviews whether Microsoft engagement would meaningfully change the outcome – accelerating the deal, unlocking a customer introduction, providing technical validation or enabling MACC-eligible marketplace routing. Opportunities where Microsoft engagement adds nothing are run as direct deals and not submitted to Partner Center.
  2. Partner Center referral. The ISV creates the opportunity in Partner Center with customer selection, estimated value, estimated close date, relevant solution area and solution play. Opportunity stages map to MCEM stages in the workflow. The visibility setting must be set correctly; see The Private vs Partner-Led Decision above.
  3. Microsoft response. When Microsoft help is requested, Microsoft sellers have a 14-day window to decide whether to participate. Opportunities can be accepted or declined; they expire if no response is provided within the required period. The acceptance mechanic is more variable than ACE – routing through ATS or Solution Specialist can produce slower initial response than PDM-routed submissions but typically yields more substantive engagement on accepted opportunities. Declines should be diagnosed before the next submission.
  4. Joint pursuit. The ISV and Microsoft work the deal together. Solution Specialists or CSAs typically lead Microsoft-side engagement; the ATS stays informed but is rarely the primary working contact. The ISV provides product expertise, proof-of-concept support and customer relationship continuity.
  5. Marketplace transactable offer. For MACC-eligible marketplace deals, the customer purchases an eligible offer through Microsoft Marketplace or Marketplace in Azure portal, and the invoiced amount decrements the customer’s MACC. Azure IP co-sell eligible status is required for a Microsoft Marketplace offer to be MACC eligible. For non-MACC deals (CSP-routed, traditional invoicing), the marketplace path doesn’t apply.
  6. Close and attribution. Closed-won status updated in Partner Center. The deal flows into Microsoft’s reporting (ATS / AE quota retirement and the ISV’s Solutions Partner designation renewal counters) and into the ISV’s CRM and alliance comp infrastructure. It is understood that on a Private deal, the Microsoft AE receives no quota retirement credit and the PDM receives no partner-attribution credit – which means the ISV forfeits the relationship capital that a co-sold closed-won deal would otherwise have built. Closed-loop attribution discipline keeps the two systems in sync. Detail on attribution mechanics in Co-Sell Operations.

Microsoft-Led Inbound

Microsoft identifies an opportunity and brings it to the ISV. The inbound flow is simpler by design: Microsoft has already qualified the customer need before making the introduction, so the ISV qualification step largely collapses.

  1. Microsoft origination and introduction. A Solution Specialist, ATS or CSA identifies a customer need that includes the ISV’s product and shares the opportunity through Partner Center or makes a direct introduction. The qualification step is substantially done by Microsoft at this point – the customer problem is real, the fit has been assessed and the Microsoft field is prepared to advocate for the ISV.
  2. ISV acceptance and response. The ISV accepts the opportunity in Partner Center and responds promptly. As with AWS inbound, the triage model from Hyperscaler Co-Sell applies: Solution Specialist or CSA-originated inbound warrants immediate senior response; PDM-originated inbound warrants standard qualification.
  3. Joint pursuit, marketplace transaction, close and attribution. Same as steps 4–6 of the outbound flow above.

Tooling

Microsoft co-sell tooling sits across three layers:

Microsoft-native tooling. Partner Center is the system of record. MCEM is the methodology model Microsoft expects opportunities to be expressed in. Cloud Ascent and Customer Insights are Microsoft-side intelligence tools that surface customer-segment and consumption data to the field; partners with strong PDM relationships sometimes get access to relevant Cloud Ascent outputs.

ISV-side CRM. Salesforce or HubSpot, holding source-of-truth account and opportunity data. Microsoft has invested in Partner Center APIs and the integration is increasingly capable, though bidirectional sync between Partner Center and CRM is in practice non-trivial.

Third-party Cloud GTM Platforms. Clazar, Labra, Suger and Tackle (acquired by AppDirect, December 2025) each support Microsoft-side automation including Partner Center↔CRM sync and marketplace operations. Cited as a category, no endorsement. Detail on build-vs-buy in Co-Sell Operations.

Common Pitfalls

Patterns that recur in Microsoft co-sell motions of all sizes:

  • Submitting deals as Private when co-sell engagement is the goal. When “No help required at this point of time” is selected, Partner Center reveals a second question: “Would you like Microsoft sellers to view this deal?” The default is Yes (Partner-led – visible to Microsoft field); selecting No creates a Private deal, invisible to Microsoft Sales and used only for internal reporting. The motivation for selecting No is usually pipeline paranoia, sometimes driven by sales leadership uncomfortable with Microsoft having visibility into active pursuits. The concern is understandable in the abstract – sharing pipeline with a hyperscaler who could theoretically engage the customer directly. In the Microsoft co-sell context it is almost entirely misplaced: the Microsoft AE on an Azure IP co-sell eligible deal has explicit quota incentive to see the deal close with the ISV’s product attached. They are not a threat to the pipeline; they are a commercial ally with reasons of their own to want the same outcome. Choosing Private on an incentivised co-sell deal is refusing help from someone who is paid to provide it. The consequences of a closed-won Private deal deserve to be stated plainly. It is understood that the Microsoft AE receives no quota retirement credit and the PDM receives no partner-attribution credit. Nobody in the Microsoft field has any record of the ISV closing business on their platform. From their perspective, nothing happened. The ISV received revenue; Microsoft received nothing attributable. The next time the ISV approaches the same account team for support on a new pursuit, they arrive with no history of delivering – no closed deal the AE can point to internally when advocating for the ISV’s inclusion in a customer conversation. The relationship capital that a co-sold closed-won deal would have built has been entirely forfeited. Across a pipeline of deals, a pattern of Private submissions compounds: the ISV looks, from the inside of Microsoft’s systems, like a company that closes business despite Microsoft rather than with them. The workable compromise for teams facing internal resistance is “No help required” + Yes to visibility: the deal remains visible and actionable to the Microsoft field, while the sales team gets their preferred “No help required” framing. Once a deal is set to Yes on visibility it cannot be changed back to No. Alliance teams should have explicit written guidance on the correct visibility setting for each deal type and should audit submissions regularly to catch deals filed as Private by default.
  • Co-sell ready but not Azure IP co-sell eligible. The most significant gap. Partners that reach co-sell ready and assume the meaningful enterprise mechanics are unlocked are operating below the structural threshold. Without Azure IP co-sell eligible status, offers don’t count toward customer MACC drawdown and enterprise traction is by design limited.
  • Missing the Preferred Solutions display lag. After an offer achieves preferred solutions status, it can take up to 30 days for the badge to appear in the online store. Account for this in launch planning.
  • Not linking opportunities to transactable marketplace offers. Particularly for ISVs that haven’t yet built the marketplace operational discipline. Partner Center submissions that don’t route to MACC-eligible transactions mean Microsoft seller incentives don’t fire, which reduces AE engagement on subsequent pursuits.
  • Ignoring the Solution Assessment motion. Microsoft’s Solution Assessment programme (a related but distinct motion to Partner Center opportunity sharing) provides funding for customer-side assessments that often precede ISV adoption pursuits. Partners that ignore Solution Assessment miss a meaningful funded-discovery channel.
  • PDM-first engagement for customer-deployed products. The default ISV assumption is that the PDM is the primary engagement layer. For customer-deployed products this is wrong on Microsoft as it is elsewhere – the leverage sits with ATS, Solution Specialists and CSAs. See ISV-Hosted vs Customer-Deployed.
  • MCEM-stage expression failures. Partner Center submissions that don’t map cleanly to MCEM stages stall in handover. Internal enablement on MCEM is the prerequisite for credible submissions.

What This Looks Like in Practice

A composite example, drawn from patterns across multiple real situations.

A data-analytics ISV with $50M ARR began Microsoft co-sell as the third hyperscaler motion (after AWS and Google Cloud). The starting state was a Microsoft Solutions Partner designation in Data & AI earned in 2024, but no transactable marketplace offer and no active Partner Center co-sell presence.

Month 1–3: ISV Success enrolment. Marketplace offer creation in flight. Microsoft technical validation scoped (deferred until month 4 because of internal engineering capacity constraints). First PDM rhythm established. End-of-quarter state: co-sell ready achieved, marketplace offer live but not yet transactable, technical validation at 40% complete.

Month 4–6: Technical validation completed. Marketplace offer upgraded to transactable. Azure IP co-sell eligible status earned month 5. Preferred Solutions badge applied within 30 days. First Partner Center co-sell opportunities submitted – mostly partner-led, with two early Microsoft-originated leads coming through the PDM relationship.

Month 7–12: motion maturing. First Microsoft Marketplace transaction (a renewal of a pre-existing customer routed through MACC drawdown) closed in month 8. First non-renewal Microsoft Marketplace transaction in month 10. Co-sell opportunity acceptance rate at ~55% by end of year one. The ATS at one strategic financial-services customer became a sustained engagement point; the relationship produced two AE-originated opportunities by month 12. Total Microsoft pipeline contribution at month 12: ~$3.2M, with $850k of marketplace transactions across the year.

The diagnostic insight from the rebuild was the structural value of MACC. Customers that had previously evaluated the ISV’s product through traditional procurement channels and stalled became significantly easier to close once a MACC-drawdown path through marketplace was available. The procurement-friction reduction was the real lever, not the marketing badge that came with the program enrolment.

Where to Go Next

Within this pillar:

  • AWS Co-Sell – the equivalent operating manual for AWS.
  • Google Co-Sell – the equivalent for Google Cloud, including the Q1 2026 Partner Network reset.
  • Co-Sell Operations – the tooling and attribution infrastructure that supports Microsoft co-sell at scale, including Partner Center↔CRM bidirectional sync, the PSC/Referrals submission schema and conflict-resolution rules.

Adjacent:

The full series glossary is at Glossary.

External References

Vendor Primary Sources

Practitioner Models and Industry Commentary

These sources are influential within the cloud-GTM practitioner community but published from a commercial or advisory vantage point. Cited with attribution.

  • AchieveUnite’s Hyperscaler Fit – practitioner taxonomy and dual-PDM framing that anchors the PDM-vs-customer-facing-field distinction on Microsoft.
  • CONNACT – Co-Selling Roles and Responsibilities. Practitioner overview of hyperscaler co-sell roles and engagement mechanics. Note: the author has a professional relationship with CONNACT; see the series disclosure on the hub page.

Sources

Verified primary sources used in the factual verification pass for this article.

Last reviewed: 2026-07-01. Vendor-specific clusters in this series are reviewed twice yearly after Microsoft Ignite (late November / early December) plus mid-cycle for major program changes. Major changes between reviews are flagged in the Updates section below.

Updates

(No updates yet. This section will record dated corrections, program changes between reviews and community-contributed clarifications as they arrive.)

© Chris Buckel / flashdba. Part of the Hyperscaler GTM Playbook. If you quote or reproduce this content – in writing or as material for AI systems – please attribute it to Chris Buckel / flashdba.com and link to the source. Full disclosure and terms: flashdba.com/about/legal/.