Private Offers in Cloud Marketplace: AWS Private Offers, Azure MPOs and CPPOs Explained

Public marketplace listings handle the commodity end of the market. Private offers handle everything else – enterprise deals with negotiated pricing, custom terms, specific contract durations and, frequently, a channel partner in the middle. Understanding private offers, their multi-party variants and how they interact with commit-drawdown mechanics is the difference between marketplace as a niche billing channel and marketplace as the primary procurement route for large enterprise deals. This post covers the mechanics across all three platforms.

TL;DR

A cloud private offer is a customer-specific marketplace transaction with negotiated pricing, custom terms and a defined contract duration. It is the primary marketplace mechanism for enterprise deals that require negotiated commercial terms.
All three hyperscalers support both direct (ISV-to-customer) private offers and multi-party variants (ISV + channel partner + customer): AWS Private Offers and CPPOs (Channel Partner Private Offers); Microsoft Customer Private Offers and Multiparty Private Offers (MPOs); Google Cloud Private Offers and Marketplace Channel Private Offers (MCPOs).
AWS’s Express Private Offer, announced around AWS re:Invent 2025 (AWS launch post dated 30 November 2025), reduces friction for standard deals by generating private offers from seller-configured pricing rules. Microsoft’s MPO mechanism allows channel-partner-routed deals to preserve MACC drawdown. Microsoft’s CSP Private Offers do not draw MACC, which is the structural reason MPO exists as a separate mechanism.
Operational mechanics are similar across platforms but the specifics diverge enough that practitioner knowledge from one cloud translates imperfectly. Eligibility requirements for channel-partner variants (country availability, partner-program status) shift periodically.
The most common deal-loss failure mode is offer-expiry before customer acceptance. Configure expiration generously, monitor accepted-vs-pending state actively and treat the private-offer workflow as a sales-stage workflow, not a paperwork exercise.

Comparison at a Glance

Dimension	AWS	Microsoft	Google Cloud
Direct ISV-to-customer	AWS Private Offer; Express Private Offer	Customer Private Offer; CSP Private Offer (no MACC)	Google Cloud Private Offer
Multi-party variant	CPPO (Channel Partner Private Offer)	MPO (Multiparty Private Offer)	MCPO (Marketplace Channel Private Offer)
Pre-committed spend drawdown	EDP	MACC (only for Azure IP Co-Sell Eligible offers)	CUD / MCCP for direct offers; MCPOs count 100% toward committed spend, capped at 25% of total commitment (effective June 2025)
Marketplace fees	AWS: tiered by pre-tax contract value	Microsoft: agency fee applied to software company’s partner price in MPOs	Google: variable revenue share, 3% to as low as 1.5% for eligible partners and deals
Country availability constraints	CPPO geo-restricted; check current eligibility	MPO available in 33 markets as of May 2026 (expanding to Australia, Japan, South Africa July 2026); verify current eligibility in Partner Center	Channel offer geo-restricted; check current eligibility
2026 notable mechanic	Express Private Offer (re:Invent 2025)	Post-September-2025 unified Microsoft Marketplace	Q1 2026 Partner Network reset

Why Private Offers Exist

Public marketplace listings rarely match enterprise procurement reality. Public pricing is a single point on the pricing function; enterprise deals require negotiated tiers, volume discounts, contract durations beyond the listing’s defaults, payment schedules that match the customer’s procurement cycle and custom terms reflecting the specific commercial relationship. Private offers exist to bridge between the marketplace’s standardised contracting infrastructure and the enterprise customer’s specific deal requirements.

Mechanically, a private offer is a customer-specific marketplace transaction that overlays the public listing’s contract structure with negotiated parameters. Where eligible, marketplace private offers can route through marketplace acceptance and billing workflows and may count against the customer’s relevant cloud commitment, such as Microsoft MACC or Google Cloud Minimum Commitment obligations.

The structural value: private offers preserve the procurement-friction-reduction benefits of marketplace transactions (single bill, vendor-risk pre-approved, committed-spend drawdown) while accommodating the commercial reality of enterprise deals. This friction reduction applies to the transactional mechanics – billing infrastructure, contract execution, committed-spend drawdown. It does not eliminate the upstream legal process. In practice, a full enterprise sales cycle involves an NDA at the start of the engagement, a POC or trial agreement where the customer is putting data onto ISV systems for evaluation, and an MSA or software licence and maintenance agreement negotiated directly between ISV and customer lawyers – potentially through multiple redline cycles. The private offer is created only after these agreements are in place; the agreed MSA is then carried into the private offer as the contract overlay. The marketplace handles the commerce; the legal relationship is established outside it.

In mature ISV marketplace motions, private offers account for the substantial majority of marketplace transaction value. Public-listing transactions and click-to-subscribe motions still happen but typically serve self-service customer segments rather than enterprise pursuits. The detailed treatment of marketplace transaction motions is in Cloud Marketplace.

Channel Partner Transaction Models

Before examining the mechanics of CPPO and MPO, it is worth mapping the four fundamental ways an ISV can structure a channel-partner transaction. The commercial controls available to the ISV differ significantly across the four, and the choice has material implications for pricing integrity, partner economics and comp design.

Model 1: Customer pays ISV, ISV pays partner on the backend. The customer contracts directly with the ISV and pays the ISV’s invoice. The ISV separately pays the channel partner their agreed margin. The ISV has complete control over partner economics – payment amount, timing and conditions are all ISV-determined. No cloud marketplace involved, and no cloud committed spend (EDP / MACC / CUD) can be drawn down against the purchase.

Model 2: Customer pays channel partner, partner pays ISV their cut. The customer contracts with the channel partner and pays the partner’s invoice. The partner pays the ISV their agreed wholesale amount. The ISV cannot control what margin the partner takes – the ISV’s cut is whatever remains after the partner’s margin is applied. No cloud marketplace involved, and no cloud committed spend can be drawn down against the purchase.

Model 3: Standard cloud marketplace private offer. The customer transacts through the cloud marketplace, which bills the customer, deducts the marketplace fee and pays the net amount to the ISV. The ISV then makes a separate backend payment to the channel partner for their agreed share. The ISV controls the terms and amount of this backend payment. The marketplace fee is borne by the ISV. Committed spend drawdown (EDP / MACC / CUD) applies where the transaction is eligible.

Model 4: Multiparty private offer (CPPO / MPO / equivalent). The customer transacts through the cloud marketplace. The marketplace pays the ISV their partner price minus the marketplace fee, and pays the channel partner their markup directly and separately. The ISV cannot see the customer adjustment the channel partner applied, and therefore cannot see the channel partner’s final margin or the customer-facing price. This is confirmed by both AWS and Microsoft in their primary documentation. The marketplace fee applies only to the ISV’s partner price; the channel partner’s markup is paid fee-free.

The loss of pricing visibility in Model 4 mirrors the arrangement in Model 2: the ISV sets a wholesale price and the partner determines their own margin independently. This is not a flaw introduced by marketplace mechanics – it is how channel economics work whenever the partner is the customer’s commercial counterparty. CPPO and MPO bring that existing arrangement into marketplace infrastructure while preserving the partner’s commercial autonomy. For the ISV, the partner price set in the offer is therefore the only commercial lever available. Setting it too high leaves the partner with insufficient margin to be competitive; setting it too low compresses ISV economics unnecessarily.

Mature versus early-stage channel programmes. ISVs with a mature channel programme typically publish a list pricing document and agree a “discount off list” with each partner – for example, 35% off list as the partner’s guaranteed wholesale price, with deal protection (typically a tighter discount, say 5% off list, for any other partner quoting on the same registered deal) preventing a competing partner from undercutting within the deal protection window. The partner is then free to sell at any price between their wholesale cost (zero margin, extremely unlikely) and the full list price, with anticipated partner margins typically in the 20–35% range. In Model 4, the ISV sets the partner price at the agreed discount off list; the partner sets their customer-facing price to whatever margin they choose to take on the deal, and the ISV does not see the result.

ISVs early in their channel maturity may not yet have list pricing infrastructure. A simple agreed-percentage model (for example, “the partner gets 20% of whatever the deal closes at”) is workable in Models 1 and 3, where the ISV either invoices the customer directly (Model 1) or sees the marketplace transaction value (Model 3). It does not work in Model 2, where the ISV neither controls the customer-facing transaction nor has visibility into the price the partner quoted – the same pricing opacity that characterises Model 4. In Models 2 and 4, the absence of list pricing removes the only commercial reference point the ISV controls – the partner price becomes an arbitrary number rather than a principled discount off an established list.

AWS Private Offers

AWS Private Offers are the AWS-side mechanism for customer-specific marketplace transactions. The basic flow:

Offer creation. The ISV creates a private offer in AWS Marketplace Management Portal, specifying the customer (by AWS account ID), negotiated pricing structure, contract duration, payment schedule and any custom terms overlay.
Customer notification. The customer receives an email notification with a private-offer URL.
Customer acceptance. The customer accepts through the marketplace; the transaction creates.
Billing trigger. Billing begins per the agreed schedule. The transaction draws against the customer’s EDP commit where applicable.

Three notable AWS-specific features:

Flexible payment schedules. AWS Private Offers support instalment plans and negotiated payment schedules where available for the offer structure. The flexibility matters for customers whose procurement cycle doesn’t align with standard monthly or annual billing.

Express Private Offer. AWS introduced Express Private Offers in late 2025, with a 30 November 2025 launch post and re:Invent 2025 announcement context, as an automated mechanism that generates private offers from seller-configured pricing rules. Sellers configure rate cards and qualification criteria; buyers answer a short set of questions and receive a private offer within minutes when their requirements match the seller-configured rules. Reduces partner-side cycle time significantly for the subset of deals that fit the configured structures.

Offer expiration. AWS Private Offers have a defined expiration date set at offer creation. If the customer doesn’t accept before expiration, the offer becomes invalid and the ISV has to create a new one. Common deal-loss failure mode for ISVs that set expiration too tightly.

Detail on AWS-side co-sell mechanics that flow through private offers is in AWS Co-Sell.

AWS Channel Partner Private Offers (CPPO)

CPPO is AWS’s mechanism for channel-partner-routed marketplace transactions. The structure: the ISV creates a CPPO authorising a channel partner to resell the ISV’s product through marketplace; the channel partner sets the customer-facing price (typically with margin above the ISV’s wholesale price); the channel partner sends the offer to the customer; the customer accepts; AWS pays both the ISV (at wholesale) and the channel partner (at the margin).

Eligibility requirements as of mid-2026:

The vendor must have an eligible AWS Marketplace listing and must authorise the channel partner to resell the product through a selling authorisation.
The channel partner must meet AWS Marketplace channel-partner seller requirements, including paid-seller registration, appropriate tax and disbursement setup, a required service-linked role and AWS approval.
Country availability: practitioners familiar with the programme note that CPPO geographic availability has expanded progressively over time. Check current eligibility in the AWS Marketplace seller documentation before structuring a deal in a new geography.

Fee structure: the CPPO carries a 0.5% uplift on the standard private offer listing fee – so 3.5% for a SaaS transaction under $1M TCV, rather than the standard 3%. AWS applies the CPPO listing-fee uplift to the marketplace transaction fee structure and states that channel partners do not pay transaction fees through CPPO. AWS disburses payment to the channel partner and ISV based on the agreed pricing.

A worked example using the list price / discount off list frame: list price $100, agreed partner discount 35% off list, ISV wholesale price $65. The partner sells at $85 (taking roughly 23.5% margin on the selling price). AWS retains $2.28 (3.5% of $65). The ISV receives $62.73. The channel partner receives $20 fee-free. The ISV does not see the $85 customer price or the $20 partner margin. It is understood that AWS does not disclose the end customer price or expose the channel partner’s markup to the ISV; verify current disclosure mechanics in the AWS Marketplace channel-partner seller documentation. The ISV’s only visibility is their own wholesale price and the resulting payout after the fee deduction.

The margin/markup convention is commercially significant: “20% margin” can mean 20% of the selling price (in the example above, $20 is 20% of the $100 list price – though the ISV has no visibility into what the customer actually paid) or a 20% markup on the wholesale price (which produces different numbers). Where the ISV operates a mature list pricing programme, the partner discount off list is the agreed starting point and the partner’s margin is whatever they choose to take between that floor and the list price. Where the ISV operates a simple agreed-percentage model, the convention should be agreed explicitly in the partner agreement. Pricing structures should account for the full fee stack.

Attribution mechanics: partners report that closed CPPO transactions are attributed to both the ISV and the channel partner in AWS’s reporting. The precise reflection across partner-program tier counters and Specialisation renewal counters should be verified in current AWS Marketplace channel-partner documentation.

CPPO is the definitive mechanism for SI / MSP partners who want to bundle their services with the ISV’s product and transact through marketplace.

Microsoft Customer Private Offers and CSP Private Offers

Microsoft’s private-offer landscape includes two distinct mechanisms with meaningfully different mechanics:

Customer Private Offer (direct ISV-to-customer). The Microsoft equivalent of AWS Private Offers. The ISV creates the offer in Partner Center, specifies the customer (by Microsoft tenant ID), negotiated pricing and custom terms. The customer accepts through Microsoft Marketplace; the transaction creates; billing flows through the marketplace; MACC drawdown applies for Azure IP Co-Sell Eligible offers.

The mechanics are similar to AWS Private Offers but with important differences. Azure IP Co-Sell Eligible status is the gate for MACC eligibility. Offers can be sold through Microsoft Marketplace without MACC eligibility, but only Azure IP Co-Sell Eligible offers decrement a customer’s MACC. Practitioners familiar with the programme note that the Microsoft Customer Engagement Methodology (MCEM) stage is referenced in some workflow steps.

CSP Private Offer. A distinctly different mechanism. CSP Private Offers are sold through Microsoft’s Cloud Solution Provider (CSP) channel rather than through marketplace. The customer buys the ISV’s product from a CSP reseller; the reseller has margin-based economics; the transaction does not flow through marketplace and does not draw MACC. in practice, CSP Private Offers look like traditional reseller margin transactions wearing a “private offer” label.

The CSP Private Offer mechanism is useful for ISVs whose channel motion runs primarily through CSP-tier resellers and whose customer base doesn’t prioritise MACC drawdown. For customers with active MACC commits, CSP Private Offers leave money on the table because the MACC drawdown isn’t available. This is the structural reason Microsoft introduced MPOs (Multiparty Private Offers) as a separate mechanism for channel-routed deals that need to preserve MACC drawdown.

Detail on the Microsoft-side co-sell mechanics that interact with private offers is in Microsoft Co-Sell.

Microsoft Multiparty Private Offers (MPO)

Multiparty Private Offers are Microsoft’s mechanism for channel-partner-routed marketplace transactions. They preserve MACC drawdown when the customer purchases a co-sell eligible solution. The mechanism is newer than the equivalent AWS CPPO and is fundamentally different from Microsoft’s CSP channel.

The mechanics: the ISV creates an offer specifying eligible channel partners, contract length and basic pricing parameters; the channel partner adds customer-specific details, margin and any custom terms; the channel partner sends the offer to the customer; the customer accepts through marketplace; Microsoft pays both the ISV (at wholesale) and the channel partner (at margin) in a single coordinated marketplace transaction.

The fee mechanics are worth stating precisely because they are commonly misunderstood. In Microsoft MPOs, Microsoft pays the channel partner with no agency fee and applies the marketplace agency fee to the software company based on the partner price.

A worked example using the list price / discount off list frame: list price £100, agreed partner discount 35% off list, ISV partner price £65. The partner sells at £85 (taking roughly 23.5% margin on the selling price). Microsoft retains £1.95 (3% of £65). The ISV receives £63.05. The channel partner receives £20 fee-free. The ISV does not see the £85 customer price or the £20 partner margin – Microsoft’s documentation for ISVs confirms that ISVs have visibility only to their configured partner price and their own payout; channel partners separately see the customer adjustment they configured and the customer-facing price, which the ISV cannot access. The ISV’s partner price is therefore the only commercial lever available in an MPO.

Note: the agency-fee rate applied by Microsoft should be verified in current Partner Center documentation before using it in deal modelling.

The margin/markup convention matters: “20% margin” as a percentage of the selling price produces different numbers from “20% markup” as a percentage of the wholesale price. In a mature channel programme using list pricing, the partner discount off list (e.g. 35%) is the agreed starting point and the partner’s actual margin varies depending on what price they choose to sell at. In an early-stage channel programme using a simple agreed percentage, the convention should be explicit in the partner agreement. For a side-by-side comparison with AWS CPPO fee mechanics, see the CPPO section above.

Compared with CSP Private Offers, MPOs route the transaction through Microsoft Marketplace and can draw against MACC when the customer purchases a co-sell eligible solution. The customer gets the procurement-friction-reduction benefits of marketplace plus the MACC drawdown they wanted; the ISV gets credit for a marketplace-routed deal; the channel partner gets margin without forcing the customer outside marketplace.

Eligibility (as of mid-2026) requires:

For MPO creation, the offer must be published to Microsoft Marketplace, be publicly transactable and be created for an eligible partner and customer. Azure IP Co-Sell Eligible status is required for the purchase to decrement MACC.
The channel partner must be enrolled in MAICPP, have a Microsoft Marketplace account in Partner Center and hold a completed Marketplace tax profile in an eligible country. Customer billing-account countries and channel-partner tax-profile countries should be checked separately in Partner Center. US tax profiles carry an additional requirement: resale certificates must be filed with Microsoft at least five business days before the first MPO sale. Non-US channel partners selling to US customers may be subject to withholding tax and may use tax treaty benefits where applicable. Other countries have their own tax profile requirements; verify in Partner Center before structuring a deal in a new market.
Country availability: As of 27 May 2026, MPO customer purchases are available in Austria, Belgium, Bulgaria, Canada, Croatia, Cyprus, Czechia, Denmark, Estonia, Finland, France, Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia, Liechtenstein, Lithuania, Luxembourg, Malta, the Netherlands, Norway, Poland, Portugal, Romania, Slovakia, Slovenia, Spain, Sweden, United Kingdom and United States – 33 markets in total. From 15 July 2026, Australia, Japan and South Africa are added. Microsoft has indicated further expansion is planned beyond these markets. Channel partner tax profile requirements may vary by market; verify current eligibility in Partner Center before structuring a deal in a new geography.

MPO is more demanding in practice than direct Customer Private Offers – the multi-party coordination adds steps to the offer-creation workflow – but the commercial reach is now significantly wider than its original US/UK/Canada scope. For ISVs with established channel motions on Microsoft, MPO is the mechanism through which channel-routed enterprise deals close.

Google Cloud Private Offers

Google Cloud Marketplace supports two private-offer mechanisms:

Direct ISV-to-customer private offers. For direct Google Cloud Marketplace private offers, the vendor creates a customer-specific offer for an eligible SaaS, VM or Kubernetes product. The customer accepts through Cloud Marketplace. Eligible Google Cloud Marketplace spend may count toward Minimum Commitment obligations under Google’s Commitment Drawdown Policy, while MCCP is a separate customer-credit programme.

Marketplace Channel Private Offers (MCPOs). Google Cloud’s channel-mediated private-offer mechanism, formally named Marketplace Channel Private Offer (MCPO). The mechanics are structurally different from AWS CPPO and Microsoft MPO in ways that matter commercially, and the full picture is sufficiently complex that this section describes what is confirmed from primary documentation and is explicit about what requires direct verification with Google.

What is confirmed from primary documentation. The channel partner must hold an accepted status in Google’s channel partner programme – historically requiring acceptance in the Google Cloud Partner Advantage program and authorisation in the Sell engagement model (the Google Cloud partner programme structure before the Q1 2026 Partner Network reset – see Cloud Partner Programs and Specialisations for the current tier model). Partner Advantage was replaced by the Google Cloud Partner Network in Q1 2026; verify current channel-partner eligibility requirements directly with Google, as the programme documentation reviewed does not yet reflect the updated path names. The Q1 2026 Partner Network restructure and its implications for ISVs are covered in Google Co-Sell. ISVs create private offer plans that define the discount available to channel partners; channel partners accept these plans and use them to create private offers for their customers. The customer does not see the reseller discount the channel partner receives from the ISV.

The billing model differs from AWS and Microsoft. In Google Cloud Marketplace Channel Private Offers, the channel partner maintains the customer relationship and owns billing, invoicing and revenue recognition, while the customer purchases the ISV solution through Google Cloud Marketplace via the chosen channel partner. This follows the Model 2 pattern (ISV sells to reseller at wholesale, reseller sells to customer at their own price) mediated through Google Marketplace, rather than the Model 4 arrangement of AWS CPPO and Microsoft MPO where the marketplace invoices the customer and splits the payment.

The agency model complicates this. It is understood that Google Cloud Marketplace operates an agency model alongside the traditional reseller model, under which Google acts as agent for the ISV, facilitating and processing the transaction. Practitioners familiar with the programme note that the agency model applies when both the ISV and customer are in supported regions and the ISV has agreed to the current Marketplace Vendor Agreement; verify current applicability directly with Google. How the agency model interacts with reseller transactions is not addressed in the documentation reviewed; the two models co-exist and Cloud Marketplace selects between them based on regional and contractual criteria.

Committed spend drawdown. Starting 9 June 2025, qualifying software purchases through Google Cloud Marketplace Channel Private Offers result in 100% commit drawdown tied to the final private-offer price, with the qualifying amount subject to an allowable 25% cap. This resolves previously uncertain territory and brings MCPOs closer to parity with AWS CPPO and Microsoft MPO on this dimension. The 25% cap is a material consideration for customers with large Google Cloud Minimum Commitments. A qualifying MCPO purchase can apply the full qualifying amount toward the customer’s Minimum Commitment only up to the allowable 25% cap.

The revenue share fee for MCPOs. Google Cloud Marketplace is moving to a variable revenue-share model from 3% to as low as 1.5% for eligible partners and deals, based on attributes such as deal size, renewal, channel shift or migrations. This structure makes large-deal MCPOs potentially cheaper than the equivalent AWS CPPO (3.5% baseline uplift). Partners report that direct ISV-to-customer and MCPO revenue-share tiers may interact differently for specific deal structures; verify the applicable rates directly with Google before modelling deal economics.

Given this complexity, treat the Google Cloud channel partner reseller model as requiring direct verification before structuring channel agreements, pricing or partner programme commitments. The AWS CPPO and Microsoft MPO sections above describe verified mechanics; the Google reseller model is meaningfully different in architecture and should not be assumed to follow the same commercial patterns.

Practitioners familiar with the programme note that Google Cloud’s private-offer tooling is lighter than AWS’s or Microsoft’s, consistent with the broader pattern in Google Co-Sell that Google Cloud’s partner-side tooling is less developed than the other two. More of the workflow happens through direct AE / CE coordination rather than through the partner portal. The trade-off: lower workflow overhead, but more of the operational discipline lives with the ISV team rather than being enforced by the tooling.

When to Use Which

For ISVs where hyperscaler alliances are a strategic priority, marketplace usage should not be a deal-by-deal decision. The default should be marketplace-routed, backed by policy and comp design that make direct deals the exception requiring senior approval. The reasons are covered in the Marketplace Deal Routing and Comp Design section of Cloud Marketplace Listings: treating marketplace vs direct as a per-deal choice gives ISV AEs a structural incentive to route direct, and the pattern compounds over time.

The question this section addresses is which marketplace mechanism to use, given that marketplace is the baseline. Three questions resolve most cases:

1. Does the customer have committed cloud spend? If yes, the mechanism matters: MACC / EDP / CUD drawdown is the procurement-friction-reduction lever and not all mechanisms preserve it. For Microsoft specifically, Customer Private Offer and MPO both draw MACC; CSP Private Offer does not. For Google Cloud, eligible Google Cloud Marketplace spend may count toward Minimum Commitment obligations for direct ISV-to-customer private offers; MCPO transactions count 100% toward committed spend capped at 25% of total commitment (effective 9 June 2025).

2. Is a channel partner involved in the customer relationship? If yes, the multi-party variant (CPPO / MPO / MCPO) is the appropriate mechanism – it preserves the channel relationship and the partner’s margin through marketplace. Without a channel partner, the direct ISV-to-customer private offer is the appropriate mechanism.

3. Who owns the customer relationship? If the ISV directly owns the relationship, direct private offer is the natural fit. If a channel partner owns the relationship, the channel-mediated variant is appropriate. Where ownership is genuinely shared (ISV sells the product, channel partner delivers implementation services), the multi-party variant typically works.

4. What’s the deal size and operational complexity tolerance? Direct private offers carry lighter operational overhead than multi-party variants. For smaller deals or deals with simple terms, direct private offer is the right choice. For larger or more complex deals, the multi-party variant’s overhead is justified by the channel-partner economics and MACC / EDP drawdown preservation.

Non-marketplace alternatives – direct invoicing or, for Microsoft, CSP-routed deals that don’t draw MACC – should be documented exceptions rather than a normal operating mode. Where a deal routes direct, the reason should be recorded: customer explicitly declined marketplace, geography not yet supported, deal structure doesn’t fit available mechanisms. Tracking the aggregate of exceptions is a useful diagnostic; a high exception rate over time points to comp design and internal policy gaps, not customer preference.

Operational Mechanics

The operational flow common to all platforms (with platform-specific variation):

Pre-offer legal preconditions. For enterprise deals, the private offer is created only after the direct legal groundwork is complete. This typically involves an NDA at the start of the sales engagement; a POC or trial agreement if the customer is putting data onto ISV systems for evaluation; and an MSA or software licence and maintenance agreement negotiated directly between ISV and customer lawyers. This last step often involves multiple redline cycles and legal mediation calls that can span weeks or months. The marketplace infrastructure is not suited to hosting this negotiation – it is designed for acceptance of agreed terms, not iterative redlining. Only once the MSA is executed does offer creation begin.

Offer creation. The ISV (or, for multi-party variants, the ISV plus the channel partner) creates the offer in the platform’s marketplace seller portal, specifying customer, pricing, terms, duration, expiration and payment schedule.
Internal approval. Most ISVs operate an internal deal-desk approval flow before sending offers to customers. The approval checks pricing against discount policies, terms against legal-approved templates, payment schedules against finance preferences.
Customer notification. The customer receives notification (typically email) with the offer URL.
Customer acceptance. The customer accepts through the marketplace UI. Most marketplaces are click-to-accept; very large deals sometimes require an additional wet signature on a supplemental agreement capturing custom terms not natively supported by the marketplace contract overlay.
Billing trigger. Billing begins per the agreed schedule. Multi-party variants involve coordinated billing across both the ISV and the channel partner.
Payout cycle. Each marketplace pays the seller (and channel partner for multi-party variants) on a defined cycle. Partners report that this is typically 45–60 days after customer billing close; verify the current payout schedule in each platform’s seller documentation.
Reconciliation. The seller’s finance and RevOps teams reconcile marketplace transaction records to ISV-side CRM and ERP. Multi-party transactions add reconciliation complexity for the channel-partner-attributed share.

The operational depth required scales with transaction volume. ISVs running 1–5 private offers per quarter can manage manually; ISVs running 50+ private offers per quarter typically need Cloud GTM Platform tooling to automate offer creation, approval-flow routing and reconciliation. Detail on operational scaling is in Cloud Marketplace Operations.

Legal and Contracting Considerations

Marketplace private offers operate through a layered contract structure: the customer’s master agreement with the hyperscaler covers the marketplace transaction infrastructure; the ISV’s standard terms apply as a click-to-accept overlay; the private offer’s negotiated parameters override defaults from both layers.

EULA / Standard Contract Overrides. Private-offer contract overlays vary by marketplace. AWS supports custom EULAs or legal terms for private offers, while Google requires private offers to stay within approved Cloud Marketplace offerings and the Marketplace Vendor Agreement. The standard enterprise workflow: the ISV and customer negotiate the MSA directly and outside the marketplace, through whatever redline cycles the lawyers require; once executed, the agreed terms are uploaded as the private offer’s contract overlay or referenced via a parallel supplemental agreement. The marketplace’s click-to-accept mechanism then records the customer’s acceptance of those pre-agreed terms. The marketplace carries the agreed document; it does not host the negotiation. An ISV that attempts to use the private offer itself as the vehicle for contract negotiation will find the infrastructure unwieldy – it is designed for acceptance, not redlining.

Partner T&Cs in multi-party offers. For CPPO / MPO / channel-partner offers, the channel partner’s own terms-and-conditions may overlay or supplement the ISV’s. The multi-party contract structure has to be clear about which terms govern which aspects of the deal.

Sales tax / VAT / GST handling. Each marketplace handles a portion of customer-side tax obligations but coverage varies by jurisdiction. The seller’s finance team needs to map which jurisdictions are marketplace-handled and which require seller-side tax registration. Detail in Cloud Marketplace Listings under multi-currency / tax.

Signature requirements. Most marketplaces are click-to-accept – the customer’s acceptance of the private offer in the marketplace UI constitutes contract execution. However, legal teams routinely advise against relying solely on click-through acceptance, for two reasons: click-through is considered less legally binding than a signed agreement and is more easily challenged; and the marketplace has no mechanism for iterative redlining, so any negotiated terms have to be agreed outside the marketplace and referenced rather than negotiated within it. In practice, ISVs typically require a supplemental signed agreement on larger deals regardless of whether custom terms need to be captured – either a signed MSA executed before the private offer is created, or a signed quote that references the MSA and the marketplace transaction, creating a deliberate paper trail alongside the click-through event. Very large deals (typically $1M+ annual contract value) sometimes require an additional wet signature on a supplemental agreement capturing custom terms that aren’t natively supported by the marketplace contract overlay. The supplemental agreement is a parallel paper agreement that references the marketplace transaction; the marketplace transaction is the commercial vehicle.

Indemnities and liability caps. The marketplace’s default contract terms include indemnity and liability provisions that the ISV’s custom contract may want to modify. Legal review is necessary at the standard-contract definition stage; the per-deal review then becomes lighter because the standard contract has already been vetted.

Common Pitfalls

Patterns that recur in private-offer motions:

Pricing that doesn’t account for marketplace fees. The 3% baseline fee plus any channel-partner margin reduces the ISV’s net realisation. Pricing structures designed without accounting for the fee stack produce gross-margin surprises. A related misconception in multi-party deals: the ISV assumes the channel partner is sharing the marketplace fee. In practice the fee applies only to the ISV’s wholesale price; the channel partner’s markup above that price is paid fee-free by the marketplace. The full marketplace fee sits with the ISV regardless of whether a channel partner is involved.
Offers that expire before customer acceptance. A recurring deal-loss pattern. Customers move slower than ISVs expect; offer expiration set tightly produces missed deals that have to be re-offered (and sometimes re-approved internally). Default to generous expiration; tighten only with reason. When setting expiry, think backwards from the customer’s procurement clock – if their budget cycle closes at month-end, an offer expiring mid-month forces a missed cycle rather than a rushed decision.
Missing flexible payment schedule. Enterprise customers often have specific payment-cycle preferences (annual upfront, quarterly, milestone-based). Standard monthly billing structures lose deals where the customer’s procurement cycle requires something different. AWS Private Offers and Microsoft / Google equivalents all support flexible schedules; use them.
Channel partner not eligible for the jurisdiction. CPPO and MPO have country-availability restrictions that have expanded over time but remain limited in some geographies. Check eligibility before structuring the deal.
CSP Private Offer used where MPO would preserve MACC. Microsoft-specific. Customers with active MACC drawdown preference lose access to that benefit through CSP Private Offers. Use MPO instead where eligibility allows.
Internal approval flow not designed for marketplace velocity. Marketplace deals close faster than direct-invoiced equivalents. ISV internal deal-desk approval flows designed for the slower direct-invoicing rhythm become the bottleneck for marketplace closing speed.
Reconciliation skipped for multi-party transactions. Multi-party transactions are harder to reconcile (channel-partner-attributed share, multi-cycle payouts, partner-side reporting). ISVs that skip the reconciliation discipline find their alliance comp credit and partner-program metrics drift from the platform’s reporting over time.

What This Looks Like in Practice

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

A data-platform ISV with $35M ARR closed its first complex multi-party deal in early 2026: a financial-services customer with a $1.2M annual contract, routed through an SI partner who handled implementation services and customer-side change management.

The deal mechanics: the ISV created an MPO on Microsoft Marketplace specifying the SI as the authorised channel partner. The SI added their customer adjustment (producing roughly 15% margin on their selling price relative to the ISV’s partner price), customer-specific configuration details and a payment schedule aligned to the customer’s quarterly procurement cycle. Side-letter on indemnity caps signed in parallel with the marketplace acceptance. The customer accepted in marketplace; MACC drew down; Microsoft paid the ISV and the SI on separate parallel disbursement cycles.

Operational complexity from the MPO structure compared to the direct private-offer alternative: roughly 3x. The reconciliation step alone took the marketplace ops manager three days at month-end of the first quarter the deal billed in, against an hour or so for direct-private-offer reconciliations. By the third deal of similar structure, the team had built playbook and automation that brought MPO reconciliation overhead closer to 1.5x – still heavier, but tolerable.

The lesson: multi-party private-offer mechanics scale in practice with playbook investment. The first MPO deal looks like a major operational lift; the third looks routine. Invest in the playbook deliberately rather than treating each multi-party deal as one-off.

A benefit that registered less visibly at the time: the $1.2M MPO transaction, together with two similar deals closed over the following quarters, contributed significantly to the ISV’s Microsoft marketplace revenue metrics. The accumulated marketplace volume pushed them across the threshold to the next Solutions Partner tier – unlocking higher-priority co-sell queue access, increased PAL funding allocations and Specialisation eligibility they hadn’t previously qualified for. The operational overhead of the first three MPO deals was real; the partner-program acceleration it bought was more durable than any single deal outcome.

Where to Go Next

Within this pillar:

Cloud Marketplace Listings – the listing types and validation processes that gate private-offer eligibility.
Cloud Marketplace Operations – the back-office stack that supports private-offer reconciliation and payout at scale.
Cloud Marketplace – the broader pillar this post sits under.

Per-cloud co-sell mechanics (where private offers operationalise co-sell):

AWS Co-Sell – AWS Private Offers in the co-sell context including the SaaS Co-Sell Benefit on private-offer-routed SaaS deals.
Microsoft Co-Sell – Microsoft Customer Private Offers, MPOs and the MACC drawdown dynamics.
Google Co-Sell – Google Cloud private-offer mechanics and the more AE-mediated motion.

The full series glossary is at Glossary.

Sources

Last reviewed: 2026-07-01. Vendor-specific clusters in this series are reviewed twice yearly after the major hyperscaler conferences plus mid-cycle for major program or marketplace 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/.