Cloud GTM Glossary

A working glossary of the acronyms, program names and terms of art used across the Hyperscaler GTM Playbook. Each entry is short by design (2–4 sentences) and links out to the post that treats the topic in depth. The intent is for first-mention callouts in the series – e.g. Microsoft Azure Consumption Commitment (MACC) – to land here, not on a vendor’s marketing page.

The list below combines Wave 1 (the highest-frequency terms that recur across most of the series) and Wave 2 (the next layer – hyperscaler field roles, tenancy architecture vocabulary, listing types, per-cloud equivalents of headline programs, alliance and co-sell operating artefacts and the finance/ops terms that gate marketplace work). It will continue to extend post-by-post as new terms appear in drafts.

A note on program names: Microsoft and Google both renamed their partner programs in the 12 months before this glossary was written. Current names are used as the primary entries; the legacy names are cross-referenced inside those entries so search visitors arriving on an old term still land in the right place.

Account Mapping

The exercise of comparing the ISV’s customer and prospect list against a hyperscaler’s customer list to find the overlap – accounts where both parties already have a relationship, or where one party has reach the other doesn’t. The foundational input to most working joint account plans and to any targeted co-sell pursuit; without it, opportunity sharing is undirected and acceptance rates suffer. In practice it’s almost always tooled rather than done by hand. See Hyperscaler Co-Sell and Co-Sell Operations.

ACO

Azure Credit Offer (ACO): a Microsoft mechanism for directing Azure credits to an ISV’s own account, typically used to offset the cost of running a proof-of-concept or pilot in the ISV’s own Azure tenant. ACO credits accrue to the ISV’s subscription, not to the customer’s – which means they cannot in practice be used for customer-deployed products whose POC runs in the customer’s own environment. For customer-deployed ISVs, ACO is therefore a limited-value mechanism for POC funding; the workarounds and their limitations are covered in Cloud Provider Funding.

ACE

AWS APN Customer Engagements (ACE) is the AWS Partner Network’s pipeline-sharing system, accessible via the Sell menu in AWS Partner Central. Partners use it both to share opportunities outward to AWS – demonstrating traction and requesting field support – and to receive opportunities AWS shares inward. ACE eligibility is a prerequisite for the ISV Accelerate (ISVA) programme; ACE activity and Specialisation status are also the minimum requirements for a partner’s solutions to appear in AWS’s AI-powered co-sell recommendation engine. See AWS Co-Sell for the practical workflow.

AE

Account Executive (AE): the customer-facing hyperscaler seller, carrying a quota tied to customer cloud consumption growth. AEs are the primary co-sell counterpart for ISVs whose products run in customer accounts, and their incentives differ by design from those of the partner-side PDM – which is one of the most significant dynamics in the series. Throughout this series, unqualified “AE” means the hyperscaler AE; where the ISV’s own account executive is meant, the series uses the explicit qualifier “ISV AE”. See ISV-Hosted vs Customer-Deployed for the structural significance and Hyperscaler Co-Sell for the practical engagement model.

Alliance / Cloud Alliance

In this series, “alliance” and “cloud alliance” refer specifically to the hyperscaler GTM relationship between an ISV and one or more of AWS, Microsoft and Google Cloud. The term is used narrowly throughout: it does not cover technical alliances (product integrations between two ISVs or between an ISV and a non-hyperscaler technology vendor), marketing partnerships (co-branded campaigns or joint events with third parties), or general ecosystem relationships. At some companies “alliances” is used as an umbrella covering all of the above; this series uses the narrow definition. See Cloud Alliance Team and the hub’s terminology note.

Architecture Review

Practitioners familiar with the programme note that Google Cloud conducts a technical validation of an ISV’s product prior to marketplace listing and partner-programme status advancement, referred to in practitioner circles as an Architecture Review. The specific mechanics and formal programme name are not fully documented in current public sources; broadly equivalent in intent to AWS’s FTR and Microsoft’s Well-Architected Review. See Cloud Partner Programs and Specialisations and Cloud Marketplace Listings.

ATS

Account Technology Strategist (ATS): a senior technical-strategic role on a Microsoft enterprise customer account, broadly blending senior-AE and lead-architect responsibilities. ATSs anchor enterprise customer relationships and are critical engagement points for ISVs working a Microsoft account, particularly for customer-deployed products where the technical buy-in lives outside the partner-side PDM motion. See Microsoft Co-Sell.

ATU

Account Technology Unit (ATU): Microsoft’s named-account field organisation responsible for the overall customer relationship at enterprise accounts. The ATU is the customer-facing commercial layer – led by the ATS – that manages executive relationships, account strategy and commercial outcomes across the full Microsoft portfolio. The ATU is distinct from the STU (Specialist Technology Unit): ATU members hold the customer relationship and the commercial mandate, while STU members hold workload-specific quota and technical depth. For ISVs approaching a Microsoft enterprise account, understanding which unit has originated the introduction determines the likely co-sell motion and whose quota retirement is in play. See Microsoft Co-Sell.

AWS Partner Network

The overarching AWS partner program, structured around Partner Paths (Software, Services, Hardware, Distribution, Training). Membership is the gating mechanism for Specialisations, co-sell tooling like ACE and marketplace seller status. Detail in Cloud Partner Programs and Specialisations.

Azure IP Co-Sell Eligible

A Microsoft co-sell status indicating an ISV’s offer is transactable through the marketplace and counts toward MACC drawdown for the buying customer. Distinct from “Co-Sell Ready”, which is a softer engagement status without MACC eligibility. For most enterprise Microsoft business, IP co-sell eligibility is effectively the price of entry. See Microsoft Co-Sell.

Better-Together Story

A short, named-customer-flavoured narrative articulating why a customer benefits from buying the ISV’s product and using the hyperscaler’s platform together, rather than either in isolation. The ISV-side artefact that the hyperscaler AE uses to brief the customer team and book joint pursuits – particularly for customer-deployed products where the consumption-uplift case needs to be told directly. Lives in the alliance function and feeds the Joint Account Plan.

Build / Sell / Service

The three partner archetypes under the former Google Cloud Partner Advantage: Build (ISVs with marketplace listings), Sell (resellers and channel partners), Service (SIs and MSPs delivering implementation and managed services). These labels were replaced under the Google Cloud Partner Network (launched Q1 2026), which organises partners around distinct paths: Co-sell Partner, Services Partner and Technology Partner, among others. ISVs typically engage via the Technology and Co-sell paths. The heading is retained here for readers arriving from search on the legacy terms. See Cloud Partner Programs and Specialisations.

Channel / Channel Partner

In this series, “channel” and “channel partner” refer to the network of resellers, system integrators, managed service providers and distributors who resell or deliver the ISV’s product to end customers – sometimes called the “VAR network” or “partner program” at companies where “partner” means reseller. Channel partners are distinct from hyperscalers; they may participate in hyperscaler marketplace transactions (via CPPO or MPO) but the channel relationship is a separate commercial arrangement from the hyperscaler co-sell motion. See Private Offers for the mechanics of multi-party marketplace transactions involving channel partners.

CAM

Cloud Alliance Manager (CAM): the partner-side role responsible for owning a hyperscaler relationship, typically named on a per-cloud basis (CAM for AWS, CAM for Azure, etc.). Counterpart to the hyperscaler-side PDM in the “dual PDM” pattern. See Cloud Alliance Team for the role profile, hiring considerations and comp design.

CE

Customer Engineer (CE): Google Cloud’s customer-facing technical role. Pre-sale in orientation – CEs lead workload validation, proof-of-concept support and pre-sales technical buy-in across specific workload domains. There is no clean Microsoft equivalent: the CE carries more scope and seniority than a TSP but is less commercially quota-driven than an SSP; in practice the CE sits between the two. The AWS SA is the closer functional parallel. The Microsoft CSA is a superficially similar title but is post-sale, sitting in the Customer Success Unit rather than the pre-sale field; the CE is not equivalent to the CSA. For customer-deployed products on Google Cloud, the CE relationship often matters more than the PDM relationship. See Google Co-Sell.

CSAM

Customer Success Account Manager (CSAM): Microsoft’s specific title for the post-sale customer relationship role within the Customer Success Unit (CSU). Equivalent in function to the generic CSM role at AWS and Google Cloud but with a distinct title and pronunciation – always spoken as “See-Sam” in Microsoft field conversation. CSAMs focus on adoption acceleration, consumption growth and renewal health on existing accounts. A significant source of hyperscaler-led inbound for customer-deployed ISVs where an existing customer has a workload problem the Microsoft portfolio hasn’t solved and the CSAM has C-Sat pressure to resolve it. See Microsoft Co-Sell.

CSM

Customer Success Manager (CSM): the generic industry title for the post-sale customer-facing role at a hyperscaler, responsible for consumption growth, renewal health and customer satisfaction on existing accounts. AWS and Google Cloud use CSM; Microsoft uses CSAM (Customer Success Account Manager) for the equivalent role. CSM-originated introductions tend to be better-qualified and more urgent than PDM-originated introductions because the customer problem is typically active and documented. See Hyperscaler Co-Sell and Co-Sell Operations.

Closed-Loop Attribution

The discipline of tracking a co-sold deal from origination through to closed-won and back into the systems of both the ISV and the hyperscaler, so that revenue, quota retirement and program credit all land on the right side of every ledger. The most common ops failure in co-sell at scale, and the reason most mature alliance teams invest heavily in PSC / ACE-to-CRM bidirectional sync. Without it, the three sources of truth (the ISV’s CRM, the hyperscaler’s partner portal and the marketplace transaction record) drift, forecasts disagree and comp plumbing breaks. See Co-Sell Operations.

Cloud GTM Platform

The category of third-party tooling that automates the bidirectional sync between an ISV’s CRM and the hyperscaler partner portals (Partner Center, Partner Central, Producer Portal), plus the operational mechanics of marketplace listings, private offers, metering and disbursement reconciliation. Vendors in the category include (alphabetically, no endorsement) Clazar, Labra, Suger and Tackle (acquired by AppDirect, December 2025). Most mid-to-large ISVs eventually choose between buying a platform, building native API integrations or accepting a hybrid; the trade-offs are covered in Co-Sell Operations.

Cloud Native

An architectural approach in which applications and services are built from the ground up to run on cloud infrastructure – using managed services, elastic scaling, containers, microservices, serverless functions and declarative infrastructure rather than being lifted and shifted from on-premises environments. Cloud native is an architectural quality, not an ownership category: a service can be cloud native and first-party (AWS Lambda), cloud native and third-party (an ISV database designed for cloud deployment) or neither (a legacy appliance running on a cloud VM without re-architecture). In hyperscaler partner programs, cloud-native alignment is assessed through technical validations: FTR at AWS, the Well-Architected Review at Microsoft and the Architecture Review at Google Cloud. See Cloud Partner Programs and Specialisations and Cloud Marketplace Listings.

Co-Sell

A joint selling motion between an ISV and a hyperscaler around a shared end customer. Distinct from sell-to (the hyperscaler buys the ISV’s product), sell-through / resale (a channel partner resells the ISV’s product) and the marketing notion of sell-with. The conceptual frame is in Hyperscaler Co-Sell; per-platform mechanics in AWS Co-Sell, Microsoft Co-Sell and Google Co-Sell.

Consumption

The dollar value of cloud services used within a hyperscaler account during a billing period. Consumption is the fundamental currency of hyperscaler partnerships: AEs are measured on consumption growth in their named customer accounts; PDMs are measured on partner-attributed consumption and marketplace transaction volume; and committed-spend drawdown mechanisms (EDP, MACC, CUD) are applied against consumption. The distinction between partner-side consumption (accruing to the ISV’s own cloud account when running an ISV-hosted SaaS product) and customer-side consumption (accruing to the customer’s cloud account when running customer-deployed software) is one of the most significant structural dynamics in the series. See ISV-Hosted vs Customer-Deployed and Consumption Uplift.

Consumption Uplift

The increase in a customer’s cloud consumption that an ISV’s product is responsible for driving. Most acute and most under-articulated for customer-deployed infrastructure products that don’t just consume cloud but enable more of it: workloads that wouldn’t otherwise have moved to cloud, density that wouldn’t otherwise have been possible, performance envelopes that unlock new use cases. The story does not tell itself – explicit, named-customer evidence is what unlocks customer-facing AE engagement. See ISV-Hosted vs Customer-Deployed.

Control Plane / Data Plane

The architectural split common to hybrid-tenancy ISV products: the control plane (management, billing, metering, orchestration) runs in the ISV’s cloud account, while the data plane (the workload actually processing customer data and consuming resources at scale) runs in the customer’s cloud account. The split has significant consequences for hyperscaler-field incentives, because most of the consumption uplift sits with the data plane and therefore with the customer-facing AE. See ISV-Hosted vs Customer-Deployed.

CPPO

Channel Partner Private Offer (CPPO): an AWS Marketplace transaction structure in which a channel partner resells the ISV’s product through marketplace, with the ISV, channel partner and AWS all paid in a single transaction flow – the channel partner receives their markup free of the marketplace fee, while the ISV bears the listing fee. CPPO listing fees carry a 0.5% uplift over the standard private offer tiered schedule: 3.5% for deals below $1M, 2.5% for deals from $1M to below $10M, 2% for deals of $10M or more, and 2% for all renewals. The Microsoft equivalent is the MPO; the Google Cloud equivalent is the MCPO, which has a billing architecture that differs by design from CPPO and MPO. See Private Offers.

CSA

Cloud Solution Architect (CSA): Microsoft’s customer-facing technical role, sitting within the Customer Success Unit (CSU) rather than the pre-sale field. CSAs focus on post-sale technical enablement, adoption acceleration and consumption growth – making them distinct from the pre-sale SSP / TSP roles in the STU, despite the surface similarity in job titles. CSAs lead technical solution design on existing Microsoft accounts and are critical engagement points for ISVs whose products require architectural buy-in from the customer success layer. Practitioners familiar with the programme note that CSAs operate under a different incentive balance from quota-carrying field sellers: customer satisfaction and adoption outcomes carry more weight in their compensation than consumption growth alone, which means enterprise customers tend to place a high level of trust in their technical recommendations – a CSA endorsement of an ISV’s solution can carry meaningfully more weight with the customer than the same endorsement from a pure-quota seller. Not directly equivalent to AWS’s SA or Google Cloud’s CE, which are primarily pre-sale roles; the closer Microsoft pre-sale equivalent is the TSP. See Microsoft Co-Sell.

CSP

Cloud Solution Provider (CSP): Microsoft’s reseller channel. CSP partners resell Microsoft Azure (and Microsoft 365, Dynamics, etc.) to end customers, typically on margin-based terms. Traditional CSP transactions sit outside the marketplace and don’t draw down MACC – which is the structural reason the MPO mechanism exists separately. See Microsoft Co-Sell.

CSU

Customer Success Unit (CSU): Microsoft’s post-sale customer-facing organisation, responsible for adoption acceleration, consumption growth and renewal health on existing accounts. The CSU sits alongside rather than within the sales field (the STU and ATU); practitioners familiar with the programme note that CSU members operate under a different incentive balance from quota-carrying field sellers: customer satisfaction and adoption outcomes carry more weight in their compensation than consumption growth alone, which gives their technical and product recommendations a level of customer trust that pure-quota sellers do not always enjoy. The CSU contains the CSAM (Customer Success Account Manager) role and the CSA (Cloud Solution Architect) role. CSU-originated introductions tend to be well-qualified – the customer problem is typically active, documented and urgent – making the CSU a productive inbound channel for customer-deployed ISVs. See Microsoft Co-Sell.

CUD

Committed Use Discount (CUD): Google Cloud’s pre-committed spend mechanism. Committed Google Cloud spend (CUDs and spend-based commits) can be applied against marketplace purchases under the Google Cloud Marketplace Commitment Drawdown Policy – the dominant reason committed customers prefer to procure ISV software through marketplace. The MCCP is a related but separate customer credit incentive. The AWS equivalent to the drawdown mechanism is EDP; the Microsoft equivalent is MACC. See Cloud Marketplace.

CUA

Customer Usage Attribution (CUA): Microsoft’s mechanism for tracking ISV IP driving Azure consumption in customer subscriptions. Implemented via ARM template GUIDs, Resource Manager APIs or Terraform. A GUID is registered in Partner Center and embedded in the ISV’s deployment template; when the template deploys resources in the customer’s subscription, Microsoft associates the resulting Azure consumption with the ISV. Relevant to customer-deployed ISVs: CUA makes the ISV’s contribution to customer-side consumption visible to Microsoft’s internal systems, supporting Specialisation renewal and co-sell incentive calculations. Notably, CUA is not applicable to Azure VM offers – VM consumption in the customer subscription is tracked automatically and requires no additional ISV implementation. Known limitations: Azure Kubernetes Service, VM Scale Sets and Azure Batch have documented under-reporting issues. Distinct from PRACR, which is the mechanism for ISV-Hosted SaaS ISVs. See ISV-Hosted vs Customer-Deployed and Cloud Partner Programs and Specialisations.

Customer Account (AWS)

AWS’s term for the cloud environment owned and billed to the end customer, into which customer-deployed ISV software is installed. An AMI or container deployed into a customer account runs on the customer’s compute resources and accrues to the customer’s AWS bill. Analogous to Microsoft’s customer tenant and Google Cloud’s customer project. See ISV-Hosted vs Customer-Deployed.

Customer-Deployed Software

The tenancy archetype in which an ISV’s software runs in the customer’s hyperscaler environment – packaged as AMI/VM, container or infrastructure-as-code. Cloud consumption from the workload accrues to the customer’s bill, which significantly shifts which hyperscaler roles are paid to support the ISV (favouring customer-facing AEs over partner-side PDMs). Each hyperscaler uses its own term for this environment: AWS calls it the customer account, Microsoft calls it the customer tenant or customer subscription (the subscription being the billing and resource-management scope within the tenant) and Google Cloud calls it the customer project or customer organisation. The definitive reference for the downstream consequences is ISV-Hosted vs Customer-Deployed.

Customer Project (Google Cloud)

Google Cloud’s term for the fundamental resource container into which customer-deployed ISV software is installed. A Google Cloud project is the organisational unit that groups related cloud resources, manages billing, permissions and API access for a specific application or workload. “Customer organisation” refers to the node above projects in GCP’s resource hierarchy, encompassing all of a customer’s projects. Analogous to AWS’s customer account and Microsoft’s customer tenant. See ISV-Hosted vs Customer-Deployed.

Customer Subscription (Microsoft)

The billing and resource-management scope within a Microsoft customer tenant under which Azure resources – including ISV-deployed VMs, containers and managed applications – actually run. A tenant can contain multiple subscriptions; ISVs with Azure Lighthouse access are typically granted access at the subscription scope rather than the tenant scope. “Customer subscription” and “customer tenant” are often used interchangeably in practitioner conversation, though they are technically distinct levels of the same hierarchy. See Customer Tenant (Microsoft) and ISV-Hosted vs Customer-Deployed.

Customer Tenant (Microsoft)

Microsoft’s term for the Azure Active Directory / Entra ID identity boundary into which customer-deployed ISV software is installed. Each organisation in Microsoft’s ecosystem has a distinct tenant, with its own identity, policies and access controls. Within a tenant, a customer may have one or more subscriptions – each subscription is the billing and resource-management scope under which Azure resources (including ISV-deployed VMs, containers and managed applications) actually run. Software deployed “in the customer tenant” runs in a specific subscription within that tenant, accruing to the customer’s Azure bill. The terms “customer tenant” and “customer subscription” are often used interchangeably in practitioner conversation, though they are technically distinct levels of the same hierarchy. Analogous to AWS’s customer account and Google Cloud’s customer project. See ISV-Hosted vs Customer-Deployed.

EDP

Enterprise Discount Program (EDP): AWS’s pre-committed spend mechanism. Customers under EDP almost always prefer to spend pre-committed cloud budget on third-party software through an AWS Marketplace private offer rather than open new procurement. The Microsoft equivalent is MACC; the Google Cloud equivalent is CUD.

ECIF

End Customer Investment Funds (ECIF): a Microsoft funding program under which Microsoft pays approved partners to deliver services that accelerate customer adoption of Microsoft cloud technologies. The key distinction for ISVs: ECIF is a services-delivery program, not a software or credits program. It is available to system integrators, managed service providers and consulting firms that hold a relevant Advanced Specialisation and have completed ECIF supplier registration via Microsoft’s SupplierWeb portal (registration appears to be territory-specific in practice – a partner registered in one country may require separate registration to deliver ECIF in another territory; verify with your Microsoft PDM before assuming global coverage) – not to pure-play software ISVs without a services arm. ISV sales teams frequently request ECIF for customer POC funding; for most software-only ISVs this is structurally unavailable. The common workaround – engaging an ECIF-accredited services partner – is operationally difficult during an active sales cycle. AWS has broadly equivalent programs (MAP, POA) with the same structural constraint; Google Cloud’s Deal Acceleration Funds (DAF) are a partial equivalent. Full treatment in Cloud Provider Funding.

Express Private Offer

An AWS Marketplace transaction mechanism, launched at re:Invent 2025, that automates custom pricing for partner-defined terms – collapsing some of the manual workflow of a standard private offer. Particularly useful for higher-volume, lower-deal-size ISVs that find the standard private-offer cycle administratively heavy. See Private Offers.

First Party / 1P

Hyperscaler-owned services built, branded and fully operated by the cloud provider – billed through the provider’s console and supported through the provider’s support channels. First-party status is about who delivers and operates the service from the platform’s perspective, not necessarily who invented the underlying technology: a service built on a third-party vendor’s technology but delivered and supported natively by the hyperscaler is still first-party. In field conversation, “1P” is the standard shorthand, almost always meaning “hyperscaler-native service” in contrast to 3P partner and ISV solutions. AEs evaluate 1P options first when a customer has a problem; the ISV enters the picture when those options are insufficient – which is the structural reason the co-sell motion exists. See Hyperscaler Co-Sell.

FSR

Field Sales Representative (FSR): Google Cloud’s primary customer-facing sales role, broadly equivalent to the AWS AE and Microsoft AE. Carries quota on customer cloud consumption growth and, increasingly, customer-side marketplace transactions. The FSR owns the overall customer relationship on Google Cloud enterprise accounts and is the natural first point of contact for ISVs approaching a new Google Cloud account from the outside. For technically deep or workload-specific products, the FSR will typically route ISV engagement to the relevant CE or specialist sales counterpart, in the same way the Microsoft AE routes to the STU. See Google Co-Sell.

FTR

Foundational Technical Review (FTR): AWS’s validation that an ISV’s product meets baseline AWS architectural and operational standards. FTR gates most Specialisations, access to partner funding programmes and the ISV Accelerate (ISVA) programme; it is not a mandatory prerequisite for all marketplace listings. Since late 2024, AWS has automated part of the review using Amazon Bedrock, reducing decision times to as little as 30 minutes for qualifying submissions – though preparation effort typically still runs to weeks. FTR approval is valid for three years (extended from two in late 2024) and is not a one-time event; re-validation is required as the architecture evolves. Partners who have completed an AWS Well-Architected Framework Review with an AWS employee within the preceding 12 months, with no high-risk items, may qualify for a waiver. See Cloud Partner Programs and Specialisations.

Google Cloud Partner Network

Google Cloud’s partner programme, formally launched in Q1 2026 with a six-month transition window from Google Cloud Partner Advantage (itself formerly the Google Cloud Partner Program). Three tiers – Select, Premier and Diamond – with progression based on proven customer success. A competency model replaced the older specialisation model, with two achievement levels: Competency and Advanced Competency. Partner paths include Co-sell Partner, Services Partner and Technology Partner, among others; the legacy Build/Sell/Service archetypes belonged to Partner Advantage and are no longer current. ISVs typically engage via the Technology and Co-sell paths. See Cloud Partner Programs and Specialisations and Google Co-Sell.

Google Cloud Channel Partner Private Offer

The legacy name for the mechanism now formally designated Marketplace Channel Private Offer (MCPO). See MCPO.

Hyperscaler

The three largest public-cloud providers – Amazon Web Services, Microsoft Azure and Google Cloud Platform – treated as a distinct category from other cloud providers because of their scale, partner-program structure and consumption-driven GTM motions. Used throughout this series as the precise referent; “cloud provider” denotes the broader category that also includes Oracle Cloud, IBM Cloud, Alibaba Cloud and others.

ISV

Independent Software Vendor (ISV): a software company selling products to end customers, distinct from a channel partner (reseller) or services partner (SI, MSP, consultancy). The primary audience archetype throughout this series.

ISV Accelerate

AWS ISV Accelerate (ISVA): the formal AWS co-sell programme for software partners. Current eligibility requires: Validated or Differentiated status in AWS Partner Central (Software Path); at least one generally available marketplace listing; ACE programme eligibility; a minimum of 5 launched opportunities (ACE or Marketplace Private Offers, excluding For Visibility Only submissions) in the prior 12 months; a minimum of 15 qualified ACE opportunities (excluding For Visibility Only submissions) in the prior 12 months; ≥$2,000 in recognised AWS Account revenue; an Amazon Payee Central account; and at least one team member having completed the Co-Selling with AWS learning module. Benefits include AWS Account Managers receiving seller quota retirement when co-selling ISVA partner SaaS solutions via Marketplace Private Offers (the SaaS Co-Sell Benefit, expanded to all ISVA partners from January 2025), inclusion in AWS seller-facing solution libraries and, for partners newly enrolled from January 2026, access to Marketing Development Funds contingent on implementing Partner Revenue Measurement. See AWS Co-Sell.

ISV-Hosted SaaS

The tenancy archetype in which an ISV’s software runs in the ISV’s own hyperscaler account, multi-tenant. Customer pays the ISV; the ISV pays the hyperscaler for the underlying cloud consumption. Aligns naturally with the partner-side PDM motion and with marketplace-led origination, which is why most public cloud-GTM material implicitly assumes this archetype. The contrast with Customer-Deployed Software is the central question of ISV-Hosted vs Customer-Deployed.

ISV Success

A 12-month Microsoft programme for early-stage ISVs to build well-architected applications, publish to Microsoft Marketplace and grow sales. The programme is free in the first year; renewal is $1,550 USD per year. ISV Success is a well-established on-ramp for ISVs starting their Microsoft motion, and enrolment qualifies partners for Preferred Solutions consideration; however, co-sell-ready status is governed by the separate Partner Center co-sell requirements and is not exclusively unlocked by ISV Success. See Microsoft Co-Sell.

Joint Account Plan

A shared planning artefact between the ISV and a hyperscaler-side team (typically AE and PDM) covering a named target account: the customer’s situation, the joint value proposition, named contacts on both sides, planned activities and expected milestones. Most useful for top-50 / top-100 named accounts where the joint motion is worth the investment. See Cloud Alliance Team and Hyperscaler Co-Sell.

MACC

Microsoft Azure Consumption Commitment (MACC): Microsoft’s pre-committed Azure spend mechanism. Purchases of Azure IP Co-Sell Eligible marketplace offers count toward MACC drawdown, which is the dominant procurement driver in enterprise Microsoft co-sell. The AWS equivalent is EDP; the Google Cloud equivalent is CUD. Note for external writing: always use the platform-prefixed form (azure macc or microsoft macc) – the bare acronym is heavily contaminated in search results by an unrelated organisation.

MAICPP

Microsoft AI Cloud Partner Program (MAICPP): Microsoft’s overarching partner programme, which replaced the Microsoft Cloud Partner Program (MCPP), itself formerly the Microsoft Partner Network (MPN). Includes Solutions Partner designations and gates access to co-sell tooling, ISV Success and marketplace publication via Partner Center. See Cloud Partner Programs and Specialisations.

MAP

AWS Migration Acceleration Program (MAP): AWS-funded program supporting assessment, mobilization and migration of customer workloads onto AWS. As of 2026, MAP has expanded beyond traditional migration to include digital transformation and GenAI / agentic workloads. The customer is the recipient of MAP funding; partners participate in execution and benefit from the consumption uplift. Distinct from the partner-focused WMP. See Cloud Provider Funding.

Marketplace Listing Types

The packaging formats supported across cloud marketplaces: SaaS (ISV-hosted, customer subscribes), AMI / VM (machine image for customer to deploy in their AWS or Azure account), Container (containerised workload), Free Trial, BYOL (Bring Your Own Licence – customer brings an existing licence to use within the marketplace) and Private Listing (visible only to invited customers, often used as the vehicle for private offers). Listing-type choice is driven primarily by Tenancy Archetype and by procurement preference. See Cloud Marketplace Listings.

MCCP

Marketplace Customer Credit Programme (MCCP): Google Cloud’s customer-facing incentive, made generally available in May 2025, that provides customers with up to 3% in Google Cloud first-party credits (capped at $250,000 per transaction, disbursed quarterly) when they purchase an eligible ISV solution through Google Cloud Marketplace for the first time – whether directly from the ISV or via a channel partner. The MCCP is a net-new-workload incentive, not a general commit-drawdown mechanism. Committed Google Cloud spend (CUDs and spend-based commits) can be applied to marketplace purchases under the separate Google Cloud Marketplace Commitment Drawdown Policy; the mechanism governing channel-partner commit drawdown specifically is the MCPO programme (from June 2025, 100% drawdown capped at 25% of the customer’s commitment). See Cloud Marketplace and Google Co-Sell.

MCEM

Microsoft Customer Engagement Methodology (MCEM): Microsoft’s named sales methodology, used internally to structure customer pursuits and to express opportunity stages inside PSC. ISVs intending to operate inside Microsoft’s field motion need to understand the methodology because co-sold opportunities are typically expected to be expressed in MCEM stages – opportunities that don’t map cleanly tend to stall in handover. See Microsoft Co-Sell.

MCPO

Marketplace Channel Private Offer (MCPO): Google Cloud Marketplace’s formal mechanism for channel-partner-routed private-offer transactions, equivalent in intent to AWS CPPO and Microsoft MPO but structurally different in billing architecture. From June 2025, MCPO transactions count 100% toward a customer’s committed Google Cloud spend, capped at 25% of the total commitment. Fees are tiered by deal size: 1.5% for deals of $10M or more, 2% for deals between $1M and $10M, and 3% for smaller deals. See Private Offers and Google Co-Sell.

MDF

Marketing Development Funds (MDF): hyperscaler-funded budget reimbursable against partner marketing activities tied to consumption growth on that hyperscaler. All three hyperscalers run MDF programs, with activity-based or accrual-based models depending on program tier or specialisation. Eligibility is almost always tied to program tier; sign-off is almost always tied to a hyperscaler-side champion (typically the PDM). See Cloud Provider Funding.

MPO

Multiparty Private Offer (MPO): a Microsoft Marketplace transaction structure that includes an ISV, a channel partner and the end customer in a single marketplace transaction, preserving MACC drawdown and paying both ISV and channel partner directly – the ISV receives their partner price minus the 3% standard marketplace service fee; the channel partner receives their markup fee-free. The AWS equivalent is the CPPO; the Google Cloud equivalent is the MCPO, which has structurally different billing architecture and commit-drawdown mechanics. See Private Offers.

MPOPP

Marketplace Private Offer Promotion Program (MPOPP): an AWS fee and incentive program tied to partner-led marketplace transactions. Specific mechanics and eligibility windows shift over time, so any deal modelling that depends on MPOPP should check current AWS terms rather than rely on documented detail. See Cloud Provider Funding and AWS Co-Sell.

Partners / Partnerships

Deliberately avoided as standalone terms in this series because they are too broad to be consistently meaningful. “Partners” can mean channel resellers, hyperscalers, technical integration partners, co-marketing collaborators or all of the above depending on the company. “Partnerships” as a function title covers an equally wide range. Wherever possible this series uses the more specific term: alliance for the hyperscaler GTM motion, channel partner for the reseller/SI network, and ISV or technology partner for integration relationships. See the hub’s terminology note.

P2P

Partner-to-Partner (P2P) opportunities: a Microsoft co-sell construct in which two partners (typically an ISV and a services partner) jointly share and progress an opportunity through PSC. Often the operational form of MPO-bound deals before the marketplace transaction is structured. See Microsoft Co-Sell.

Partner Center

Microsoft’s partner-facing portal – the system of record for MAICPP enrolment, Solutions Partner designations, marketplace offer publication and co-sell opportunity sharing via PSC. Often confused with AWS’s Partner Central; they are distinct systems run by different vendors, and the spelling difference is the only practical disambiguator. See Microsoft Co-Sell.

Partner Central

AWS’s partner-facing portal – the system of record for AWS Partner Network membership, Partner Paths, Specialisations and ACE opportunity sharing. Often confused with Microsoft’s Partner Center; the systems are run by different vendors and serve different programs. See AWS Co-Sell.

PDM

Partner Development Manager (PDM): the named hyperscaler-side representative assigned to manage the relationship with a partner. The PDM’s structural incentives – partner-side metrics, marketplace transactions, program adoption – differ from those of the customer-facing AE, who is paid on customer consumption growth. This split has major consequences for ISVs whose products run in customer cloud accounts rather than their own. See ISV-Hosted vs Customer-Deployed for the dynamic and Cloud Alliance Team for how the partner-side function maps to the hyperscaler PDM.

Preferred Solutions

A Microsoft Marketplace badge surfaced to customers as a quality signal. Eligibility requires either Azure IP Co-Sell Eligible status or enrolment in ISV Success with co-sell-ready status. The badge significantly affects marketplace discovery for relevant offers. See Cloud Marketplace Listings and Microsoft Co-Sell.

Principal vs Agent

A revenue-recognition question under ASC 606 / IFRS 15: when a transaction flows through a marketplace, is the ISV the principal (recognising gross revenue, treating the marketplace fee as cost of revenue) or the agent (recognising net revenue only)? The answer depends on who bears risk, sets price and controls the good or service – and the determination has material consequences for reported revenue, channel-partner deal treatment and audit posture. See Cloud Marketplace Operations.

Private Listing

A marketplace listing visible only to specific invited customers, used to expose custom pricing, custom terms or restricted-distribution products without making them publicly available. Distinct from a private offer, which is a transaction structure rather than a listing format – though private listings are commonly the vehicle through which private offers are presented. See Cloud Marketplace Listings and Private Offers.

Private Offer

A custom commercial transaction in a cloud marketplace in which an ISV offers a specific customer privately negotiated pricing, terms, duration or payment schedule not available in the public listing. Private offers are the standard transactional mechanism for enterprise cloud marketplace deals: they preserve the procurement benefits of marketplace (single bill, committed-spend drawdown, click-to-accept contracting) while accommodating the commercial reality of individually negotiated enterprise contracts. All three hyperscalers support both direct ISV-to-customer private offers and multi-party variants involving channel partners: AWS Private Offers and CPPOs; Microsoft Customer Private Offers and MPOs; Google Cloud Private Offers and MCPOs. See Private Offers.

PSM

Partner Sales Manager (PSM): an AWS field role focused on partner-attached and partner-originated revenue in named accounts, verticals or territories. Where the PDM manages the formal partner relationship and program mechanics, the PSM operates on the deal and pipeline side – owning partner-sales forecasting, co-sell engagement and partner-contribution revenue against a quota. PSMs are measured primarily on partner-origination and partner-attachment outcomes rather than partner-program participation metrics, making them a more commercially motivated co-sell engagement target than PDMs for ISVs pursuing named enterprise accounts. The role has no current equivalent at Microsoft (the Enterprise Channel Manager was eliminated in early 2023) or at Google Cloud. See AWS Co-Sell.

PRACR

Partner Reported Azure Consumed Revenue (PRACR): pronounced “Pracker” in Microsoft field conversation. Microsoft’s mechanism for ISV-hosted SaaS partners to report Azure consumption against customer deals, enabling that consumption to be credited against the customer’s MACC commitment. Relevant specifically to ISV-Hosted SaaS ISVs: because their workload runs in the ISV’s own Azure tenant rather than the customer’s, standard Azure Consumed Revenue (ACR) tracking – which only sees consumption in customer tenants – cannot associate the ISV’s Azure spend with the customer’s MACC drawdown. PRACR bridges this gap via monthly CSV submissions in Partner Center, with each submission associating ISV-side consumption with specific customer deals via Subscription GUIDs and referral IDs. Eligible partners must hold a Solutions Partner certified software designation. The process is manual and ongoing – not a set-and-forget implementation. Distinct from CUA (Customer Usage Attribution), which is the mechanism for customer-deployed ISVs. See Microsoft Co-Sell and ISV-Hosted vs Customer-Deployed.

Producer Portal

The Google Cloud Marketplace seller portal – Google’s equivalent of Partner Center (Microsoft) and Partner Central (AWS) for marketplace-listing administration, offer creation and reporting. See Cloud Marketplace Listings and Google Co-Sell.

PSC

Partner Sales Connect (PSC): a legacy informal name for Microsoft’s co-sell opportunity-sharing system, now formally known as the Co-sell opportunities workspace within Partner Center Referrals. The system is the Microsoft equivalent of AWS’s ACE; the two have similar purposes but meaningfully different submission requirements and acceptance mechanics. See Microsoft Co-Sell.

PRM

Partner Revenue Measurement (PRM): AWS’s mechanism for measuring AWS service consumption driven by partner solutions in customer accounts. Launched January 2026. Supports three implementation methods: AWS Marketplace Metering (zero-touch for AMI and ML products listed on AWS Marketplace – attribution is automatic when customers purchase via Marketplace); Resource Tagging (tag AWS resources in the customer account with the ISV’s Marketplace product code using tag key aws-apn-id); and User Agent String (include a tracking string in AWS API/CLI calls the product makes in the customer account). Relevant to customer-deployed ISVs: PRM makes the ISV’s contribution to customer-side AWS consumption visible to AWS’s internal systems, accessible via the Attributed Revenue Dashboard in Partner Central. AWS Marketplace Metering is the lowest-friction path for products already listed on marketplace. Broadly analogous to Microsoft’s CUA for customer-deployed workloads; there is no AWS equivalent to Microsoft’s PRACR for ISV-hosted SaaS. See ISV-Hosted vs Customer-Deployed and AWS Co-Sell.

SA

Solutions Architect (SA): AWS’s customer-facing technical role, pre-sale in orientation. Broadly equivalent to Google Cloud’s CE and to Microsoft’s TSP / SSP range – the SA sits between pure technical pre-sales support (TSP) and quota-carrying specialist selling (SSP) depending on the engagement. Not equivalent to Microsoft’s CSA, which is a post-sale Customer Success role. SAs lead technical solution design, support proof-of-concept work and act as technical sponsors for marketplace and co-sell pursuits. Specialist SAs cover specific workload areas (analytics, security, generative AI, etc.) and are often the most effective field engagement point for customer-deployed ISVs. See AWS Co-Sell.

SSP

Solution Sales Professional (SSP): a Microsoft specialist seller within the STU (Specialist Technology Unit), focused on selling specific solution areas such as Azure infrastructure, data and AI, security or application innovation to named accounts. SSPs carry solution-area quota and are typically more technically engaged with workload specifics than the account-level ATS. For customer-deployed ISVs whose product solves a specific Azure workload problem, the relevant SSP is often the most productive Microsoft field contact – they have the customer workload context, the technical credibility to evaluate the ISV’s solution and a quota incentive to act. See Microsoft Co-Sell.

STU

Specialist Technology Unit (STU): pronounced “Stew” in Microsoft field conversation. Microsoft’s specialist selling organisation, distinct from the ATU (Account Technology Unit) that manages the overall customer relationship. The STU contains SSPs (Solution Sales Professionals) and TSPs (Technical Sales Professionals) organised by solution area. STU members are focused on specific Azure workloads and tend to be the originating source of hyperscaler-led introductions for customer-deployed ISVs – they encounter customer workload problems that require third-party solutions more directly than ATU members, and they carry workload-specific quota that gives them an incentive to act. Microsoft’s internal naming for these roles evolves; the function is consistent even when the acronyms change. See Microsoft Co-Sell.

TSP

Technical Sales Professional (TSP): a Microsoft technical specialist within the STU, providing deep technical pre-sales support for a specific solution area. TSPs support SSPs on complex technical deals, run proofs of concept, and act as technical validators for ISV solutions within Microsoft pursuit teams. For customer-deployed ISVs, the TSP counterpart is often the decision-maker for whether a third-party solution is viable for a customer’s workload. See Microsoft Co-Sell.

SaaS Co-Sell Benefit

An AWS mechanism that gives AWS sellers quota retirement credit when they co-sell partner SaaS through a marketplace private offer. It substantially changes AWS field-seller behaviour toward ISVs whose products fit this model. Less impactful for customer-deployed products that don’t transact this way – which is one of the structural distinctions explored in ISV-Hosted vs Customer-Deployed. See also AWS Co-Sell.

Solutions Partner Designation

A Microsoft program tier under MAICPP indicating that a partner has demonstrated capability in one of six “solution areas” (Infrastructure (Azure), Data & AI, Digital & App Innovation, Modern Work, Security, Business Applications). Replaces the older Microsoft “competency” model. Often described as Microsoft’s equivalent of an AWS Specialisation, with similar gating consequences for co-sell tooling and marketplace badges. See Cloud Partner Programs and Specialisations.

Specialisation

A hyperscaler validation that a partner has demonstrated technical and commercial proficiency in a specific workload, industry or use case. At AWS, Specialisation is the umbrella term; AWS Competency is a current Specialisation type validating technical excellence in specific industry and use-case domains, distinct from Service Delivery, Service Ready and MSP Specialisation types. Microsoft uses Solutions Partner designations with associated specialisation sub-badges; Google Cloud uses a competency model, revised in Q1 2026. Customer research consistently shows specialisations as one of the top selection criteria when end customers choose a partner. See Cloud Partner Programs and Specialisations.

Technical Alliance

A partnership between an ISV and another technology vendor (including a hyperscaler) centred on product integration, API connectivity or joint technical development rather than on commercial co-sell or marketplace activity. Technical alliances typically involve engineering-team relationships, joint reference architectures, integration certifications and co-marketing of the integrated solution. Distinct from a cloud alliance in this series: a technical alliance with a hyperscaler (e.g. an AWS-validated integration, a Microsoft Azure Certified solution) supports but does not substitute for the co-sell GTM motion. The engineering-to-engineering relationship that underlies technical alliances is covered in Cloud Alliance Team.

Tenancy Archetype

The architectural question of whose cloud account an ISV’s software runs in: ISV-Hosted SaaS, Customer-Deployed Software or hybrid (control plane in the ISV’s tenant, data plane in the customer’s). This single distinction reshapes which hyperscaler roles are paid to support the ISV, which co-sell motions actually work and what the partner-side team should look like. The definitive reference is ISV-Hosted vs Customer-Deployed.

Third Party / 3P

Products and services provided by independent software vendors (ISVs) and partners – built and operated by the vendor rather than the hyperscaler, and typically surfaced through cloud marketplaces or partner programs. The hyperscaler acts as a distribution channel and billing integration layer; support is the vendor’s responsibility. “3P” is the field shorthand in contrast to 1P hyperscaler-native services – and every ISV in this playbook is, by definition, a 3P vendor. The cloud marketplace is the primary 3P procurement channel for enterprise customers drawing down EDP, MACC or CUD committed spend. See Cloud Marketplace and Hyperscaler Co-Sell.

Well-Architected Framework (Azure)

Microsoft’s body of architectural guidance for Azure workloads, organised around five pillars: Reliability, Security, Cost Optimisation, Operational Excellence and Performance Efficiency. The Framework is the methodology – the set of design principles and best practices a workload is evaluated against. It is distinct from the Well-Architected Review, which is the assessment instrument. AWS has a parallel AWS Well-Architected Framework (the methodology), alongside the AWS Well-Architected Tool (self-service assessment) and the Foundational Technical Review (the specific partner-program gating assessment). See Microsoft documentation.

Well-Architected Review

The structured assessment in which a partner’s Azure workload is scored against the Well-Architected Framework (Azure). The Review is the assessment instrument – distinct from the Framework itself, which is the body of guidance the Review measures against. Covers five pillars: Reliability, Security, Cost Optimisation, Operational Excellence and Performance Efficiency. The Well-Architected Review is not a formally stated gate for Azure IP Co-Sell Eligible status, which requires a Microsoft technical validation for an Azure-based solution alongside a revenue threshold and transactable marketplace offer; the Review is nonetheless a valuable input to that validation. Google Cloud’s equivalent assessment is the Architecture Review; AWS’s partner-program-gating equivalent is the FTR. Partners report that preparation for a first pass runs to weeks or months per workload, and like FTR it is not a one-time event. See Cloud Partner Programs and Specialisations and Cloud Marketplace Listings.

WMP

AWS ISV Workload Migration Program (WMP): AWS-funded program supporting customers who migrate workloads off third-party technology onto an ISV’s AWS-native solution. As of 2026, WMP offers direct credit disbursement to end customers via marketplace. The ISV is typically the program execution lead; the customer is the financial recipient. Distinct from the broader customer-focused MAP. See Cloud Provider Funding.

Sources

Primary sources used to verify factual claims in this glossary. Inline hyperlinks are used on high-stakes claims (fee rates, eligibility thresholds, programme names, specific numeric values); all sources are listed here in full.

AWS

Microsoft

Google Cloud

Last reviewed: 2026-07-01. Entries are added on a rolling basis as new terms surface across the series.

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/.