Hyperscaler Co-Sell: The Complete Guide to Selling With AWS, Azure and Google Cloud

Most ISVs know they should be co-selling with AWS, Microsoft or Google Cloud. Far fewer have a co-sell motion that actually produces revenue. The gap between the two is almost always the same set of structural problems – and they are solvable. This guide covers what co-sell actually is, how it works across the three hyperscalers and what a working motion looks like in practice.

TL;DR

• Hyperscaler co-sell – or cloud co-sell – is the joint selling motion between an ISV and one or more hyperscalers (AWS, Microsoft Azure, Google Cloud) around a shared end customer. It is fundamentally different from sell-to (you sell directly to an end customer with no intermediary), sell-through / resale (a partner buys from you and resells to the end customer) and the marketing notion of sell-with (joint awareness or demand generation activity with a partner, without a joint sales motion).
• The dominant procurement driver is committed-spend drawdown. Customers with EDPs (AWS), MACCs (Microsoft) or eligible Google Cloud Minimum Commitment obligations prefer to spend pre-committed cloud budget through marketplace rather than open new procurement. This is why co-sell and marketplace are inseparable.
• Co-sell flows in two directions: partner-led (you bring the deal to the hyperscaler) and hyperscaler-led (the hyperscaler brings the deal to you). The operational infrastructure most ISVs build first – ACE submissions, PSC workflows, pipeline tracking – supports the first motion. Building the AE readiness and internal governance to convert hyperscaler-led opportunities is a separate and often later investment. It is typically where the greater leverage sits.
• A hyperscaler’s field organisation has five distinct layers, each with different incentive structures and different ways of being engaged. Which layers you over-index on depends heavily on whether your product runs in your own cloud account or your customers’ – see ISV-Hosted vs Customer-Deployed.
• Seven building blocks separate a working co-sell motion from a noisy one: opportunity-sharing system access, co-sell-ready solution status, account mapping, joint value proposition, PDM relationships, field enablement and closed-loop attribution. Missing any one of them produces a recognisable failure mode.

What Co-Sell Actually Means

Cloud co-sell is a joint selling motion between an ISV and a hyperscaler around a shared end customer. The structural distinction from other commercial motions matters because the practitioner vocabulary collapses them in ways that confuse first-time entrants.

Sell-to. Selling directly to an end customer with no intermediary. A real commercial motion, but not co-sell and not the subject of this series.

Sell-through / resale. A channel partner – typically an SI, MSP or distributor – takes the ISV’s product, marks it up and resells it to end customers. The economics flow through margin. AWS’s CPPO, Microsoft’s MPO and Google’s channel-partner private offer are the marketplace-routed variants of this motion. Pure resale – where the channel partner transacts independently of any hyperscaler co-sell motion – is not co-sell. The distinction blurs in multi-party private offers (CPPO, MPO), where a channel-resale transaction and a co-sell motion are combined in a single marketplace transaction.

Sell-with / co-sell. The ISV sells its product directly to an end customer, with the hyperscaler actively engaged in the pursuit – introducing the partner, providing field support, validating the technical fit, sometimes funding the proof of concept and (in marketplace-routed deals) processing the transaction. The hyperscaler is not selling the ISV’s product on the ISV’s behalf, and is not buying the product itself. The hyperscaler is acting as a sales-influence amplifier whose commercial interest is the cloud consumption the resulting deal drives.

That third motion – co-sell – is what this pillar is about.

AchieveUnite’s Hyperscaler Fit practitioner taxonomy develops this framing at more length. The practitioner shorthand most often heard at conferences is “sell-with motion,” but the precision matters: a sell-with conversation that doesn’t include the hyperscaler’s named field counterparts and doesn’t drive cloud consumption isn’t co-sell, it’s adjacent.

A brief history. Cloud co-sell is a young discipline. Public cloud computing dates to 2006 (AWS S3 and EC2); structured co-sell programs arrived more than a decade later. It is understood that Microsoft launched its IP Co-sell programme publicly in 2017 – having already run it as a pilot – making it the originating programme in the space. AWS followed with ISV Accelerate in 2019; Google’s equivalent co-sell infrastructure developed later still. The tooling, the practitioner vocabulary and the operational playbooks that now exist have almost all been built since 2019. This matters for two reasons: it explains why so much institutional knowledge is undocumented and why so many sales leaders – even experienced ones – have limited exposure to it; and it means the discipline is still evolving fast enough that content written two years ago may already be significantly out of date.

Why the Customer Wants This

The structural reason co-sell works is that the customer wants it. Specifically, the enterprise customer wants to spend committed cloud budget rather than open new procurement.

Almost every enterprise cloud customer of meaningful size has a committed-spend agreement in place with one or more hyperscalers. The mechanisms differ: AWS calls them Enterprise Discount Programs (EDP); Microsoft calls them Microsoft Azure Consumption Commitments (MACC); Google Cloud marketplace drawdown is described against Minimum Commitment obligations, and Google’s MCCP is a separate Marketplace Customer Credit Programme. All three mechanisms work the same way at the customer’s procurement desk: the customer has pre-paid for a fixed level of cloud spend and is more willing to spend it than to open a new procurement budget.

This changes the customer’s preferred buying motion for third-party software. The traditional motion – legal review, procurement intake, vendor onboarding, finance approvals, separate invoicing – is in practice heavy. The marketplace-routed motion – select the product, click to subscribe or accept a private offer, transaction draws against committed cloud spend, single invoice from the hyperscaler – is in practice light. For customers, the difference is measured in weeks of saved cycle time and meaningful procurement-overhead reduction.

The data on the resulting shift is consistent across the named sources tracking it. Omdia partner-channel research (including research formerly published under the Canalys brand, which Omdia acquired in 2023) suggests partners are forecast to manage a growing majority of public cloud spend. AWS’s own ISV Accelerate data shows that 51% of ISV Accelerate partners report higher average revenue growth as a result of co-sell motions. Omdia’s AWS Partner Ecosystem Multiplier 2025 Study, cited by AWS, puts the figure at up to US$7.13 in services revenue for every US$1 of AWS technology sold. Tackle’s annual State of Cloud GTM report tracks the marketplace-as-procurement transition through three years of survey data showing it accelerating from niche to default. Treat the specific numbers as directional (the practitioner-cited-not-verified caveat is developed at more length in Cloud Alliances); the consistent direction across the named sources is the finding that matters.

For ISVs, the practical implication is that ignoring co-sell increasingly means ignoring the buying motion the customer prefers. The customer who would once have started procurement with a vendor evaluation now starts with “is this on marketplace?” Co-sell is the motion that puts you there with hyperscaler-side support.

The Two Directions of Co-Sell

Co-sell flows in two directions, and most ISVs run only one of them well.

Partner-led. You bring a deal to the hyperscaler. You have a customer relationship, you have an active pursuit and you share the opportunity with the hyperscaler through ACE / PSC / the Google partner portal in the hope of pulling in hyperscaler field support, marketplace routing, MDF funding or technical validation. The partner is the originator; the hyperscaler is the support function.

Hyperscaler-led. The hyperscaler brings a deal to you. A hyperscaler AE is working a customer pursuit and identifies that the ISV’s product is part of the solution. The AE engages the ISV directly (or via the ISV’s PDM) to bring them in. The hyperscaler is the originator; the ISV is the technology supplier.

The operational infrastructure most ISVs build first – ACE submissions, PSC workflows, pipeline tracking – supports the first motion. Building the AE readiness and internal governance to convert hyperscaler-led opportunities is a separate and often later investment. It is typically where the greater leverage sits.

The asymmetry has a structural explanation. Hyperscaler-led co-sell depends on the AE’s behaviour, not the ISV’s, and the AE has a hundred ISVs competing for inclusion in their pursuits. Earning a place in the AE’s mental list of “ISVs I bring into deals” is harder than running an ACE submission process. It requires consumption-uplift evidence (per ISV-Hosted vs Customer-Deployed), pre-built customer-facing materials, named-account joint planning and the kind of trust that takes time to build.

The conversion economics are completely different: hyperscaler-led pipeline often converts at significantly higher rates than partner-led pipeline because the customer arrives pre-qualified in a meaningful way – the hyperscaler has typically exhausted its own native solution options before bringing in a third party, which means the problem is real, documented and technically understood. The full mechanism is explained in Cloud Alliance Team.

The two profiles of hyperscaler-led inbound. Not all hyperscaler-led opportunities are equivalent. The profile depends on who is bringing it and, critically, on the ISV’s tenancy archetype.

Account team or CS-led inbound, typically for customer-deployed ISVs. This is the highest-value category and the one with the most distinctive commercial profile. By the time a hyperscaler’s customer-facing AE or customer success team brings an ISV into a pursuit, they have typically already attempted to solve the customer’s problem using every tool available to them – first-party solutions, other third-party products, internal professional services. The ISV is being brought in because nothing else worked. The implications are significant: the customer’s problem is not only real but technically documented; both the hyperscaler and the customer have a detailed understanding of the constraints involved; and the urgency is often acute. The customer may be exasperated. The hyperscaler’s CS team may have C-Sat exposure. These opportunities arrive fast and demand an immediate response – the ISV that responds with the right preparation and the right people can move from first conversation to signed POC in days. The ISV that treats this as a routine inbound will not get a second chance.

A composite illustration, drawn from patterns across multiple real situations: a customer-deployed infrastructure ISV received an out-of-hours message from a hyperscaler customer success engineer on a Sunday evening. The customer – a financial services firm – had a critical workload performance problem that the hyperscaler’s own tooling had failed to resolve over multiple quarters. The CS team had exhausted their internal options and had explicit C-Sat pressure. The ISV’s alliance manager and a technical SE responded immediately, attended the Monday morning call fully prepared with a pre-built technical narrative matched to the specific workload profile, and were in a paid proof of concept by the following week. The deal closed within a month. The account subsequently became the ISV’s largest in the region and the hyperscaler account team became active advocates for the ISV within the hyperscaler field organisation.

The relationship asymmetry. There is a structural reason why hyperscaler-led co-sell matters disproportionately for early-stage and smaller ISVs, and it is worth naming directly. If you are reading this playbook, you are almost certainly many orders of magnitude smaller than your chosen hyperscaler. That size difference has a specific consequence when the prospective customer is a large enterprise.

The AWS, Microsoft or Google AE on a Fortune 1000 account has typically spent years building a strategic relationship with that account. They have deep knowledge of the customer’s technology plans, internal politics, budget cycles and executive priorities. They have access to senior stakeholders that no ISV sales team – however well-hired – can easily match, because the ISV’s business simply cannot mean as much to that enterprise as Microsoft’s or AWS’s does. A hyperscaler AE on a major financial services account may have a relationship with the CIO that took a decade to build and is reinforced by hundreds of millions of dollars of annual spend. An ISV AE on the same account is, by comparison, a newer relationship with a smaller stake. This is a specific and underappreciated advantage of hyperscaler co-sell for ISVs targeting enterprise accounts: the hyperscaler’s existing relationships open doors that the ISV’s direct sales motion would take years to open independently, if at all.

The flip side is equally real. If the prospective customer is smaller – commercial or mid-market rather than enterprise, or a large company that happens to be a minor spender on a particular cloud – the relationship dynamic reverses. A hyperscaler covering 20–30 accounts in a commercial segment has limited capacity for any individual customer. The ISV, whose product may be more directly relevant to that customer’s problem, can build a closer and more trusted relationship than the hyperscaler AE who isn’t sufficiently present or motivated to be. ISV reps in commercial and mid-market segments often find that helping a customer navigate the hyperscaler – translating program mechanics, connecting them to the right technical resources, advocating for their account internally – creates a level of trust that a stretched hyperscaler AE cannot replicate.

One further nuance: a company’s size and a hyperscaler’s investment in that company are not the same thing. A billion-dollar business whose cloud spend is concentrated on two of the three hyperscalers may be a minor account on the third, and that hyperscaler will allocate sales resources accordingly. Being enterprise-sized does not guarantee enterprise-level hyperscaler attention on every cloud. The ISV that understands this can identify accounts where the hyperscaler’s coverage is thin relative to the customer’s actual scale – and where the ISV’s own relationship-building therefore has disproportionate value.

The operational implication is a triage model, not a uniform response policy. Inbound should be categorised by source before resources are allocated: CS or account-AE originated inbound warrants immediate response and senior team involvement; PDM-originated inbound warrants a standard qualification process. Treating both categories identically underserves the first and over-invests in the second. The detailed triage mechanics and the readiness infrastructure needed to respond effectively to high-urgency inbound are covered in Co-Sell Operations.

PDM-led inbound, typically for ISV-hosted SaaS partners. A different category entirely. PDMs are measured on partner-program participation, pipeline activity and marketplace metrics. An opportunity brought by a PDM may be early-stage, lightly qualified and not urgent from the customer’s perspective. The PDM is doing their job; that doesn’t mean the customer has a burning problem or that the ISV should treat this as a drop-everything situation. Standard qualification discipline applies.

If the opportunity is not a good fit, the response matters as much as the qualification decision itself. The PDM has invested relationship capital in making the introduction; a half-hearted call that goes nowhere, followed by silence, communicates that the ISV is not a reliable partner for their referrals. Repeat this two or three times and the PDM quietly stops making introductions – not because of any explicit decision, but because the pattern tells them that investing in the ISV produces nothing. Disengagement by attrition is one of the most common ways a PDM relationship dies, and it is almost always avoidable.

The discipline is to close the loop directly: a short debrief with the PDM after every introduction, whether or not the opportunity progresses. If the fit is wrong, explain why clearly and specifically – the product isn’t relevant to this customer’s workload, the deal size is below the ISV’s commercial threshold, the customer is too early in their cloud journey. Specific feedback helps the PDM calibrate future introductions. Generic feedback (“not the right fit at this time”) helps no-one. The PDM who receives consistent, honest, specific feedback on their referrals will over time become a more accurate and more valuable referral source.

The ISVs that get hyperscaler-led co-sell right tend to have invested in it deliberately for two to three years. The ISVs that get only partner-led co-sell right tend to produce predictable but capped pipeline volumes. The most mature ISVs operate both, with different motions and different team structures behind each.

The Five Layers of Co-Selling at a Hyperscaler

A hyperscaler’s field organisation is not a single layer of “field reps.” It has five distinct layers, each with different incentives and different engagement mechanics.

1. Executive and industry leads. Senior leaders responsible for industry verticals (financial services, healthcare, public sector, retail), large customer segments or named strategic accounts. KPIs: industry revenue growth, strategic account expansion, named-customer references at industry events. Engagement: high-leverage, low-frequency – an industry-lead relationship can shape multi-quarter customer pursuit lists but requires significant ISV-side investment in industry credibility (named customers, industry-specific value propositions, regulatory evidence). The right access is usually through senior alliance leadership or executive-to-executive engagement, not via individual AE relationships. Operational implication: don’t try to access industry leads cold; invest in industry credibility first, then broker the relationship through senior-alliance-to-senior-alliance introductions on a multi-quarter cycle.

2. Regional and segment leadership. Theatre and area leaders responsible for AMER, EMEA, APJ (or equivalent), often sliced further by customer-segment band (enterprise, commercial mid-market, SMB). KPIs: regional revenue growth, segment-specific consumption, named partner contribution to regional pipeline. Engagement: rhythm-driven – quarterly or monthly check-ins focused on regional pipeline health, partner-attach rates and joint pursuits. Operational implication: invest in formal QBR-rhythm engagement once your regional pipeline justifies it; expect this layer to be slow to engage and high-leverage once engaged.

3. Account relationship owners. The customer-facing field members who own the named account relationship: the AE and ATS equivalents at each hyperscaler, the CSM post-sale layer, and the CSA customer success technical layer on Microsoft. These are the people who own the customer – they manage the overall commercial relationship, hold the account plan, and are the “front door” to any named account. KPIs: customer cloud consumption growth, customer commitment retirement, marketplace transactions, customer retention. Engagement: account-by-account – the working unit is a named customer relationship and the rhythm is whatever the customer pursuit requires. Operational implication: this layer is the right entry point for opening a new named account relationship. For customer-deployed ISVs, it is necessary but not sufficient – the specialist layer (below) is where workload-specific engagement happens.

4. Specialist and solution teams. Technical and commercial specialists organised by workload domain – data and analytics, AI / ML, security, infrastructure, modernisation, agentic AI (a 2026-vintage category). These are the people who own the workload: Microsoft’s STU (SSP and TSP roles), AWS’s specialist SA pools, Google Cloud’s specialist CE teams. Specialists are deployed onto accounts where their domain is the centre of gravity; they are not account owners but they carry workload-specific quota and are directly incentivised to solve workload problems. This is the layer that matters most for customer-deployed ISVs – see ISV-Hosted vs Customer-Deployed. KPIs: workload-specific consumption growth, solution-area customer references, technical validation contribution. Engagement: workload-led – specialists join pursuits where their domain is relevant and tend to be the most receptive to ISVs whose products solve well-defined workload problems with measurable consumption outcomes. They encounter third-party-solution requirements more directly than account relationship owners, and they have quota incentive to act on them. Operational implication: for customer-deployed ISVs, specialist teams are often both the primary source of hyperscaler-led inbound and the most productive engagement target for partner-led co-sell. Invest in named relationships with the relevant specialist by workload domain, not just with the account AE or PDM.

5. Partner-program owners (PDMs and their leadership). The partner-side org that runs the formal partner program, manages partner-tier progression, owns the marketplace partner relationship and operates the opportunity-sharing systems. KPIs: partner-side metrics – partner consumption, marketplace transaction volume, partner-program participation, partner-program revenue. Engagement: program-driven and relationship-driven – the PDM is the natural primary champion for ISV-hosted SaaS partners and the structural choke point for customer-deployed partners. Operational implication: ISV-hosted SaaS partners should over-index here as their primary engagement layer; customer-deployed partners should treat PDM relationships as necessary-but-not-sufficient and concentrate effort on layers 3 and 4 instead.

Note: AWS also has a Partner Sales Manager (PSM) role that sits adjacent to this layer but operates more like layer 3 – the PSM owns partner-attached revenue and co-sell pipeline on named accounts and has direct quota incentive to see partner-involved deals close. The PSM is typically a more commercially motivated co-sell engagement target than the PDM for ISVs pursuing named enterprise accounts on AWS. Microsoft had a comparable role (the Enterprise Channel Manager) but eliminated it in early 2023; Google Cloud has no direct equivalent. See AWS Co-Sell for the full PSM treatment.

The default ISV assumption is that the PDM is the primary engagement layer. For ISV-hosted SaaS partners this is correct. For customer-deployed partners it is wrong – the PDM’s incentives don’t align well with the partner’s consumption pattern, and the leverage instead sits with layers 3 and 4 (account relationship owners and specialists). The mismatch between assumed and actual engagement layers is one of the most significant errors in cloud co-sell. The definitive reference is ISV-Hosted vs Customer-Deployed.

Co-Sell Building Blocks

A working co-sell motion needs seven building blocks. Missing any one of them produces a recognisable failure mode.

1. Opportunity-sharing system access. Active accounts in ACE (AWS, via Partner Central), PSC (Microsoft, via Partner Center) and Google’s partner portal. Not just enrolled – actually used, with hygiene practices in place (submission quality, follow-up rhythm, acceptance-rate tracking).

2. Co-sell-ready solution status. The formal program status that gates eligibility for AE incentives and marketplace mechanics. AWS’s ISV Accelerate (ISVA), Microsoft’s Azure IP Co-Sell Eligible (with ISV Success as the on-ramp) and Google’s Co-sell Partner path with marketplace listing and Architecture Review passed. Detail in Cloud Partner Programs and Specialisations.

3. Account mapping. Comparing the ISV’s customer and prospect list against the hyperscaler’s customer list to find overlap. Done badly: a spreadsheet manually maintained by the alliance team that ages out within a quarter. Done well: a tooled process running quarterly, with named-account joint pursuit lists falling out of the overlap. The leverage from account mapping compounds with every quarter it runs.

4. Joint value proposition / better-together story. A short, named-customer-flavoured narrative that articulates why a customer benefits from buying the ISV’s product and using the hyperscaler’s platform together rather than either in isolation. For customer-deployed products, this needs to lead with consumption-uplift evidence per ISV-Hosted vs Customer-Deployed. For ISV-hosted SaaS, it leads with marketplace-routing benefits and joint workload completeness.

5. PDM relationships. Named PDM at each engaged hyperscaler, with a working rhythm (typically weekly or fortnightly for primary clouds, monthly for secondary). The PDM is the gateway for ISV-hosted SaaS partners and the partner-program coordinator for customer-deployed partners. Even when the PDM isn’t your primary co-sell engagement layer, the relationship is the gate for partner-program benefits, MDF funding and formal escalations.

6. Field enablement. The ISV’s own sales team needs to know how to operate inside hyperscaler co-sell motions – what to share through opportunity systems, when to invoke a hyperscaler-side counterpart, how to structure a marketplace-routed deal. Without internal enablement, the alliance function generates co-sell-eligible opportunities that direct sales then fails to capitalise on.

7. Closed-loop attribution. Tracking co-sold deals from origination through to closed-won and back into both the ISV’s and the hyperscaler’s systems. Without it, alliance comp can’t be calculated cleanly, hyperscaler-side reporting drifts and renewal-cycle funding decisions lose the consumption-outcome evidence that drives them. Detail on attribution mechanics in Co-Sell Operations.

A useful diagnostic: if any of these seven building blocks is missing or weak, the team’s energy will flow toward it whether or not anyone has decided that’s where the work should be. Co-sell motions are remarkably good at self-revealing the bottleneck.

The Three-platform Comparison

The high-level orientation. Detail per platform sits in AWS Co-Sell, Microsoft Co-Sell and Google Co-Sell.

Dimension	AWS	Microsoft	Google Cloud
Co-sell program name	ISV Accelerate (ISVA)	Azure IP Co-Sell Eligible (entry via ISV Success)	Co-sell Partner path
Pipeline-sharing system	ACE, inside Partner Central	PSC, inside Partner Center	Google Cloud partner portal (lighter tooling)
Methodology / sales process	AWS-flavoured pipeline stages	MCEM (Microsoft Customer Engagement Methodology)	Google’s customer-journey model
Field-org structure	AE / SA / ISV-PDM / specialist sellers / industry leads	ATS / CSA / Solution Specialists / PDM / industry leads	FSR / CE / specialist sellers / PDM / industry leads – customer-segment vs partner-segment orgs unusually distinct
Pre-committed spend mechanism	EDP	MACC	CUD / MCCP
SaaS bridge mechanic	SaaS Co-Sell Benefit – AE quota retirement on marketplace-routed SaaS	Multiple mechanisms; less single authoritative example	Less developed; bridged through PDM advocacy
Term for customer’s cloud environment	Customer account	Customer tenant	Customer project (sometimes customer organisation)
2026 vintage	Continued ISVA expansion; new agentic AI partner categories	Continued MAICPP / ISV Success refinement	Complete program reset in Q1 2026

Three patterns emerge from the comparison. First, the operating mechanics are recognisably similar across the three platforms – pipeline-sharing system, formal co-sell-eligible status, technical validation, marketplace transaction structures – but the names and the systems are different enough that practitioner translation between platforms is a real (and underestimated) cost. Second, AWS and Microsoft have more developed tooling and more mature systems; Google’s tooling is lighter and more AE-mediated, which has implications for how Google co-sell teams should be staffed. Third, all three platforms had material structural updates in 2025–2026; pre-2025 practitioner knowledge of any of them should be revalidated.

Co-Sell Readiness Checklist

Before initiating a co-sell motion on any platform, the alliance function should be able to answer “yes” to most of the following. The checklist is the same across hyperscalers; the specifics differ.

• [ ] Marketplace listing live and transactable (SaaS, AMI / VM or container as appropriate for tenancy archetype).
• [ ] Technical validation passed and current (FTR for AWS, Well-Architected Review for Microsoft, Architecture Review for Google).
• [ ] Co-sell-eligible program status earned (ISVA / Azure IP Co-Sell Eligible / Co-sell Partner path).
• [ ] Opportunity-sharing system access configured (ACE / PSC / partner portal) with clear internal submission criteria.
• [ ] Named PDM relationship with established working rhythm.
• [ ] Joint value proposition / better-together story produced, with at least one named customer reference per priority workload.
• [ ] Account mapping performed against the hyperscaler’s customer list, with target-account joint pursuit list defined.
• [ ] Internal sales-team enablement complete: direct AEs know how to invoke hyperscaler counterparts and how marketplace transactions affect their comp.
• [ ] Comp structure for alliance and direct sales defined and documented, with credit-sharing rules for influenced and sourced deals.
• [ ] Attribution and reporting infrastructure operational: deals can be tracked from origination through to closed-won across both ISV and hyperscaler systems.

Missing any item on this list significantly increases the probability of co-sell motion underperformance. Most ISVs starting from a near-zero baseline will miss four or five items on first audit; bringing them all to “yes” status typically takes six to nine months and is the precondition for the co-sell motion producing meaningful pipeline.

Co-Sell Maturity Stages

What does co-sell look like at different stages of maturity? The shape progresses through known states:

Month 1. Initial program enrolment underway. Marketplace listing in development. First PDM relationship established but transactional. No opportunity-sharing flow operational. Internal sales team unaware of co-sell mechanics. Expected pipeline contribution: zero.

Month 3. Marketplace listing live. First technical validation submitted (likely not yet passed). Co-sell-eligible program status in flight. First ACE / PSC / partner-portal submissions made. PDM rhythm established. Expected pipeline contribution: minimal, mostly retrospective routing of pre-existing pipeline through co-sell systems.

Month 6. First technical validation passed. Co-sell-eligible status earned on primary cloud. Opportunity-sharing operational at low volume with growing acceptance rate. First named-customer joint pursuit underway. First marketplace transaction closed (likely a renewal of pre-existing direct customer business routed through marketplace, which is expected and not a failure). Expected pipeline contribution: 5–10% of new business in the engaged hyperscaler’s customer footprint.

Month 12. Specialisation earned where applicable. Multiple named-customer joint pursuits in flight. ACE / PSC acceptance rate at 50%+. Marketplace transactions running at a consistent cadence – five to ten per quarter is a reasonable marker for a mid-sized SaaS ISV, though infrastructure and enterprise ISVs with high average deal sizes will be at this milestone at materially lower transaction counts. Field-enablement programs operational; direct AEs are no longer surprised when co-sold deals appear. Expected pipeline contribution: 15–25% of new business in engaged segments.

Month 18. Second cloud at the month-6 stage in parallel. First-cloud motion compounding: PDM relationships producing pre-emptive referrals, AE relationships producing hyperscaler-led pipeline rather than only partner-led. Industry-specialist relationships developing. Expected pipeline contribution: 25–40% of new business in mature segments.

Month 24+. Mature multi-cloud co-sell function, with all five engagement layers active, hyperscaler-led pipeline running at parity or higher with partner-led, mature attribution and comp infrastructure, joint account plans on top-50 to top-100 named customers. Expected pipeline contribution: 40–60% of new enterprise business.

These map onto the Establishing Foundation → Building Adoption → Driving Adoption → Scale maturity model from Cloud Alliances. Timing varies widely by company stage, tenancy archetype and execution quality – the milestones above describe shape rather than guarantee.

Metrics That Matter

A working metrics approach to cloud co-sell covers four areas. The taxonomy below references the broader KPI structure that recurs across this series:

Pipeline metrics. Sourced pipeline (originated by the hyperscaler) and influenced pipeline (worked jointly but not originated by the hyperscaler), tracked separately. Count, value and stage distribution. The split between sourced and influenced is the single most useful diagnostic – an alliance function with strong influenced pipeline but weak sourced pipeline is operating partner-led co-sell well but hyperscaler-led co-sell poorly.

Conversion metrics. Win rate uplift on co-sold deals vs direct-only deals. Deal size uplift on co-sold deals (often higher when marketplace-routed). Sales cycle compression on co-sold deals vs direct equivalents. All three metrics depend on tenancy archetype and customer segment. Industry data from sources like Tackle’s State of Cloud GTM and Omdia suggests material uplift across all three, but specific percentages vary by source, segment and methodology – treat published figures as directional rather than as benchmarks.

System health metrics. ACE / PSC / partner-portal opportunity acceptance rates. Marketplace transaction rate (count per quarter, value per quarter). Partner attach rate (percentage of new business with hyperscaler attribution). Time from opportunity submission to hyperscaler acceptance.

Relationship metrics. Named-counterpart relationship coverage across the five hyperscaler layers. Joint account plans in flight on top-50 / top-100 named accounts. QBR-rhythm reviews completed with hyperscaler partner organisations. These metrics are harder to track quantitatively but are the leading indicators for the pipeline metrics above.

Most alliance teams over-report on the second and third categories and under-report on the first and fourth. The under-reporting matters because pipeline and relationship metrics are the leading indicators; conversion and system-health metrics are lagging. Better-instrumented alliance functions invert the typical reporting pattern.

Co-Sell Anti-Patterns

Several named anti-patterns recur across alliance functions of all sizes:

“share every opportunity” The team submits every opportunity in pipeline to ACE / PSC / partner portals, drowning the hyperscaler in noise. Acceptance rates collapse. PDMs stop returning calls. Joint pursuits get lost in undifferentiated submissions. The fix is selectivity – submit opportunities where joint engagement actually changes the outcome, let the rest run as direct deals.

“co-sell as deal registration” The alliance function treats opportunity-sharing systems as deal-reg portals for the ISV’s direct sales team to file claims against future closed business. The systems weren’t designed for this; the hyperscaler doesn’t want this; and the resulting submission quality is poor enough that genuine co-sell opportunities get filtered out alongside the spam.

“PDMs as personal lead sources” Treating the hyperscaler PDM as a sourcing function for the ISV’s direct sales team – expecting the PDM to bring inbound leads. PDMs aren’t structured that way. They can broker introductions and advocate for pursuits, but they don’t have customer-side intake responsibility. ISVs that treat them as lead sources damage the relationship and don’t get the leads.

“alliance withholds support from AE-sourced deals” The reverse of the comp-alignment problem and in some ways more damaging because it is harder to see. An AE has a deal that was not sourced by the cloud alliance team but wants alliance support to re-energise it or push it forward. The alliance team has no comp incentive to help – their metrics reward sourced and influenced pipeline, not support work on deals they didn’t originate. In the absence of explicit comp provision for this work, the rational CA team response is to wait: let the opportunity age out, get closed-lost, and then re-open it with the alliance team as the source. This is individually rational and organisationally damaging. The fix requires senior GTM executive involvement – either explicit comp provision for support work on non-sourced deals, or a case-by-case approval process for high-value situations. At high deal volumes the case-by-case model becomes unmanageable and a comp design solution is required. Detail in Cloud Alliance Team.

“tenancy-archetype mismatch” The most significant of the patterns and the easiest to miss. Running a SaaS-style co-sell motion (PDM-led, marketplace-as-origination) for a customer-deployed product, or vice versa. The functions look textbook from the outside and produce systematically wrong outcomes. The definitive reference is ISV-Hosted vs Customer-Deployed.

“single-cloud strategy” Investing only in the primary cloud and treating the other two as not-yet decisions. As the customer base diversifies, the unaddressed clouds become structural blind spots. Even token presence on secondary clouds (basic listing, program enrolment, named PDM) preserves option value.

The honest read: every alliance function exhibits one or two of these patterns at any given time. The work is identifying which one is currently active and resolving it before it compounds.

Common Pitfalls

A handful of practical pitfalls that sit alongside the structural anti-patterns above:

• Underestimating PDM rhythm. PDM relationships need weekly or fortnightly rhythm on primary clouds, not quarterly check-ins. Build the rhythm into the alliance team’s operating rhythm.
• Inadequate consumption-uplift evidence for customer-deployed products. Named-customer evidence is the gating asset for AE engagement. Build it before the AE conversations start.
• Treating marketplace and co-sell as separable. They’re not. Marketplace is the procurement path that closes co-sold deals; co-sell is the motion that originates the marketplace-routed pipeline. Investment in one without the other underperforms.
• No internal escalation path for stalled opportunities. Hyperscaler-side pursuits stall. Without a defined escalation path (regional leadership, industry leads, PDM management) they sit indefinitely. Document the path.
• Ignoring fiscal-year cycles. AWS and Google Cloud run on calendar-year fiscal cycles; Microsoft runs July-to-June. Co-sell pipeline strategies that ignore these cycles miss material end-of-fiscal-year acceleration windows.
• Submitting opportunities with template or placeholder details. It is immediately obvious to a PDM or any hyperscaler reviewer when every submission arrives with identical deal amounts, generic opportunity names (“Co-sell with Microsoft opp”) and no customer-specific context. Deal size is often genuinely unknown early in a pursuit – but that is an argument for a thoughtful placeholder and a documented update cadence, not for copying the same $100k figure across 40 submissions. Lazy submissions signal that the alliance team is treating the portal as a deal-registration system rather than a joint-pursuit tool, and they erode exactly the PDM trust that makes co-sell work. The discipline is: enter the best available information at submission, then update opportunity stage and value on a regular cadence as the deal develops.

What This Looks Like in Practice

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

A data-platform ISV with $70M ARR built a multi-cloud co-sell motion over 30 months. The starting state was an AWS-only motion at month-12 maturity (ACE operational, ISVA-eligible, first specialisation earned, $1.2M of marketplace transactions in the trailing 12 months) and no meaningful Microsoft or Google Cloud presence. The decision to expand was triggered by a board-meeting question – the CRO had been asked why the largest two prospects in late-stage pipeline were both running primary workloads on Azure and Google Cloud while the company had no co-sell motion on either – and the resulting six-month catch-up sprint shaped most of what happened next.

Month 1–6: Microsoft enrolment. ISV Success sprint completed in 90 days, taking the ISV from cold to Co-Sell Ready. Well-Architected Review failed at first attempt on three pillars (cost optimisation, operational excellence, performance efficiency); remediation took six weeks and a redirected sprint from the platform engineering team that had been working on a feature release. Microsoft second attempt cleared. First PSC submissions in flight. First Microsoft marketplace transaction (a $180k renewal of a pre-existing customer routed through MACC drawdown at the customer’s request) closed in month five. The customer’s procurement lead made the marketplace-drawdown ask directly; the ISV’s deal desk took two weeks to process the first private offer and four days to process the second. Direct AEs in two priority Microsoft accounts engaged, both through warm introductions from the Microsoft PDM rather than cold outbound.

Month 7–12: Microsoft maturity progression. Azure IP Co-Sell Eligible earned month 8. First non-renewal Microsoft marketplace transaction (a $340k expansion at an existing customer that converted from direct-invoiced to marketplace at renewal) in month 10. AE-originated pipeline appearing in PSC – the first instance came when an Account Technology Strategist at a financial-services prospect specifically requested ISV inclusion in a customer modernisation pursuit; the ISV’s direct sales team had been working the same account for nine months without the ATS-level relationship. Joint account plans written for the top ten Microsoft accounts. Total Microsoft pipeline contribution at month 12: ~$3.8M.

Month 13–18: Google Cloud entry. The Q1 2026 Partner Network reset shaped the entry path: the ISV enrolled in the Co-sell Partner path, passed Architecture Review in 14 weeks (versus the expected 6–8), opened first PDM relationship in month 16. The Architecture Review extension was less about technical gaps and more about Google’s reviewer capacity – the alliance manager learned later that Q1 2026 had been the busiest review quarter on record because of the program reset. Marketplace transactions through MCCP began in month 18. Google co-sell at this stage was lighter-touch and AE-mediated, consistent with the platform’s tooling vintage and consistent with the Google bifurcation discussed in Google Co-Sell – the PDM accepted ACE-equivalent submissions cheerfully but didn’t move them.

Month 19–24: AWS motion maturing into hyperscaler-led co-sell. The trailing 12-month AWS pipeline shifted from 80% partner-led to roughly 50/50 partner-led / hyperscaler-led, driven by sustained investment in named-customer consumption-uplift evidence and AE relationship-building. Three case studies built in months 14–17 (each showing measurable AWS consumption growth tied to the product) were the single most-cited assets in AE conversations; the alliance team observed that AEs who had read at least one of the case studies were significantly more likely to include the ISV in a new pursuit unprompted. Microsoft motion approaching parity. The CRO’s quarterly board update in month 22 included a co-sell-attributable revenue line for the first time, which significantly changed leadership’s posture on alliance-team headcount. Total co-sold pipeline at month 24 across all three clouds: ~$18M, with marketplace transactions running at 20–25 per quarter.

Month 25–30: Mature operating state. All five engagement layers active across all three hyperscalers (industry leads engaged for two priority verticals). Co-sell contributing ~45% of new enterprise business. Field-enablement programs running quarterly; comp infrastructure stable after a year-two redesign that resolved the alliance-vs-direct credit dispute that had taken almost a quarter of the alliance leader’s time during year one. Total trailing 12-month marketplace transaction value: ~$11M.

None of the milestones above are unusual for a mid-sized ISV taking co-sell seriously. The total trajectory of two-and-a-half years from single-cloud month-12 maturity to mature three-cloud operation is roughly the median for ISVs in the $50–100M ARR band. The single most consistent factor that separates ISVs who reach this state from those who don’t is sustained alliance-leadership focus on the building blocks above, particularly the unglamorous ones (account mapping, attribution infrastructure, field enablement) that don’t produce visible activity in the first few months. The honest reading of this composite: most of the milestones that look like wins in hindsight (the AE relationship at the financial-services prospect, the case studies that changed AE behaviour) came from operational discipline rather than from any single strategic insight.

Where to Go Next

The cluster posts under this pillar:

• AWS Co-Sell – the operating manual for ACE, ISV Accelerate, the SaaS Co-Sell Benefit and the AWS co-sell field motion.
• Microsoft Co-Sell – PSC, Partner Center, MACC drawdown, ISV Success, Azure IP Co-Sell Eligible.
• Google Co-Sell – the post-2026 Google Cloud Partner Network, Co-sell Partner / Services Partner / Technology Partner paths and the AE-mediated motion.
• Co-Sell Operations – the tooling, automation and attribution infrastructure that the three platform motions run on.

Adjacent pillars:

• Cloud Alliances – the partnership function that operates the co-sell motion described here.
• Cloud Marketplace – the procurement channel that increasingly closes co-sold deals.

The full series glossary is at Glossary.

External References

Vendor Primary Sources

• AWS Partner Network – Co-Sell with AWS – the definitive vendor description of the AWS co-sell motion.
• Microsoft Partner Center – Co-Sell Overview – Microsoft’s documented co-sell mechanics.
• Google Cloud Partner Network – the Q1 2026 program structure underpinning Google Cloud co-sell.

Independent Analyst Research

• Omdia – partner-channel and analyst research on cloud partner spend forecasts and co-sell programme outcomes. Note: Omdia acquired Canalys in 2023; research previously attributed to Canalys is now published under the Omdia brand.

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 of sell-to / sell-through / sell-with and the dual-PDM framing that this post leans on.
• CONNACT – Understanding the Co-Selling Layers. A practitioner introduction to hyperscaler co-sell field-organisation layers. Note: the author has a professional relationship with CONNACT; see the series disclosure on the hub page.
• Tackle – State of Cloud GTM annual report, including the marketplace-as-procurement transition data.
• The Ultimate Partner podcast (Vince Menzione) – episode 215 with Chelsea Berlucchi on Google Cloud co-sell, particularly on the customer-segment vs partner-segment field-org distinction at Google.

---

Sources

Primary sources used to verify factual claims in this post. Inline hyperlinks on high-stakes claims point to the same URLs.

AWS

• AWS ISV Accelerate programme page – co-sell partner revenue growth data (51% figure) – Verified June 2026
• AWS APN Blog – AWS Partner Profitability and Revenue Multiplier – Omdia AWS Partner Ecosystem Multiplier 2025 Study ($7.13 figure) – Verified June 2026

Google Cloud

• Google Cloud Marketplace – Committed Use Drawdown documentation – Minimum Commitment obligations as the marketplace drawdown mechanism – Verified June 2026

Last reviewed: 2026-07-01. Pillars in this series are reviewed twice yearly after the major hyperscaler conferences (late November / early December following AWS re:Invent and Microsoft Ignite; late April / early May following Google Cloud Next). Major program 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/.