Co-Sell Operations: How to Run Co-Sell at Scale Across AWS, Azure and Google Cloud

Running co-sell manually across one hyperscaler is manageable. Running it across two or three, with dozens of active opportunities in flight and a direct sales team that needs pipeline visibility, is not. Co-sell operations is the discipline – people, process and tooling – that makes the motion work at scale without requiring constant manual intervention. This post covers what that looks like in practice.

TL;DR

  • Co-sell at scale is mostly an information-routing problem. Three hyperscaler partner portals (Partner Central for AWS, Partner Center for Microsoft, Google Cloud’s partner portal) plus a CRM plus marketplace systems plus finance ERPs means four to six systems holding overlapping pipeline data that drifts over time.
  • Build vs buy is a real decision with no universally correct answer. Native API integrations to each hyperscaler are achievable but ageing; a Cloud GTM Platform (Clazar, Labra, Suger or Tackle (acquired by AppDirect, December 2025) – named as a category, no endorsement) buys faster time-to-value at the cost of vendor lock; hybrids are common.
  • Pre-decide which system is authoritative for which data field. Without that decision, every system claims authority and disagreements compound. CRM as system of record for accounts; marketplace systems as system of record for transactions; hyperscaler portals as system of record for hyperscaler-side pipeline status.
  • Sales comp plumbing for co-sell is harder than it looks. Quota retirement, multi-party influence credit, AE-PDM-CAM splits and marketplace-routed transactions all need explicit rules agreed in advance.
  • Three failure modes recur: custom integrations that age out within 12 months as hyperscaler APIs evolve, three different pipelines that disagree and no closed-loop attribution back to alliance comp. Each is avoidable with operational discipline.

Why Operations Becomes the Bottleneck

Co-sell starts as a relationship discipline and becomes an operations discipline. The transition is predictable: the first ten co-sold opportunities can run on spreadsheets and a manageable PDM-rhythm call list. The first fifty stretch the CRM. The first hundred break the CRM. By two hundred concurrent active opportunities across multiple hyperscalers, the operations infrastructure is either the load-bearing function of the alliance team or the bottleneck holding the motion back.

The structural reason is information routing. Co-sell at scale is mostly the same data – customer accounts, opportunities, stages, values, owners, marketplace-routing intent – flowing through multiple systems with different ownership models and different update rhythms. Each system holds part of the truth; none holds all of it; and the systems disagree more often than anyone expects.

The volume problem is the obvious one. A mid-sized ISV running co-sell on all three hyperscalers might submit 50–100 ACE / PSC / partner-portal opportunities a quarter, manage 200 active marketplace listings and offers, process 30–60 marketplace transactions a quarter and reconcile 4–6 disbursement files per cloud per quarter. Doing this by hand is possible up to a point and impossible past it.

The variability problem is the less obvious one. Each hyperscaler’s opportunity-sharing system has different submission requirements, different acceptance mechanics and different sync rhythms. Each marketplace has different transaction structures, different metering models and different disbursement schedules. Each finance ERP has its own rules for handling marketplace-routed revenue. Operations infrastructure that handles AWS reliably might break on the second day of Microsoft handling because the schema is subtly different.

The Single Source of Truth Problem

The standard co-sell tooling stack includes at minimum: the ISV’s CRM (Salesforce or HubSpot, typically), the three hyperscaler partner portals, the three marketplace systems, the finance ERP. That’s seven to eight systems, each holding overlapping pipeline data, each updated by different people on different rhythms, each authoritative for different fields.

The drift happens because nobody pre-decided which system was authoritative for which field. The CRM has an opportunity record. The hyperscaler portal has a parallel record. The marketplace has a transaction record. They were the same record once, and now they aren’t, because someone updated the deal value in the CRM but not in the portal, or the close date moved in the portal but not in the marketplace offer, or a stage transition fired in the CRM that didn’t sync.

The fix is upfront design, not retrospective reconciliation. Pre-decide which system is authoritative for which class of data:

  • Account records. CRM is authoritative. Hyperscaler-side account names and identifiers should map to the CRM account ID, not vice versa.
  • Opportunity records. CRM is authoritative for the opportunity itself; hyperscaler portals are authoritative for hyperscaler-side status (ACE acceptance, PSC stage, partner-portal disposition).
  • Marketplace transactions. The marketplace system is authoritative for the transaction record; CRM holds a reference but doesn’t try to be the source of truth.
  • Disbursements and finance. The disbursement file from each hyperscaler is authoritative for what got paid; finance reconciles into the ERP from there.

The discipline is to wire up the syncs around these authority decisions, not in spite of them. When CRM and a hyperscaler portal disagree on opportunity stage, the rule is clear: CRM owns the opportunity, the portal owns the hyperscaler-side disposition and the reconciliation tooling resolves the differences without forcing one to win.

Build vs Buy

The architectural decision that shapes everything downstream. Three options, each with real trade-offs:

Build native integrations. The ISV’s engineering team writes direct integrations to the AWS Partner Central Selling API, the Partner Center Referrals API and Google Cloud’s partner portal co-sell API and Cloud Marketplace billing APIs. Sync logic, conflict resolution and workflow automation are owned in-house. Trade-offs: complete control over the integration surface and zero vendor lock, at the cost of meaningful engineering investment (typically 6–12 person-months for an initial three-cloud integration plus 2–4 person-months per year of ongoing maintenance as the hyperscaler APIs evolve). Hyperscaler APIs change roughly annually – sometimes more often – which means the maintenance burden compounds rather than diminishes.

Buy a Cloud GTM Platform. The ISV subscribes to a third-party platform (Clazar, Labra, Suger or Tackle (acquired by AppDirect, December 2025) – named as a category, no endorsement) that provides the sync layer between CRM and the hyperscaler portals plus marketplace operational tooling. Trade-offs: faster time-to-value (weeks to first-working sync rather than months), maintained API integrations as the hyperscalers evolve their interfaces and a managed roadmap of new features (private-offer automation, multi-party attribution, metering integrations). The costs are subscription fees, vendor lock and the practical reality that the ISV’s tooling stack now includes another vendor relationship that has to be managed.

Hybrid. Native integrations for the highest-value flows (typically the CRM↔Partner Central sync because AWS volumes are usually largest) and a Cloud GTM Platform for the rest. Trade-offs: lower vendor lock than pure-buy, lower engineering investment than pure-build, at the cost of more moving parts and harder integration testing.

A decision guide by company stage:

  • Pre-$10M ARR. Spreadsheets plus CRM. Build vs buy isn’t the decision yet; the decision is which CRM to use and how disciplined the data hygiene is.
  • $10–50M ARR. The common pattern at this stage is platform adoption. Engineering headcount is typically constrained and the opportunity cost of building and maintaining native integrations tends to outweigh the subscription cost – but this depends on the ISV’s available engineering resource and co-sell volume.
  • $50–200M ARR. At this scale the factors shift. Higher co-sell volumes and greater engineering capacity make native integrations for the highest-value flows more viable. Some ISVs move to a hybrid; others remain on platforms indefinitely. Both work.
  • $200M+ ARR. Mature ISVs sometimes consolidate back toward native integrations as the engineering investment becomes affordable and the strategic value of owning the integration surface increases. Others stay on platforms indefinitely; both patterns work.

The pattern that consistently fails: building a custom integration without budgeting for the ongoing maintenance. Year-one builds look feasible; the risk is year-three, when accumulated API changes, schema drift and integration test debt can consume engineering time that wasn’t in the original budget. The honest engineering cost of “build native” is the year-one number plus an explicit annual maintenance budget – not a residual.

Bidirectional Sync Mechanics

A working sync layer handles three flows in each direction between CRM and each hyperscaler partner portal:

Opportunity sync. New opportunities created in CRM should be available for submission to the relevant hyperscaler’s ACE / PSC / partner portal. Submitted opportunities should sync back acceptance / decline status and current stage. Stage transitions in the CRM that cross a defined threshold (e.g., qualified-to-active) should propagate to the portal automatically where appropriate.

Account sync. Customer account records in CRM should map cleanly to the hyperscaler-side account names. The mapping is non-trivial: customer subsidiaries, parent-company relationships, regional variations and DBA names all produce naming divergences that cause ACE / PSC declines if not handled. Most mature implementations maintain an account alias layer that maps multiple hyperscaler-side names to a single authoritative CRM account ID.

Contact sync. Customer contacts and hyperscaler-side counterparts (PDMs, AEs, specialist sellers, CEs) should be visible to the alliance team in both directions. The CRM holds the definitive contact records; hyperscaler-side counterparts can be tagged for visibility but shouldn’t be syncable in both directions (the hyperscaler side doesn’t expose its CRM to partners).

The approach to storing hyperscaler-side counterparts in the CRM deserves specific attention. A common early implementation – adding custom fields to the account or opportunity record to name each hyperscaler role (Microsoft AE, Microsoft ATS, Microsoft CSA and so on) – breaks down reliably for three reasons: account teams rotate and custom fields don’t update themselves; roles like SSP and CSA are many-to-one on accounts, so a single field cannot represent the full relationship picture; and the resulting structure sits outside Salesforce’s native relationship model and requires ongoing maintenance that typically goes unowned. The approach that works in practice is to add hyperscaler account team members directly as contacts on the opportunity record, using the standard Salesforce Contact entity and the existing opportunity-contact relationship. Multiple named counterparts per opportunity, each with their own contact record and role designation, accessible through standard Salesforce reporting and activity logging. The same mechanism handles the many-to-one problem cleanly – two CSAs and three SSPs on the same account appear as distinct opportunity contacts rather than as a broken field.

A Microsoft-specific complication worth noting: Practitioners familiar with the programme note that Microsoft employees typically have two email addresses – a display-name form (firstname.lastname@microsoft.com) and a shorter alias form (alias@microsoft.com). Where email address is used as the deduplication key in the CRM – which is the Salesforce default – the same counterpart introduced via different addresses at different touchpoints will be created as two separate contact records. Deduplication logic or a manual merge convention is required to prevent this accumulating at scale. Whether AWS or Google have an equivalent dual-address pattern is not confirmed, but it appears to be a Microsoft-specific issue in practice.

What doesn’t sync, and shouldn’t: customer financial information beyond opportunity value (subscription tier, contract structure, payment terms); internal hyperscaler routing decisions (which AE is currently assigned, which industry team is engaged); pre-decision discussion (the hyperscaler-side internal Slack threads about whether to engage on a deal). The boundary matters – partners that try to over-integrate find themselves running into hyperscaler-side privacy and compliance constraints.

Conflict resolution: when CRM and portal disagree on a field that exists in both, the resolution rule is established at design time per field. Stage transitions: CRM wins, portal updates. Acceptance status: portal wins, CRM updates. Deal value: CRM wins (the partner owns the commercial conversation). Close date: CRM wins for forecasting purposes; portal can hold a separate hyperscaler-side close date if the field exists.

Account Mapping and ICP Enrichment

The single most underrated operations discipline. Account mapping comparing the ISV’s customer and prospect list against the hyperscaler’s customer list to find overlap is covered conceptually in Hyperscaler Co-Sell; this section is about how to do it in practice.

The mechanics: at quarterly rhythm (or more often for primary clouds), the alliance ops team should produce an enriched account list that flags each CRM account with hyperscaler-specific data:

  • Hyperscaler commit status. Is this account on an AWS EDP? A Microsoft MACC? Google CUDs / MCCP? The commit status changes which co-sell motion is viable.
  • Hyperscaler-side relationship coverage. Which named PDM / AE / CSA / CE counterparts are mapped to this account? Has the alliance team engaged with them in the trailing 90 days?
  • Tenancy archetype implications. For customer-deployed ISVs, the AE relationship matters more than the PDM (see ISV-Hosted vs Customer-Deployed). The account enrichment should surface which hyperscaler-side counterparts are relevant per archetype.
  • Marketplace transaction history. Has this customer transacted with the ISV through marketplace before? If yes, which cloud and which type of offer? Repeat marketplace customers are systematically easier to close than first-time marketplace buyers.

The enrichment data lives in CRM custom fields; the population is partly automated (from hyperscaler-side data the partner has access to, marketplace transaction records, third-party intent-data tools) and partly manual (PDM-reported commit status, named-relationship coverage).

A quarterly account-mapping review with sales leadership produces the joint-pursuit prioritisation that drives the next quarter’s co-sell motion. ISVs that skip this step end up running co-sell on whatever opportunities happen to be in pipeline rather than on the opportunities where co-sell engagement actually moves the needle.

Workflow Automation Patterns

Beyond bidirectional sync, several workflow patterns recur across mature co-sell operations:

Auto-share inbound opportunities under defined rules. When a CRM opportunity meets specified criteria (deal value above threshold, customer on relevant hyperscaler commit, product fits a defined co-sell-eligible category), automatically pre-fill an ACE / PSC submission for human review. Reduces submission friction without removing the human quality check.

Auto-create portal records on stage transitions. When an opportunity hits a defined CRM stage (e.g., qualified, demo-completed), the workflow creates the corresponding hyperscaler-portal record automatically. Particularly useful for ISV-hosted SaaS partners with high opportunity volumes.

Auto-generate private offers from CRM data. Pre-populate marketplace private-offer templates from CRM opportunity data (customer name, agreed pricing, contract length, support tier). The alliance team reviews and submits rather than typing from scratch. Cuts private-offer cycle time significantly – often from days to hours.

Notifications to Slack / Teams. Alert the relevant alliance manager when an ACE / PSC submission is accepted, declined or stalled; when a private offer is accepted by a customer; when a marketplace transaction closes. Real-time visibility into co-sell state reduces the human attention required to keep the motion running.

Lapsed-relationship surfacing. Flag named hyperscaler-side counterparts where the alliance team hasn’t logged a touch in the trailing 60 / 90 / 120 days. Relationship hygiene is one of the easiest things to let drift and one of the highest-leverage things to maintain.

The automation principle: automate the high-frequency, low-judgement work so the alliance team can spend their time on the low-frequency, high-judgement work. Submitting an ACE record is high-frequency and low-judgement; designing a joint account plan is the opposite.

Reporting and KPIs

The co-sell operations function owns the reporting layer that surfaces alliance KPIs. The taxonomy below maps to the broader KPI model that recurs across this series:

Pipeline metrics. Sourced pipeline (originated by the hyperscaler) and influenced pipeline (worked jointly but not hyperscaler-originated), tracked separately per cloud and summed to a total alliance-attributed pipeline figure.

Conversion metrics. Win rate uplift on co-sold deals vs direct-only deals. Deal size uplift on co-sold deals. Sales cycle compression on co-sold deals. Track these by cloud and by tenancy archetype – the dynamics differ significantly.

Sourced/influenced mix. Worth monitoring but interpretation is situational: a high influenced proportion may reflect a healthy outbound ISV motion rather than a weak hyperscaler relationship; a high sourced proportion may reflect a concentrated new-business focus rather than a maturing co-sell motion. The mix reads differently depending on new-business versus expansion ratio, deal size profile and where the business is in its hyperscaler relationship lifecycle. Pipeline size and conversion metrics are the primary indicators of a working co-sell motion; the sourced/influenced breakdown is context, not verdict.

System health metrics. ACE / PSC / partner-portal opportunity acceptance rates per cloud. Marketplace transaction rate. Days from opportunity submission to hyperscaler acceptance. Days from private offer creation to customer acceptance.

Operational metrics. CRM↔portal sync error rate. Days from disbursement file to ERP reconciliation. Account-mapping freshness (days since last quarterly refresh). Lapsed-relationship count.

Comp metrics. Alliance comp paid as a percentage of attributable closed-won revenue. Comp disputes count per quarter. Days from deal closed to comp credited.

Most alliance functions over-report on pipeline and conversion metrics and under-report on system health, operational and comp metrics. The under-reporting matters because operational and comp metrics are the leading indicators for whether the function will scale; pipeline and conversion metrics are lagging.

Hyperscaler-led Inbound: Triage and Readiness

Hyperscaler-led inbound is not a homogeneous category and should not be managed with a uniform response policy. The profile of the opportunity – its urgency, its qualification level and the speed at which it requires a response – varies significantly depending on who is bringing it and, critically, on the ISV’s tenancy archetype. The operational failure is treating all inbound as equivalent.

Two distinct inbound profiles.

Account team or CS-originated inbound. The highest-value and most time-sensitive category. When a hyperscaler’s customer-facing AE or customer success team brings an ISV into a pursuit, it is typically because their own internal options have been exhausted – first-party (1P) services, third-party products, internal professional services. The customer’s problem is not only real but technically documented. Both the hyperscaler and the customer have a detailed understanding of the constraints. The urgency is often acute: the customer may be exasperated; the hyperscaler’s CS team may have C-Sat exposure; the AE may have a customer threatening to evaluate a competing cloud provider. These opportunities arrive fast and close fast, or they close elsewhere. A response measured in days, not weeks, is the operational requirement. This profile is most common for customer-deployed ISVs, whose consumption pattern aligns with the incentives of the customer-facing account team and specialist sellers rather than the partner-side PDM.

PDM-originated inbound. A structurally different category. PDMs are measured on partner-program participation, pipeline activity and marketplace metrics. Opportunities brought by a PDM may be early-stage, lightly qualified and not urgent from the customer’s perspective. This is not a criticism of PDMs – generating activity is their job. But treating PDM-originated inbound with the same urgency as CS or account-team inbound misallocates the ISV’s most constrained resource: senior technical and commercial time. Standard qualification discipline applies. This profile is more common for ISV-hosted SaaS partners, whose PDM relationship is their primary hyperscaler engagement layer.

The triage model. On receipt of any hyperscaler-led inbound, the alliance manager should determine: who is the source (partner-side PDM vs customer-facing AE or CS); what is the customer’s situation (active problem vs early exploration); has the hyperscaler already invested commercial or CS time in the account; and what is the stated timeline. The answers place the inbound into one of two tracks:

Urgent track – CS or account-AE originated, documented customer problem, hyperscaler has skin in the game. Immediate response within hours, not days. Senior technical and commercial resource committed. Pre-built materials activated (technical narrative matched to workload profile, consumption-uplift evidence, reference customers in the relevant segment). If the ISV cannot respond at this speed, the opportunity will be redirected to a partner who can.

Standard track – PDM-originated or early-exploration. Standard qualification call within two to three business days. Alliance manager assesses whether to bring in direct AE and technical resource, or to continue at the alliance team level until qualification warrants escalation.

The readiness infrastructure. The ability to respond effectively to urgent-track inbound is not improvised. It is the product of months of upstream investment: pre-built workload-specific technical narratives, named-customer consumption-uplift case studies, a direct AE and SE who are briefed on the product’s technical differentiation and available for fast activation, and an alliance manager who has already mapped the relevant hyperscaler account team and knows who to call. ISVs that have not built this infrastructure discover the gap in the moment it matters most – when a Sunday-evening CS message arrives and the Monday-morning call requires people who are prepared, not people who are learning the product that morning.

Sales Comp and Pipeline Governance

Comp is where co-sell operations meets sales operations meets finance. The structural challenge is that a single co-sold deal can produce comp obligations to multiple people: the direct AE who worked the deal day-to-day, the alliance manager who brought the hyperscaler in, the hyperscaler-side AE whose quota retires on the customer-cloud-consumption, sometimes a channel partner in CPPO / MPO structures. The comp plumbing has to resolve these claims without double-counting or under-paying.

Three rules of thumb that prevent most comp-related disputes:

1. Define credit-sharing rules in writing before deals close. Documented credit-sharing rules for alliance-influenced and alliance-sourced deals, agreed by sales and alliance leadership and reviewed quarterly. Without documentation, every closed deal triggers a comp negotiation. The detailed mechanics of credit-sharing structures (shared quota credit, alliance MBO + influence multiplier, dedicated alliance carve-out) are covered in Cloud Alliance Team.

2. Distinguish quota retirement from incremental booking. Quota retirement is the credit applied to a seller’s existing quota – they were going to be measured against $X of bookings; this deal counts toward that. Incremental booking is comp paid above and beyond quota – an explicit incentive on top of base attainment. Co-sell comp structures use both, but the alliance team needs to know which is which on every deal.

3. Wire marketplace-routed transactions into the comp system directly. Marketplace transactions don’t follow the same plumbing as direct invoicing. The disbursement-to-ERP latency (typically 45–60 days from customer billing close to seller disbursement) means marketplace-routed comp lags direct-invoice comp by a quarter or more. Sellers who don’t understand this find themselves wondering why a closed deal didn’t appear on their comp report; alliance teams that don’t explain the timing get blamed for it.

4. Address the Reverse-Direction Comp Problem Directly. The standard comp-alignment discussion focuses on AEs having insufficient incentive to work alliance-sourced deals. The less-discussed reverse problem is equally real: the alliance team having no incentive to support AE-sourced deals. When an AE has a deal they want alliance help to re-energise or accelerate, the CA team’s comp structure gives them no reward for doing so – their metrics credit sourced and influenced pipeline, not support work on deals they didn’t originate. The rational CA response, absent any other provision, is to wait until the deal ages out, gets closed-lost and can be re-opened with the CA team as the source. This is individually rational and organisationally destructive. The fix requires either explicit comp provision for CA support work on non-sourced deals above a value threshold, or a senior-GTM-approved case-by-case process for high-value situations. At low deal volumes the case-by-case model is manageable; at higher volumes a comp design solution is required.

The two fixes that matter. Everything else is downstream of these.

The first is a universally agreed definition of a stage-one opportunity, signed jointly by the VP of Alliances and the VP of Sales (or their functional equivalents), and enforced as operational policy rather than left as guidance. The definition must specify the minimum conditions that must be met before an account is registered as a stage-one alliance-sourced deal: at minimum, a named contact at the prospect, evidence of hyperscaler field engagement and a documented reason to believe the prospect has a problem the ISV can solve. Without this definition, every contested registration becomes a judgement call, and the party with more internal leverage – usually direct sales – wins.

The adjudication model matters as much as the definition. At low volumes, contested registrations can be resolved between the VP of Alliances and VP of Sales directly. At scale this creates a corrosive dynamic: the head of alliances repeatedly asking for credit they believe they have already earned, the relationship accruing favours rather than operating as policy. A more durable model assigns adjudication to a neutral party in Sales Ops or RevOps – someone with no direct stake in the outcome and a clear set of guidelines to apply. CAMs can then escalate a missed stage-one directly through ops rather than upwards through leadership, removing most of the interpersonal friction from what is otherwise a routine operational question.

An alternative sometimes proposed: the CAM creates a stage-one record in a holding state until the AE accepts it. The structural problem is that the AE was typically present at the meeting the hyperscaler arranged and sponsored – a holding record they have not acknowledged is difficult to enforce without triggering the same VP-to-VP conversation you were trying to avoid. Clear definition plus neutral adjudication is the more robust answer.

The second is active pipeline inspection and funnel management for alliance-sourced opportunities, owned by Sales leadership and enforced by Sales Ops or RevOps. Stage-one opportunities that have not progressed past a defined threshold within a defined period should be subject to mandatory review, with clear criteria for advancement or removal. This is standard practice for direct-sales pipeline and is routinely absent for alliance-sourced pipeline, partly because sales leaders are less familiar with cloud alliance mechanics than with other top-of-funnel sources, and partly because the alliance function rarely has the organisational standing to demand it.

The organisational dynamics around the second fix deserve naming directly. In practice, the head of alliances often finds themselves in a position that is weaker by design than their nominal peer status would suggest when trying to get pipeline management applied to alliance-sourced deals. The VP of Sales controls the sales operations function, the CRM configuration and the forecast cadence. The head of alliances is dependent on that infrastructure without owning it. Persistent advocacy for proper pipeline governance on alliance-sourced deals – even when the advocacy is entirely legitimate – risks being perceived as friction or special pleading rather than as operational management. This is not a failure of individuals; it is a structural consequence of organisational design, and it is the main reason why the VP of Alliances / VP of Sales relationship is the single most important internal relationship for the alliance function to get right.

What happens when the governance doesn’t exist. A composite illustration, drawn from patterns across multiple real situations:

A $120M ARR infrastructure ISV had built a cloud alliance function that was generating roughly 60 stage-one alliance-sourced opportunities per quarter by month 18, against a target of 30. On paper the function was outperforming. In practice, approximately 40% of those opportunities were not progressing past stage one despite repeated review cycles. The CFO flagged the conversion rate discrepancy at a board prep session. The board meeting was six weeks away.

The VP of Alliances proposed removing the stale opportunities from the active pipeline – a standard hygiene exercise that would immediately reduce the total stage-one count and improve the conversion metrics that mattered for management reporting. The VP of Sales did not object to the logic but noted that removing the opportunities before the board meeting would reduce the total pipeline figure reported to the board by approximately 12% compared to the prior quarter, which would require explanation at a moment when the company was in a fundraising-adjacent discussion. The CFO made the decision: the opportunities would remain in the pipeline until after the board meeting.

Six weeks later, the opportunities were removed. The conversion metrics improved significantly. The underlying problem – a stage-one definition that was too loose, an AE population that had been creating registrations without real qualification, and a pipeline governance cadence that applied to direct sales but not to alliance-sourced deals – was addressed over the subsequent two quarters. The alliance function’s credibility recovered, but slowly.

The lesson is not that zombie pipeline is inevitable. It is that the conditions that produce it are structural and predictable, and that the governance needed to prevent it has to be designed and agreed before the pipeline builds up, not after leadership notices the conversion numbers.

Tooling Category Landscape

The Cloud GTM Platform category includes (alphabetically, no endorsement) Clazar, Labra, Suger and Tackle (acquired by AppDirect, December 2025). These vendors target broadly similar problems but differ in emphasis: some are stronger on marketplace operations, some on co-sell sync, some on multi-cloud parity, some on industry-specific specialisation. Detailed product comparison is outside the scope of this post and changes year-on-year as the vendors evolve.

AWS Partner Central Agents (March 2026). A development worth tracking in the context of co-sell operations tooling: AWS has launched an agentic AI layer within Partner Central itself, automating opportunity field population from meeting notes, funding eligibility identification and pipeline intelligence queries. Partners can also access these capabilities from their CRM via MCP integration. This partially overlaps with the Cloud GTM Platform value proposition – reducing manual overhead in ACE submissions and opportunity management – but comes from AWS directly rather than a third-party vendor, and is currently available only to partners on the new Partner Central console experience. Microsoft and Google have not launched equivalent co-sell operations agents at the time of writing. See AWS Co-Sell for the detailed treatment.

Hyperscaler Fiscal Year and the Engagement Calendar

One of the most consistently underestimated operational inputs to co-sell planning is the hyperscaler’s fiscal year. AWS and Google Cloud both run January to December; Microsoft runs July to June. These dates shape the availability, receptiveness and priorities of the hyperscaler field in ways that directly affect the ISV’s co-sell motion.

The AE availability window. For customer-deployed ISVs whose primary co-sell counterpart is the hyperscaler AE, field availability tracks the fiscal year tightly. The final six to eight weeks of any fiscal quarter are difficult windows for non-urgent alliance engagement. The final weeks of the fiscal year are effectively closed: enterprise AEs are managing committed-revenue close plans, customer dinners and internal forecast reviews. An unsolicited alliance introduction or a new joint account plan request landing in late May (for Microsoft) or late November (for AWS and Google) will be deferred indefinitely unless it comes with a credible, near-term, material close attached.

The opening weeks of a new fiscal year are among the most productive windows in the alliance calendar. AEs have fresh quota and no near-term pipeline pressure. New joint account plans, introductory meetings, Specialisation co-sell conversations and named-account planning all land significantly better in the first six to eight weeks of the fiscal year.

The PDM-side seasonality. The PDM’s quota structure produces a different pattern. A PDM under end-of-quarter pressure to close out pipeline and marketplace metrics can be more motivated to push ISV opportunities forward – but only for ISVs with a track record of delivering quality submissions. End-of-quarter is not the moment to submit poor-quality or template ACE entries.

The practical planning implication. ISVs should maintain a co-sell engagement calendar that tracks the fiscal year boundaries of each engaged hyperscaler:

  • Q1 of the hyperscaler’s fiscal year: front-load relationship-building, joint account planning and Specialisation conversations.
  • Q2–Q3: execute on the joint plans. Submit high-quality pipeline.
  • Q4 (the last 6–8 weeks): focus only on closing what is already in the pipeline.
  • Fiscal-year boundary: ensure MDF applications and funding requests are submitted well before the deadline.

Common Pitfalls

  • No agreed stage-one definition. Without a jointly-owned definition of what constitutes a stage-one alliance opportunity, the zombie pipeline problem is almost unavoidable. Definitions must exist before disputes arise, not after – and re-communicated to every new ISV AE who joins, since each hire arrives with their own assumptions about what ‘alliance-sourced’ means.
  • Inbound attribution conflicts erasing alliance-sourced pipeline credit. One of the most consistently underestimated operational problems in cloud alliances. The alliance team does the upstream work of introducing the ISV to the hyperscaler field, the hyperscaler introduces the ISV to a prospect, the prospect visits the ISV’s website independently and submits a contact form – and immediately the inbound lead is claimed by marketing or the SDR team. The operational fix is internal deal registration at point of first hyperscaler engagement. With a channel partner, the ISV typically operates a partner portal through which the channel partner registers deals, creating a logged record on the ISV’s side. With a hyperscaler, the upstream engagement happens entirely within the hyperscaler’s own systems – the field conversation, the AE’s account notes, the opportunity record – none of which the ISV can access or verify after the fact. Dual attribution models – where multiple teams share credit for a deal each contributed to – are an appealing partial fix but break down at scale.
  • Alliance introductions that convert to unattributed direct-sales pipeline. When an alliance manager introduces an ISV seller to a hyperscaler seller, the two sometimes develop a productive working relationship independently – quota-carrying salespeople find natural affinity, share account intelligence and generate joint pipeline without the alliance manager in the loop. This is a healthy pattern and should not be discouraged. The attribution problem emerges when the ISV seller logs the resulting opportunity in the CRM with the default source of “direct sales”: there is no bad faith, no comp incentive to correct it and no clean way to challenge it after the fact without creating friction with sales. The primary fix is upstream: the alliance manager logs the introduction at the time it happens – a CRM activity record noting the hyperscaler counterpart, the ISV seller involved and the date. When attribution questions arise later, the log provides the evidence without requiring anyone to contest a source field once a deal is already in motion. A supplementary technique: revenue intelligence platforms (Gong and equivalents) can surface conversations between ISV sellers and hyperscaler counterparts passively, giving the alliance manager visibility into developing relationships without having to ask. The limitation is scale – reviewing recorded conversations to track relationship development is viable at low alliance volumes and impractical once the motion grows.
  • Submitting opportunities with template or placeholder details. Identical deal amounts, generic opportunity names and absent customer context across a batch of submissions are immediately visible to PDMs and hyperscaler reviewers. Deal size is often genuinely unknown early in a pursuit – but that justifies a thoughtful placeholder and a documented update cadence, not copying the same figure across every submission.
  • No quarterly account-mapping refresh. Account mapping ages out. A list that was current six months ago is now actively misleading. Quarterly refresh is the operational minimum; monthly is better for primary clouds.
  • Tooling without process. Cloud GTM Platforms automate what is already working. They don’t compensate for missing stage-one definitions, attribution policies or pipeline governance. Buy the tooling after the process is in place.
  • Over-integration that hits hyperscaler-side compliance limits. Trying to sync more than the hyperscaler exposes – internal routing decisions, customer financial data, pre-decision discussions – produces integration failures that are hard to diagnose because the hyperscaler doesn’t surface why the access is blocked. Stay within the documented integration surface.
  • Silent marketplace bypass. Deals taken direct instead of through marketplace, each justified in isolation, accumulate in hyperscaler reporting as low marketplace transaction volume relative to ARR and co-sell pipeline. See Cloud Alliances for the full treatment.

Hyperscaler Deal Verification and Audit Holds

ISVs with consistently large deal sizes or high partner program rebate values should be aware that hyperscalers periodically verify that co-sell claims accurately reflect closed business. The precise trigger mechanisms are not publicly documented and appear to vary by hyperscaler and by program, but the pattern that recurs in practitioner experience is size-based: deals or program rebate calculations above certain thresholds are more likely to be subject to verification before payments are released.

The payment-release dynamic is the practically significant part. Where a verification review is triggered, disbursement of partner program rebates – and in some cases incentive payments to the hyperscaler’s own field teams or PDMs – may be held until the review completes. For ISVs with a small number of large deals rather than a high volume of smaller ones, a single deal under review can represent a significant proportion of expected rebate income in a given quarter.

The practical implications for co-sell operations:

First, the quality of co-sell submission documentation matters more at high deal values than volume-focused metrics might suggest. ACE and PSC submissions that clearly evidence customer identity, deal structure, close date and the hyperscaler’s specific contribution to the pursuit are less likely to generate verification friction than submissions that rely on implicit or informal evidence.

Second, finance should be made aware that partner rebate timing is not fully predictable. A rebate expected in Q2 may not disburse until Q3 if a verification review is in progress. Building a buffer assumption into rebate-dependent financial planning is prudent for ISVs whose deal profile creates higher-than-average exposure to review.

Third, the alliance team should maintain a clean audit trail for every large co-sold deal: customer confirmation of close, correspondence with the hyperscaler field team involved, ACE/PSC submission records and any joint-pursuit documentation. This is the evidence set that resolves a verification review quickly. ISVs that lack it find reviews taking significantly longer.

The frequency with which an individual ISV encounters these reviews is partly a function of deal profile. An ISV with an unusually high average deal size relative to its closed-won volume will encounter them more often than the absolute deal count would suggest – the combination of large individual rebate calculations and a small number of reference transactions creates exactly the profile that size-based triggers are designed to catch.

What This Looks Like in Practice

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

A data-platform ISV with $95M ARR built its co-sell operations infrastructure across three distinct phases over three years:

Phase 1 (~$30M ARR): spreadsheets and CRM. A single alliance manager maintained ACE submissions, PSC submissions and partner-portal opportunities in a manually-curated Salesforce custom object plus a parallel spreadsheet. Worked up to roughly 25 active opportunities; broke between 25 and 50.

Phase 2 (~$45M ARR): adopted a Cloud GTM Platform. Implementation took roughly four months from contract to first-working AWS sync; Microsoft sync followed three months later; Google sync six months after that (the lighter Google portal infrastructure made the integration harder, not easier, because there was less standard mapping). First-year cost was meaningful but produced a step-change in operational scalability – the same alliance team handled 5x the opportunity volume by phase-2 month 12.

Phase 3 (~$75M ARR): hybrid platform plus selective native integrations. The CRM↔Partner Central sync was rebuilt as a native integration, driven by a preference for owning the primary integration surface as AWS became the dominant volume driver. Tooling cost and integration ownership were both factors in the decision; the outcome was greater control over the highest-volume flow. Microsoft and Google stayed on the platform. Marketplace operations stayed on the platform throughout – the disbursement-reconciliation tooling was the highest-value piece and the hardest to replace.

The diagnostic insight: the right architecture changed twice over three years, and the team that owned operations was the same throughout. Continuity of operational ownership mattered more than the specific tooling choices, because the tooling decisions were always made against the institutional knowledge of what was actually working and what was actually breaking.

Where to Go Next

Within this pillar:

  • AWS Co-Sell – the AWS-specific mechanics that this operations layer supports.
  • Microsoft Co-Sell – the Microsoft-specific mechanics, including Partner Center Referrals (PSC), co-sell statuses and the MACC drawdown dynamics that drive the Microsoft private-offer motion.
  • Google Co-Sell – the Google-Cloud-specific mechanics.
  • Hyperscaler Co-Sell – the broader co-sell model this operations function exists to operationalise.

Adjacent:

The full series glossary is at Glossary.

External References

Vendor Primary Sources

Practitioner Models and Industry Commentary

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

  • CONNACT – Checklist: Are You Positioned for Co-Sell Success? and 4 Key Co-Sell Challenges and How to Overcome Them. Practitioner content on co-sell operations and readiness. Note: the author has a professional relationship with CONNACT; see the series disclosure on the hub page.
  • Tackle – State of Cloud GTM annual report, including operational benchmarking on co-sell motion maturity. Tackle (acquired by AppDirect, December 2025) is a Cloud GTM tooling vendor; the report is informative but published from a commercially interested vantage.

Last reviewed: 2026-07-01. Vendor-neutral clusters in this series are reviewed annually. Major changes in hyperscaler API surfaces or significant Cloud GTM Platform category evolution 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/.