integration-partnership-strategy

{
  "skill_name": "integration-partnership-strategy",
  "evals": [
    {
      "id": 1,
      "prompt": "I run BD at Threadline, a $14M ARR B2B workforce-scheduling SaaS. My exec team wants a shortlist of 5 integration partners for next year and I have a draft: Slack (our CTO knows their partner lead personally), Workday (biggest logo we could realistically land), Gusto (met their BD guy at a conference in May, we got on great), Notion (everyone integrates with Notion), and Rippling (a competitor announced one in March). For context: our CRM has a partner-source field that nobody fills in, sales win/loss notes mentioned missing payroll integrations about a dozen times last quarter, and support logged 40-something tickets asking for Gusto sync. Give me the partner strategy.",
      "expected_output": "A partner-selection approach that gates the shortlist on written demand evidence, drops the relationship- and logo-driven candidates, proposes competing portfolio shapes before committing, and places survivors on the depth ladder at the default rung.",
      "files": [],
      "expectations": [
        "Asks clarifying questions before delivering a finished strategy, or explicitly gates the strategy on interview answers covering deadline, one-off-win vs compounding-asset, and effort ceiling",
        "Requires every shortlisted partner to carry a written demand-evidence line (named deals, request counts, or retention data)",
        "Rejects or parks the Notion and Workday candidates for having no demand evidence, rather than keeping them on the strength of ubiquity or logo size",
        "Treats the conference relationship as non-evidence for Gusto, while keeping Gusto on the strength of the 40-odd support tickets and the payroll win/loss mentions",
        "Names the three primary selection filters: customer and prospect demand, market/SAM expansion, and competitive necessity",
        "Adds quantified signals including deal-attached revenue (dollar value of open deals blocked on each missing integration), ecosystem gravity, and retention/attach lift",
        "Flags that the unfilled partner-source CRM field makes attribution plumbing a prerequisite rather than an afterthought",
        "Proposes 2-3 candidate portfolio shapes with trade-offs (such as few-and-deep, category-coverage breadth, platform-anchor) and recommends one, instead of delivering a single finished list",
        "Places selected partners on the five-rung depth ladder running referral, reseller, co-sell/integration alliance, co-build/strategic alliance, OEM/embed",
        "Names co-sell/integration alliance as the default depth rung rather than opening every partner at a deep alliance",
        "Recommends proving 1-3 partner types first before adding depth or more partners",
        "Sets a recurring cadence of quarterly prioritization review with monthly intake from sales and CS"
      ]
    },
    {
      "id": 2,
      "prompt": "Our CFO at Bellwright (HR-tech, roughly $40M ARR) killed the partnerships headcount request last quarter. His reason: our dashboard claimed partners touched $31M of revenue, which is more than three quarters of the entire company. That number comes from a Google Sheet our partner manager Dana updates in the last week of each quarter - she tags any closed-won deal where a partner logo appears anywhere in the opportunity notes. We are going back in Q3 to ask for three more heads. Rebuild the number so it survives finance.",
      "expected_output": "An attribution rebuild that replaces the blended spreadsheet figure with two separate capped CRM-level numbers, claimed at deal creation with dated IDs, plus the comp, forecast, and reporting changes that make the data credible.",
      "files": [],
      "expectations": [
        "Splits reporting into two separate numbers, partner-sourced and partner-influenced, and refuses to report a single blended partner-touched figure",
        "Defines sourced as a deal that would not exist without the partner, and influenced as a deal that already existed and the partner materially advanced",
        "Caps influenced credit and explains that uncapped influence is how partner-attributed revenue comes to exceed total revenue",
        "Moves attribution out of the spreadsheet onto a partner-source field on the CRM opportunity record",
        "Requires attribution claimed at deal creation with a dated claim ID, never reverse-engineered at close",
        "Identifies the conflict in having the number maintained by the person whose quota or headcount request depends on it",
        "Specifies a short attribution window of roughly 14 days from deal creation",
        "Limits credit to one sourced partner per deal",
        "Requires credit caps set before the quarter starts rather than after results are known",
        "Calls for equalizing AE compensation on partner deals, because AEs paid less on partner deals deprioritize them",
        "Rolls partner pipeline into the same forecast review and the same exit criteria as direct pipeline",
        "States that referral, co-sell, and OEM motions need different attribution rules rather than one generic scheme",
        "Reports an executive KPI set inside dashboards leadership already checks - sourced vs influenced revenue, activation rate, time to first deal, partner CAC vs direct CAC - rather than a standalone partner report"
      ]
    },
    {
      "id": 3,
      "prompt": "Quick one. We are Latchpoint, 60 people, field-service scheduling software. Two of our largest customers run NetSuite and two more run Salesforce. Sales says getting listed on AppExchange and earning the Built for NetSuite badge would unblock about $900K of stalled deals. I have exactly one integration engineer and a CFO who wants the full cost of both before he signs anything. What is the number, and should we do it?",
      "expected_output": "A certification cost model that treats both programs as recurring standing engineering work with named owners, carries the concrete fee, timeline, and failure-rate figures, and tests the single-engineer constraint before recommending a join.",
      "files": [],
      "expectations": [
        "Treats certification as a recurring standing cost rather than a one-time launch project",
        "States the AppExchange security review carries a $999 per-submission fee",
        "States the AppExchange review takes roughly 6-9 weeks initially plus 2-3 weeks per resubmission",
        "Warns that roughly half of first AppExchange submissions fail, and budgets at least one resubmission cycle",
        "States that Built for NetSuite must be renewed at every major NetSuite release, twice yearly",
        "Notes Built for NetSuite is revocable at any time the standards lapse",
        "Names a renewal owner for each certification joined",
        "Counts recurring certification maintenance against integration-engineer headcount and flags the single engineer as the binding constraint",
        "Mentions Salesforce's ongoing listing cost of roughly $150/yr and/or its 15% revenue share, 25% for OEM",
        "Tests each platform against whether it reaches a segment the demand evidence names, not only against the stalled deal value",
        "Advises verifying current program requirements and tier names against each platform's own current documentation before committing",
        "Requires the effort ceiling in engineering hours per quarter to be checked before joining rather than discovered afterwards"
      ]
    },
    {
      "id": 4,
      "prompt": "Cassava Systems here, warehouse inventory software, about $22M ARR, all direct sales, no channel, and every contract is signed by us - finance flatly refuses to let another company be the transacting party on our revenue. Three partnership conversations are live right now. Kitewell, a robotics vendor: their reps sent us 6 opportunities over the last two quarters, 2 closed, and their largest customers keep asking for a real productized integration instead of the CSV hack we have. Norsefield, a large ERP: they want to white-label our forecasting module inside their product under their own brand, and they have floated minimum annual commitments. Orbit Freight, a TMS: interesting people, but zero customer overlap so far and nobody has ever asked us for it. Separately, our VP Sales wants to list on AWS Marketplace and keeps calling that the deepest tier of partnership. How deep do we go with each?",
      "expected_output": "A per-partner placement on the five-rung ladder with graduation gates, the reseller rung deleted rather than parked, white-label distinguished from OEM, and the cloud-marketplace framing corrected.",
      "files": [],
      "expectations": [
        "Places each partner on the five-rung ladder: referral, reseller, co-sell/integration alliance, co-build/strategic alliance, OEM/embed",
        "Promotes Kitewell toward co-build/strategic alliance, citing already-sourced pipeline plus joint-customer pull for a productized integration",
        "Places Orbit Freight at referral or parks it, because no demand evidence exists yet",
        "Deletes the reseller rung outright rather than demoting or parking it, because the business cannot support partner-transacted deals",
        "Explains that a parked or merely demoted rung silently reappears as scope later",
        "Distinguishes white-label from true OEM: white-label hides the vendor brand but typically carries no roadmap commitment, so it is its own category rather than a synonym",
        "States that OEM/embed revenue share runs roughly 10-30% of the partner's revenue from the powered feature",
        "Flags OEM/embed as the hardest rung to unwind once the partner's customers depend on it, with minimum commitments as a precondition for promotion",
        "Corrects the AWS Marketplace framing: cloud-marketplace co-sell is a channel and transaction decision, not a depth rung on this ladder",
        "Gates every graduation on proven joint economics plus the three-fit test, requiring product fit, commercial fit, and operational fit to line up simultaneously",
        "Notes the co-build commitment shape: a 12-18 month joint roadmap with shared pipeline targets",
        "Names the compliance cost each rung triggers, such as OEM licensing with IP and indemnity terms, a joint development agreement for co-build, NDA and revenue-share terms for co-sell, and referral being terminable at will",
        "States the ranking is a default to be re-ranked against the deadline, one-off-vs-compounding, and effort-ceiling answers"
      ]
    },
    {
      "id": 5,
      "prompt": "Meridian Loop, 38 employees, SaaS for clinical trial site management. We just hired our first dedicated partnerships person, Priya. Our COO wants to stand her up as VP of a proper Alliances org with a partner ops hire and a partner marketer underneath her, so that partnerships finally gets the respect it needs internally. Today partnerships informally sits with our head of sales. We have 4 integrations live and none of them produces measurable pipeline yet. Where should this function live, and what do we staff?",
      "expected_output": "A recommendation to keep the function under Sales at this stage, with the standalone Alliances org named as the deliberately starved option, the ~100-employee split threshold, the Product migration condition, and attribution plumbing built now.",
      "files": [],
      "expectations": [
        "Recommends keeping the function reporting into Sales at this stage rather than standing up a standalone Alliances org",
        "Names the standalone Alliances org as the highest-value and highest-cost option that an efficiency ranking never picks, and states the condition that promotes it anyway, such as partner-sourced revenue becoming a board-level metric or deep-rung governance needing dedicated owners",
        "Notes that reporting into Sales costs zero reorganization and keeps an unproven function tied to revenue",
        "Ties the recommendation to the fact that none of the 4 live integrations produces measurable pipeline yet, so the function is still unproven",
        "Names roughly the 100-employee mark as the threshold for splitting into dedicated roles, well above the current 38",
        "Describes the split-role shape at that threshold: partner/alliance manager plus a partner or integration engineer plus an integration product manager",
        "Recommends treating the top 10-15 partners as named strategic accounts once the split happens",
        "Names the condition for migrating integrations under Product: when productizing integrations becomes the goal, so they get built for scale instead of as bespoke BD favors",
        "Prescribes building the attribution plumbing during this Sales-reporting phase, before the program scales",
        "Ranks the three placements explicitly on effort, value, and efficiency instead of presenting them as a flat list of options"
      ]
    },
    {
      "id": 6,
      "prompt": "We signed a strategic alliance with Halvard Analytics six months ago and our two products are supposed to ship a deep joint integration. Since kickoff we have had exactly two calls, both of which were them presenting slides about their quarterly numbers and us presenting ours. Their engineering team went quiet around month three and we only found out from a mutual customer last week that they had re-platformed their API. Our legal team is now asking whether we should have set this up as a joint venture. Fix the governance.",
      "expected_output": "A governance rebuild that reclassifies the calls as status updates, specifies real QBR mechanics with resource-approving attendees, installs shared roadmap visibility and a joint business plan, and recommends a scoped JDA over a joint venture.",
      "files": [],
      "expectations": [
        "Diagnoses the two calls as status updates rather than QBRs, because they produced no dated commitments",
        "Specifies a QBR as a working session reviewing last quarter against the previous QBR's commitments and setting the next quarter's",
        "Requires someone on each side who can approve resources to be present at the QBR",
        "Requires roadmap visibility shared from the start rather than at launch, so a partner re-platform surfaces before a customer reports it",
        "Sets a sync cadence of at least quarterly covering integration performance, upcoming platform changes, and customer feedback",
        "Recommends a joint development agreement scoped to the specific integration, with IP, support, and roadmap terms explicit, rather than a joint venture",
        "Explains that a joint venture creates a new jointly-owned legal entity and should be reserved for a genuinely shared new entity or product",
        "Requires a joint business plan with shared targets on a timeline and an explicit statement of which side carries the heavier lift at each phase, so a stall obligates the other side to unblock",
        "Reframes the integration as a product with its own roadmap, quality bar, security review, and definition of done, instead of a project",
        "Warns that project framing makes post-launch decay the default outcome"
      ]
    },
    {
      "id": 7,
      "prompt": "Building the board deck for our partnerships review at Ferncastle (DevOps tooling, $18M ARR). Two things I want checked before it goes out. First, my Salesforce slide says we should target Crest tier and eventually Summit on their ISV partner program, and my Atlassian slide has Silver/Gold/Platinum with a note that Gold needs $500K in cloud sales. Second, the headline stat on slide 2 is that 83% of enterprise buyers cite integrations as a purchase-decision factor, and slide 9 says ecosystem-qualified deals are 53% more likely to close and close 46% faster. Sanity check this for me.",
      "expected_output": "A correction pass that replaces the deprecated Salesforce tiers with the current journey stages, fixes the Atlassian threshold and its security requirement, and relabels both cited statistics with their real sourcing strength.",
      "files": [],
      "expectations": [
        "Flags Base/Ridge/Crest/Summit as Salesforce's retired legacy Trailblazer-Score ISV tiers, replaced in July 2024",
        "Gives the current Salesforce ISV journey stages: Registered, Exploration, Build, Select, Summit",
        "Corrects the Atlassian Gold threshold to $750K in cloud sales, and gives Silver at $150K and Platinum at $3M",
        "Notes that Atlassian Gold and above additionally require SOC 2 Type 2 or ISO 27001",
        "Labels the 83% enterprise-buyers figure as circulated without a traceable primary study, and advises against presenting it to a CFO or board as a cited benchmark",
        "Labels the 53% and 46% ecosystem-qualified-deal figures as vendor-published and drawn from top-performing cohorts, so they read as directional ceilings rather than median outcomes",
        "Advises measuring Ferncastle's own program with its own attribution data instead of leading the deck with industry-wide lift figures",
        "Recommends verifying every tier name against the platform's own current documentation before the deck ships, since third-party guides still describe deprecated tiers",
        "Notes that the 2024-2026 period was a restructuring wave that renamed tiers across nearly every major platform"
      ]
    }
  ],
  "trigger_queries": [
    { "query": "Which technology partners should we integrate with first?", "should_trigger": true },
    { "query": "We have 40 integrations listed and no partnership strategy - help me pick which 5 vendors to actually go deep with", "should_trigger": true },
    { "query": "Design a technology-partnership program for our CRM add-on: who to partner with first, how deep, and who owns it internally", "should_trigger": true },
    { "query": "How deep should we go with each of our ISV partners?", "should_trigger": true },
    { "query": "Our CFO stopped trusting the partner-influenced revenue number. Rebuild it so it survives finance review", "should_trigger": true },
    { "query": "What is the difference between partner-sourced and partner-influenced revenue, and how do I report both?", "should_trigger": true },
    { "query": "Salesforce is pushing us to certify on their platform. Should we join, and what does it really cost per year?", "should_trigger": true },
    { "query": "Is the Built for NetSuite badge worth it for a 60-person company?", "should_trigger": true },
    { "query": "Set up tiers for our technology partner program", "should_trigger": true },
    { "query": "Who should own partnerships internally, sales or product?", "should_trigger": true },
    { "query": "We signed 200 partners and only 12 have ever sent us a deal. What now?", "should_trigger": true },
    { "query": "Our BD lead keeps adding partners because he knows people there. How do I put evidence behind the shortlist?", "should_trigger": true },
    { "query": "Should this alliance run on a JDA or should we set up a joint venture?", "should_trigger": true },
    { "query": "Our quarterly partner calls are just slide readouts. How do I turn them into real QBRs?", "should_trigger": true },
    { "query": "A big ERP wants to embed our forecasting module under their own brand with minimum annual commitments. Good idea?", "should_trigger": true },
    { "query": "What revenue share is normal for an OEM deal?", "should_trigger": true },
    { "query": "We need a joint roadmap with our biggest alliance partner. How do we govern it?", "should_trigger": true },
    { "query": "help me figure out which other software vendors we should build integrations with next year", "should_trigger": true },
    { "query": "how do I prove to finance that our partner program actually makes money", "should_trigger": true },
    { "query": "our AEs quietly ignore any deal that comes in through a partner", "should_trigger": true },
    { "query": "How many integration partners should a Series B SaaS actually invest in?", "should_trigger": true },
    { "query": "We are re-evaluating a mature partner program from scratch. Where do we start?", "should_trigger": true },
    { "query": "What should we track to know whether the partner program is working?", "should_trigger": true },
    { "query": "Is it normal for partner CAC to come out higher than direct CAC?", "should_trigger": true },
    { "query": "When is a partnership ready to graduate from co-sell to co-build?", "should_trigger": true },
    { "query": "Three partners drive almost all of our partner revenue. Is that concentration a red flag?", "should_trigger": true },
    { "query": "Build me a scorecard for prioritizing which integrations to build next", "should_trigger": true },
    { "query": "We keep certifying on platforms and then getting blindsided when they force us to re-certify", "should_trigger": true },
    { "query": "How do I stop our program from turning into 50 shallow integrations that produce nothing?", "should_trigger": true },
    { "query": "what are the current Salesforce and Atlassian partner tiers, and what do they require", "should_trigger": true },
    { "query": "Need an attribution model for deals that come through our ISV partners", "should_trigger": true },
    { "query": "Our head of sales wants to spin up a VP of Alliances. Are we big enough for that?", "should_trigger": true },
    { "query": "We want to become the default integration in our category. What does that actually take?", "should_trigger": true },
    { "query": "Two of our biggest customers keep pushing us toward the same vendor. Should we formalize something with them?", "should_trigger": true },
    { "query": "Draft the plan for who we partner with over the next 12 months and how much we invest in each", "should_trigger": true },
    { "query": "What belongs in a joint business plan with a technology partner?", "should_trigger": true },
    { "query": "I need to decide between going wide with lots of integrations or deep with a few", "should_trigger": true },
    { "query": "Optimize our AppExchange listing so we convert more views into installs", "should_trigger": false },
    { "query": "Our marketplace search rank keeps dropping. How do we defend it?", "should_trigger": false },
    { "query": "Should we build our own app marketplace or just join other people's?", "should_trigger": false },
    { "query": "What take-rate should our app marketplace charge third-party developers?", "should_trigger": false },
    { "query": "Design the payout cadence and hold window for developers selling on our marketplace", "should_trigger": false },
    { "query": "Who should be merchant of record for paid apps on our marketplace?", "should_trigger": false },
    { "query": "Write the listing quality rulebook every third-party app on our marketplace must meet", "should_trigger": false },
    { "query": "Pick the founding launch cohort for our new app marketplace and plan the keynote reveal", "should_trigger": false },
    { "query": "Design the review and approval pipeline for third-party apps submitted to our platform", "should_trigger": false },
    { "query": "How should we provision sandbox tenants for partner developers?", "should_trigger": false },
    { "query": "Design the onboarding journey from partner signup through to first submitted app", "should_trigger": false },
    { "query": "Should we get listed as a source connector on Fivetran and Airbyte?", "should_trigger": false },
    { "query": "We need CDC support on our connector so customers can pipe us into Snowflake", "should_trigger": false },
    { "query": "Which integration surfaces should we build first - webhooks, GraphQL, or an MCP server?", "should_trigger": false },
    { "query": "Should we add a GraphQL layer on top of our public REST API?", "should_trigger": false },
    { "query": "Design the webhook retry, backoff, and dead-letter policy for our platform", "should_trigger": false },
    { "query": "Which languages should get official client SDKs first?", "should_trigger": false },
    { "query": "Set our API rate limits and burst quotas per pricing tier", "should_trigger": false },
    { "query": "Write our API deprecation and sunset policy with notice windows", "should_trigger": false },
    { "query": "Build a machine-readable error-code taxonomy for our public API", "should_trigger": false },
    { "query": "Design a dashboard so partners can see why their integration calls are failing", "should_trigger": false },
    { "query": "We want to build a reseller channel of regional IT consultancies who resell our product with their own services wrapped around it. How do we recruit and enable them?", "should_trigger": false },
    { "query": "How should we structure our sandbox and test API keys?", "should_trigger": false },
    { "query": "Design the OAuth consent screen and scope taxonomy for third-party apps", "should_trigger": false },
    { "query": "How do we rotate customer API keys without downtime?", "should_trigger": false },
    { "query": "Audit our API reference docs for undocumented endpoints and missing error codes", "should_trigger": false },
    { "query": "Design the information architecture for our developer portal", "should_trigger": false },
    { "query": "Write the job description and interview loop for a partner/integration engineer", "should_trigger": false },
    { "query": "I want to move into API product management. How do I prep for the interviews?", "should_trigger": false },
    { "query": "Review our REST endpoint naming and pagination style for consistency", "should_trigger": false },
    { "query": "Should we expose a JDBC endpoint so customers can query their data from Tableau?", "should_trigger": false },
    { "query": "Design our Parquet export to S3 with an incremental delivery cadence and freshness SLA", "should_trigger": false },
    { "query": "Should we ship an MCP server so AI agents can operate our product?", "should_trigger": false },
    { "query": "Write the code to integrate our checkout with the Stripe API", "should_trigger": false },
    { "query": "Set up multi-touch attribution across our paid ad channels", "should_trigger": false },
    { "query": "Configure the connected app and named credentials for our Salesforce integration", "should_trigger": false },
    { "query": "Set up an affiliate program with commission payouts for bloggers promoting our product", "should_trigger": false }
  ]
}

# Attribution mechanics, governance detail, and named case studies

## Sourced vs. influenced: precise definitions

Consistent across practitioner sources (Suger, Forecastable):

- **Partner-sourced** - the deal would not exist without the partner, who originated it via deal registration or referral. 100% creation credit goes to the registering partner. Defensible default: one sourced partner per deal.
- **Partner-influenced** - the deal already existed and the partner materially advanced it: co-sell, technical validation, POC, procurement access, or an integration requirement. Credit split by role, always capped.
- **Direct** - neither sourced nor influenced. "If no partner sourced or influenced it, it is direct revenue that happened to transact on a marketplace" (Suger).

Why finance discounts blended numbers, in the practitioners' own words:

- "uncapped influence is how partner-attributed revenue exceeds total revenue - a result that ends the conversation with finance immediately and permanently" (Suger)
- "most partnerships teams report a combined number to the CFO, which is exactly why CFOs discount it" (Forecastable)

Three structural causes compound:

- High- and low-confidence deals mixed into one aggregate.
- Attribution reverse-engineered at close instead of claimed at deal creation.
- The data maintained by the partner manager whose quota depends on it.

The structural fix:

- Attribution lives on the CRM opportunity, never a spreadsheet.
- Each claim carries a dated ID predating the outcome.
- Sourced and influenced are always two separate, capped numbers.
- Credit caps are set before the quarter starts.
- The attribution window is short: about 14 days from deal creation.

## The executive KPI set

Report inside the dashboards leadership already checks daily. A separate partner report nobody opens makes the impact evaporate regardless of data quality.

- Partner-sourced vs. partner-influenced revenue (two numbers, never one).
- **Activation rate** - share of signed partners that ever generate a lead or revenue. The fastest exposure of vanity recruiting: "a program with 200 signed partners and 12 active ones does not have 200 partners" (Partnerships.ai).
- Time to first deal per partner.
- **Partner CAC vs. direct CAC** - the number to put in front of a CFO. A common working benchmark is partner CAC under ~1.5x direct CAC (Scayul, vendor-published, directional). Above that, fix activation and onboarding before recruiting more partners.
- Revenue per partner - a more useful health signal than raw partner count.

Concentration reality: in high-performing programs, roughly 80% of partner revenue comes from the top 10-20% of partners. That's expected, not a red flag by itself.

Forrester's "State of B2B Partner Ecosystems, 2025" reports 63.5% of companies say channel partners contribute meaningfully to annual revenue. Board-level partner-sourced-pipeline reporting and quarterly QBRs with core partners are the traits separating realized growth from the plan.

## Governance detail

**QBR, precisely** (PartnerStandard, Bernhard Friedrichs): "a recurring working session between a vendor and a channel partner that reviews the last quarter against the commitments made in the previous QBR and sets the next quarter's commitments. A meeting that produces no dated commitments is a status update, not a QBR."

Minimum attendance: the partner manager and their counterpart, plus someone on each side who can approve resources.

Four fixed blocks:

- Last quarter vs. commitments.
- Pipeline by name.
- Blockers.
- Next quarter's plan.

**JDA vs. JV**:

- A Joint Development Agreement governs a specific project between existing entities: each party remains independent, no new legal entity, typically scoped to a single project.
- A Joint Venture creates a new jointly-owned legal entity with shared management, profits, and liabilities.

A clean primary-source example of contractual escalation: Vast Renewables' SEC filing with EDF establishes a four-person joint steering committee governing the JDA. It layers in a joint venture agreement entered "for each jointly developed project which reaches a certain stage of development." It's an energy-sector deal, cited here for its structure: SaaS co-development follows the same JDA logic but rarely publishes the paper trail.

Practical rule: default to a JDA scoped to the specific integration with IP, support, and roadmap terms explicit. Reserve a JV for a genuinely shared new entity or product.

**Two-tier alliance governance** (Umbrex's playbook): a Joint Steering Committee (executive-sponsored: long-range strategy, budget, major pivots) above an Operating Committee (quarterly resource allocation, roadmap sequencing). Shared-scorecard tooling - joint plans, shared KPIs, QBR-ready dashboards visible to both vendors - is an established product category used by the largest alliance programs.

## The six core roles

From real job specs (Channeltivity, GitLab, CaptivateIQ, Honeycomb, Contentsquare, Diligent):

| Role                          | Focus                                                                                                          | Reports to                      |
| ----------------------------- | -------------------------------------------------------------------------------------------------------------- | ------------------------------- |
| Partner/Alliance Manager      | Owns the relationship, joint business plan, co-sell execution                                                  | Head of Partnerships / Director |
| Partner/Integration Engineer  | Bridges the partner's product and engineering teams; owns the build end-to-end, plus certification maintenance | Partnerships or Product/Eng     |
| Integration Product Manager   | Owns integration roadmap, backlog, prioritization                                                              | Product                         |
| Alliance Director             | Strategic co-sell/co-build alliances, joint GTM, sourced+influenced pipeline                                   | VP Alliances / BD               |
| Partner Operations Specialist | Administers the PRM, attribution plumbing                                                                      | Head of Partnerships            |
| Partner Marketer              | Co-marketing, joint content, launches                                                                          | Partnerships or Marketing       |

The Contentsquare migration, in the executive's own words (EVP Gilad Zubery): having integrations "under product ensures that the integrations are being built and managed according to best practices with a focus on scale and productization… My team's goal is to productize as many integrations as possible."

## Named case studies and benchmarks, with sourcing labels

- **Okta - depth over breadth, the strongest citable case.**
  - Ron Piovesan (Head of Technology Partnerships): Okta runs 5-6 deep partnerships on 12-18 month joint roadmaps despite 7,000+ total integrations: "spreading yourself too thin won't work."
  - Bill Hustad (SVP Partner & Alliances), on the partner-first repositioning: historically Okta "turned to partners primarily for reach. a lot of tactical engagements, where we'd meet the partner at the cash register."
  - Cited results: more than 60% of business through partners, partner deals 3X+ larger than average direct sales, and one quarter where 10 of 10 top deals were partner-influenced (~$20M ACV).
  - Label: Okta-reported figures, verified via secondary coverage. Cite as company-reported, not independently audited.
- **Jay McBain** (Chief Analyst, Channels, Partnerships & Ecosystems, Canalys) defines Technology Alliances as the integration-partnership category: products integrate to deliver additional customer value. His "7 partners in every deal" thesis: the average B2B customer works with ~7 partners across a buying process, so a vendor needs 3-4 trusted voices around every buyer. Market sizing, stated at the Canalys Channel Forum: 73.1% of the total IT market transacts through or with partners, beyond 90% with partner assist.
- **Ecosystem multipliers** (IDC studies, sponsored by the platforms they describe: first-party, cite as such):
  - HubSpot's ecosystem earns $6.16 per $1 of HubSpot revenue (2024 figure).
  - Salesforce's ecosystem was projected to make $6.19 per $1 of Salesforce revenue by 2026.
  - Use as evidence that platform ecosystems carry real partner economics, not as your own forecast.
- **Ecosystem-Led Growth stats** (Crossbeam, 2023 State of the Partner Ecosystem Report): ecosystem-qualified deals reported:
  - 53% more likely to close.
  - 46% faster.
  - 58% less likely to churn.
  - Label: vendor-published by the category-leading ecosystem-intelligence tool, with directional ceilings from top-performing cohorts rather than median outcomes. The same label applies to every lift stat above. Treat all of them as ceilings, and measure your own program with the attribution mechanics in this file instead of citing industry-wide figures.
- **Customer-first framing**:
  - Vinod Devan (Global Head of Partner Ecosystem, Cohere): "Solve for the customer, build an ecosystem that solves for the customer." Anchors partner selection in customer demand signal rather than partner-side BD convenience.
  - Kelly Sarabyn (Director of Technology Partnerships, HubSpot): high-impact partner growth requires moving past linear reseller channels into an interconnected partner ecosystem, the argument for treating integration partnerships as a portfolio decision, not one-off bilateral deals.
- **83% of enterprise buyers cite integrations as a purchase-decision factor** - the argument for why integration partner selection carries retention and win-rate stakes, not just ecosystem breadth. Label: circulated widely across partnership content without a traceable primary study. Treat the direction as sound and the figure as unverified, and never put it in front of a CFO as a cited benchmark.
- **Microsoft/OpenAI** - the outer bound, not a template: the deepest technology partnerships are built on a shared strategic thesis rather than the integration alone. Atypical for the audience this skill serves. Cite only as a scale contrast.

# Depth ladder, platform tier programs, and certification obligations

## The five-rung depth ladder

| Depth rung                   | Who owns the customer   | Commercial model                                                                                                        | Product/roadmap commitment                         |
| ---------------------------- | ----------------------- | ----------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------- |
| Referral                     | Vendor                  | Referral fee/commission                                                                                                 | None                                               |
| Reseller/VAR                 | Partner (transacts)     | Margin/discount; recurring commission around 30%/yr is a common market rate                                             | Low; services wrap                                 |
| Co-sell/integration alliance | Shared                  | Sourced/influenced revenue share, joint pipeline                                                                        | Medium; an integration built and maintained        |
| Co-build/strategic alliance  | Shared, deep            | Joint GTM investment, shared pipeline targets                                                                           | High; joint roadmap (12-18 months at the deep end) |
| OEM/embed                    | Partner owns end-to-end | Licensing fee or roughly 10-30% rev-share of the partner's revenue from the powered feature; minimum commitments common | Deep; product embedding plus roadmap commitment    |

OEM vs. white-label: true OEM couples licensing with product embedding and a roadmap commitment. White-label hides the vendor brand but typically lacks that roadmap commitment, so treat it as its own category, not a synonym.

Cloud-marketplace co-sell (AWS/Azure/GCP transaction layer) is a distinct motion this ladder doesn't capture. Handle it as a channel decision, not a depth rung.

## Graduation triggers

What promotes a partner to a deeper rung (synthesized industry practice, not one canonical source):

- **Proven repeatable joint economics** - the partner already sources or influences pipeline at a rate that justifies deeper investment.
- **The three-fit test** (Forecastable): product fit, commercial fit, and operational fit must line up on the same side simultaneously. If any one is missing, the deeper motion underperforms regardless of contract terms.
- **Customer pull** - joint customers demanding a deeper, productized integration.
- **Strategic necessity** - competitive or platform dynamics that make deeper embedding defensive.

## Tier structures across seven major platforms

The 2024-2026 period was a heavy restructuring wave across nearly every major platform. Verify current tier names against each platform's official docs before acting. Many third-party guides still describe deprecated tiers.

| Platform                         | Tier names (current)                                          | Basis for tiering                                         | Notable requirements/benefits                                                                                                               |
| -------------------------------- | ------------------------------------------------------------- | --------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------- |
| Salesforce (ISV)                 | Registered → Exploration → Build → Select → Summit            | Journey stage / commercial relationship, quarterly review | $999 one-time security-review fee per app, ~$150/yr listing, 15% rev share (25% for OEM); Select/Summit unlock co-marketing and GTM support |
| HubSpot (App/Technology partner) | partner → rising → leading → premier (+ invite-only Catalyst) | Customer value, influenced revenue, quality               | Free to join; list with an integration plus 3 active users; quarterly tier-up on influenced-revenue submissions                             |
| Shopify (Technology Track)       | Registered → Plus → Premier → Platinum (top tier invite-only) | Performance requirements                                  | Certified Technology Partner Program replaced the prior program in Dec 2025; Platinum gets roadmap influence                                |
| Atlassian (Marketplace)          | Silver → Gold → Platinum                                      | Cloud sales thresholds + security/trust + support SLA     | Silver $150K / Gold $750K / Platinum $3M cloud sales; Gold+ needs SOC 2 Type 2 or ISO 27001; annual July review                             |
| Microsoft (MAICPP)               | Solutions Partner designations → Advanced Specializations     | Points-based Partner Capability Score                     | Replaced Gold/Silver competencies; ISV Success program, Azure credits, co-sell                                                              |
| ServiceNow (Build)               | Registered → Select → Premier → Elite (+ Access tier)         | Certification depth, outcomes, pipeline                   | Jan 2026 overhaul for AI agents; simplified fees; Store visibility                                                                          |
| Zendesk (Technology Partner)     | Tiered by engagement/investment                               | Proactive engagement + marketplace investment             | Free to join; Solutions Architect consultation at higher tiers                                                                              |

**Deprecation warning, worked example**: in July 2024 Salesforce retired its legacy Trailblazer-Score ISV tiers (Base/Ridge/Crest/Summit) for the five-stage journey model above - yet many third-party guides still describe the old names. Citing them dates the strategy and misroutes the partner team. HubSpot's separate Solutions Partner program (sold and managed recurring revenue - a different program from the technology/app track above) uses Gold → Platinum → Diamond → Elite, gated on roughly 75-80% gross revenue retention at the top tiers, with thresholds rising in 2027.

## Certification programs you join: the recurring-renewal comparison

Certification is what a vendor joins on someone else's platform, as opposed to any tier program it runs for its own partners. Four named programs:

| Program                              | Platform           | Core requirement                                                                                                 | Renewal/revocation                                                                                                                          |
| ------------------------------------ | ------------------ | ---------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------- |
| Built for NetSuite (BFN)             | Oracle NetSuite    | BFN questionnaire, positive customer references, live product demo to the SDN team                               | Must be renewed every major NetSuite release (twice yearly); revocable anytime standards lapse                                              |
| AppExchange Security Review          | Salesforce         | Mandatory code and behavioral audit (CRUD/FLS enforcement, secure auth, external-endpoint scans, data-flow docs) | $999/submission, 6-9 weeks initial plus 2-3 weeks per resubmission; roughly half of first submissions fail; ongoing per-release obligations |
| Slack Marketplace / Works with Slack | Slack (Salesforce) | OAuth flows/scopes/tokens, UI framework compliance, enterprise readiness, developer certification                | Certification-maintenance modules required each release                                                                                     |
| Atlassian Cloud Fortified            | Atlassian          | SOC 2 Type 2 or ISO 27001, bug-bounty participation, <24h support response, third-party-validated trust center   | Annual review; Atlassian commits to 6 months' notice before new requirements                                                                |

**The pattern, stated once**: the recurring-renewal design is deliberate - platforms use it to keep their ecosystem safe and current as their own product changes - but it creates an ongoing engineering carrying-cost for the joining vendor. Budget it as standing work in integration-engineer headcount, never as a launch-phase project cost that finishes.

---
name: integration-partnership-strategy
description: Select which technology partners a B2B SaaS vendor integrates with and how deep each partnership goes - demand-data partner prioritization (deal-attached revenue, retention lift, competitive necessity), the referral-to-OEM depth ladder with graduation gates, joint-roadmap and co-build governance, certification-program joins with budgeted renewals, sourced-vs-influenced pipeline attribution, and where the technology-partnerships function reports. Use whenever the user mentions integration partners, ISV alliances, technology partnerships, partner tiers, certification programs, or partner-pipeline attribution - even if they never say "partnership strategy". Strategy layer only. Do NOT use for ETL-platform listings - use samber/developer-platform-skills@etl-connector-strategy instead.
license: MIT
metadata:
  author: Samuel Berthe
  version: "1.0.1"
---

# Integration Partnership Strategy

You are a technology-partnerships strategist for a B2B SaaS company. Decide, as one coherent portfolio rather than a series of one-off bilateral deals:

- Which other software vendors to integrate with.
- How deep each partnership goes.
- How the joint work is governed.
- Which platform certifications to join.
- How partner-driven revenue is attributed.
- Who runs the function.

Business-alliance work with no product integration in it - pure reseller networks, referral programs, services alliances - sits at a different altitude of partnership strategy and is also out of scope. This skill applies only where two products integrate.

**Memory (advised):** When memory lives in a file, consider using `developer-platform-context.md`; if a different memory system is in use, rely on that instead. The file is an advisory reference, not a mandatory requirement. Separate task info in different sections. Remove finished tasks. Add a date to a task; no date for general project context. Some interview responses may differ between 2 tasks.

## Interview

Ask one question per message, multiple-choice where possible, and wait for the answer before the next. Each answer changes a later step.

1. Where is the program today? (a) no formal partnerships, (b) a handful of integrations, no tiers, (c) dozens of listed integrations, no depth strategy, (d) a mature program being re-evaluated.
2. What demand data exists right now? (a) a partner-source field on CRM opportunities, (b) sales win/loss reasons mentioning missing integrations, (c) support/CS integration requests only, (d) none of these. Anything below (a) makes step 5 a prerequisite, not an afterthought.
3. Where do partnerships report today? (a) Sales, (b) a dedicated BD/Alliances org, (c) Product, (d) nobody owns it.
4. Is there a named executive sponsor with budget? (a) yes, (b) interest but no budget, (c) no.
5. By when must the first partnership result land? A hard deadline promotes fast rungs of the depth ladder. No deadline permits the slow compounding ones.
6. Is the goal a one-off win (one flagship deal unblocked) or a compounding asset (an ecosystem that lifts retention for years)?
7. What is the effort ceiling - engineering hours per quarter for integration and certification maintenance, dedicated headcount, and the political capital to change AE compensation if attribution demands it?

Questions 5-7 re-rank every menu below. Record the answers and say which answer moved which option.

## Brainstorm before committing

Never jump from the interview to a finished strategy. Propose 2-3 candidate partnership portfolios with trade-offs and a recommendation, for example:

- **Few-and-deep**: 3-5 partners chosen on demand evidence, each on a co-sell or deeper rung. Okta runs 5-6 deep partnerships on 12-18 month joint roadmaps despite having 7,000+ total integrations (company-reported, not independently audited) - the strongest sourced case for this shape.
- **Category-coverage breadth**: one integration per adjacent category the customer base uses, all at referral/co-sell depth, no deep alliances yet. Cheapest to start, weakest per-partner economics.
- **Platform-anchor**: one dominant platform partnership (certification, marketplace presence, co-sell) plus a thin long tail. Concentrates effort where ecosystem gravity is highest, and concentrates risk the same way.

Recommend one against the interview answers. Then draft the strategy and validate it with the user section by section - partner shortlist, depth placements, governance, certifications, attribution, org - with an explicit approval gate before finalizing. If your harness has persistent memory, store the chosen portfolio, each partner's rung, and the re-ranking answers so later tactical sessions start from decisions, not re-interviews.

## Workflow

1. Build the demand-data prioritization scorecard.
2. Place each selected partner on the depth ladder.
3. Set up joint-roadmap governance for the deep rungs.
4. Decide certification joins, with renewals budgeted.
5. Wire attribution before the program scales.
6. Place the function in the org.

Each step has a section below, in order.

## 1. Prioritize partners with data, not relationships

Partner selection is a data problem. Score every candidate on three filters, evidenced from your own records rather than BD enthusiasm:

- **Customer and prospect demand** - the strongest signal: share of the base already running the candidate's product, plus sales-pipeline data showing which missing integrations kill deals.
- **Market (SAM) expansion** - does the integration open a use case or segment the product cannot reach alone.
- **Competitive necessity** - is the integration table stakes for a segment, or does it neutralize a competitor's advantage.

Mature teams add three quantified signals:

- **Deal-attached revenue** - the dollar value of open deals blocked on each missing integration. A large stalled deal can justify an accelerated build.
- **Ecosystem gravity** - the heavy hitters recurring across the base.
- **Retention/attach lift** - customers with several integrations churn less and close faster. Measure it in your own cohort data.

Run a quarterly prioritization review with monthly intake from sales and CS.

Every partner that makes the shortlist carries a written demand-evidence line - named deals, request counts, or retention data. A candidate with none is rejected or parked, never grandfathered in because someone knows someone.

## 2. Place each partner on the depth ladder

The ladder runs referral → reseller → co-sell/integration alliance → co-build/strategic alliance → OEM/embed. Deeper rungs shift customer ownership toward the partner and add roadmap commitment - full rung-by-rung mechanics in [references/depth-ladder-and-tier-programs.md](references/depth-ladder-and-tier-programs.md).

- effort: `OEM/embed > co-build > co-sell > reseller > referral`
- value: `OEM/embed > co-build > co-sell > reseller > referral`
- compliance cost (descending): `OEM/embed > co-build > reseller > co-sell > referral`
  - OEM licensing puts your product behind the partner's paper with minimum commitments, IP, and indemnity terms, and is the hardest rung to unwind once their customers depend on it.
  - Co-build triggers a joint development agreement with legal sign-off on IP, support, and roadmap.
  - Reselling makes the partner the transacting party, pulling in order-of-record and tax review.
  - Co-sell needs mutual NDA and revenue-share terms.
  - Referral is terminable at will.
- efficiency: `co-sell > referral > reseller > co-build > OEM/embed`

- **Default rung: co-sell/integration alliance.** One built-and-maintained integration plus a joint pipeline motion is where partner-market fit gets proven - repeatable sourced deals, usage uplift, retention improvement - at medium effort. Start with one referral or co-sell motion for 1-3 partner types, prove it, then add depth.
- **Step down to referral** when no integration demand evidence exists yet: near-zero effort buys a signal about whether the partner's base wants you at all.
- **Delete the reseller rung**, rather than demoting it, when your business model cannot support partner-transacted deals. A parked rung silently reappears as scope.
- **Co-build is the starved option**: highest value short of OEM and high effort (a 12-18 month joint roadmap, shared pipeline targets), so it loses every efficiency round. It is promoted anyway when a partner already sources pipeline at a rate justifying the investment, joint customers pull for a productized integration, or platform dynamics make deep embedding defensive.
- **OEM/embed** is promoted only when the partner owns the customer end-to-end and minimum commitments are on the table. Market rev-share runs roughly 10-30% of the partner's revenue from the powered feature.

Gate every graduation on proven joint economics plus the three-fit test (Forecastable): product fit, commercial fit, and operational fit must line up simultaneously, or the deeper motion underperforms regardless of what the contract says. This ranking is a default, not a law - re-rank against questions 5-7 and anything else known about the user: a hard deadline promotes referral, a compounding mandate promotes co-build, and an existing deep relationship with proven joint economics jumps the ladder legitimately.

## 3. Govern the deep rungs like a product

For every partner at co-build depth or beyond:

- Share roadmap visibility from the start, not at launch. Sync at least quarterly on integration performance, upcoming platform changes, and customer feedback.
- Treat each co-build like a product, never a project: its own roadmap, quality bar, security review, and definition of done. Post-launch decay is the default outcome of project framing.
- Write a joint business plan both sides work from: shared targets on a timeline, and which side carries the heavier lift at each phase - so a stall obligates the other side to unblock rather than letting the roadmap slip.
- Run real QBRs: a working session reviewing last quarter against the previous QBR's commitments and setting the next quarter's, with someone in the room on each side who can approve resources. A meeting producing no dated commitments is a status update, not a QBR.
- Default the legal shape to contractual co-development (a joint development agreement scoped to the specific integration, with IP, support, and roadmap terms explicit). Reserve a joint venture for a genuinely shared new entity or product. For the largest alliances, add two-tier governance: an executive steering committee above an operating committee that allocates resources quarterly.

## 4. Join certifications with renewals budgeted

Certification and verification programs are what you join on someone else's platform - distinct from any tier program you might run for your own partners. Two decision inputs: does the platform reach a segment your step-1 evidence names, and can the effort ceiling from question 7 absorb the carrying cost.

The trap is budgeting certification as a one-time project. Across platforms, the renewal is recurring by design:

- Some programs re-certify every major platform release (twice yearly on some platforms); others annually.
- Security reviews carry per-release obligations, and roughly half of first submissions fail on the strictest programs.

Budget certification maintenance as standing engineering work with a named owner, and count it against integration-engineer headcount, before signing up.

Per-program requirements, fees, and renewal cadences - plus current tier names for the major platforms and a warning about widely cited deprecated ones - are in [references/depth-ladder-and-tier-programs.md](references/depth-ladder-and-tier-programs.md). The 2024-2026 restructuring wave renamed tiers on nearly every major platform. Verify against the platform's own current docs before citing any tier name.

## 5. Wire attribution before scaling

A blended "partner-touched" revenue number is discounted by finance for a structural reason: uncapped influence credit is how partner-attributed revenue exceeds total revenue, a result that ends the conversation with the CFO immediately. Report **sourced** (the deal would not exist without the partner) and **influenced** (the deal existed and the partner materially advanced it) as two separate, capped numbers - never one blend.

Four requirements make the data credible:

1. A partner-source field on the CRM opportunity record - attribution in a spreadsheet is structurally impossible to defend.
2. Compensation alignment - AEs paid less on partner deals deprioritize them every quarter. Equalize comp treatment, or co-sell will not happen.
3. Unified forecast review - partner pipeline rolls into the same forecast review as direct pipeline, same exit criteria.
4. Motion-specific design - referral, co-sell, and OEM need different attribution rules. One generic scheme fits none.

Defensible defaults:

- Attribution claimed at deal creation with a dated ID, never reverse-engineered at close.
- A short attribution window: about 14 days from deal creation.
- One sourced partner per deal.
- Credit caps set before the quarter starts.

Report a small executive set inside the dashboards leadership already checks, not a separate partner report nobody opens:

- Sourced vs. influenced revenue.
- Activation rate.
- Time to first deal.
- Partner CAC vs. direct CAC.

Full definitions and benchmark figures, with their sourcing labels, in [references/attribution-and-case-studies.md](references/attribution-and-case-studies.md).

## 6. Place the function in the org

Three placements, ranked:

- effort: `standalone Alliances org > integrations under Product > report into Sales`
- value: `standalone Alliances org > integrations under Product > report into Sales`
- efficiency: `report into Sales > integrations under Product > standalone Alliances org`

- **Default: report into Sales** (Crossbeam's explicit early-stage guidance) - it keeps an unproven function tied to revenue with zero reorganization cost. Build the step-5 attribution plumbing during this phase, before scale.
- **Promote to split roles around the ~100-employee mark** (Crossbeam's Rule of 99, when partnerships get materially more complex): partner/alliance managers plus a partner or integration engineer plus an integration product manager, with the top 10-15 partners treated as named strategic accounts.
- **Migrate integrations under Product when productization becomes the goal** - the Contentsquare pattern: integrations under Product get built for scale and best practices instead of as bespoke BD favors.
- **The standalone Alliances org is the starved option**: a VP-level org with partner ops and partner marketing delivers the most at scale and costs the most to stand up, so efficiency never picks it. It is promoted when partner-sourced revenue becomes a board-level metric and the deep-rung governance of step 3 needs dedicated owners.

Re-rank against question 3: a team already sitting under Product keeps integrations there rather than paying a migration. A company with no owner at all starts at the default rung regardless of size.

## Failure modes

- **Relationship-vibes selection** - a partner shortlisted because the BD lead knows someone. Fix: no shortlist entry without a demand-evidence line (step 1).
- **Too many shallow partnerships** - dozens of listed integrations, none deep, none producing pipeline. Spreading thin is the documented anti-pattern the Okta case argues against. Fix: 1-3 partner types, few-and-deep portfolio.
- **Blended attribution** - one sourced+influenced number, assigned at close, maintained by the person whose quota depends on it. Fix: step 5's two capped numbers and four requirements.
- **Certification-renewal surprise** - the badge budgeted as a launch project, then a platform release lands and re-certification competes with the roadmap. Fix: standing renewal owner and budget before joining (step 4).
- **Vanity partner count** - 200 signed partners, 12 active is not 200 partners. Track activation rate (share of signed partners ever producing a lead or revenue).
- **Comp misalignment** - AEs quietly deprioritizing partner deals because they pay less. The program stalls without anyone deciding it should.
- **Integration run as a project** - no roadmap, no quality bar, no definition of done. It decays the quarter after launch (step 3).
- **Citing deprecated tier names** - several major platforms renamed their programs in 2024-2026, and third-party guides still describe the old tiers. Verify against current platform docs.

## Measurement

No industry pass-standard exists for a strategy document, so these gates are self-set. Iterate the strategy until all three pass.

1. **Evidence coverage**: every partner in the plan carries a demand-evidence line - zero partners selected on relationship alone.
2. **Attribution is structural**: sourced and influenced defined as two capped CRM-level numbers with dated claim IDs and a stated window, before the plan asks for headcount.
3. **Renewals owned**: every certification the plan joins names a renewal owner and a budgeted standing cost.

Watch as trends afterwards, baselined against your own first two quarters:

- Activation rate.
- Partner CAC - a common working benchmark is staying under ~1.5x direct CAC (vendor-published, directional).
- Partner-sourced pipeline.
- Time to first deal.
- Retention/attach lift for integrated customers.

Expect revenue concentration in the top 10-20% of partners. That is normal, not a red flag by itself.

## Invocation examples

- "We have 40 integrations listed and no partnership strategy - help me pick which 5 vendors to actually go deep with."
- "Salesforce is pushing us to certify on their platform. Should we join, and what does it really cost us per year?"
- "Our CFO stopped trusting the partner-influenced revenue number. Rebuild our attribution so it survives finance review."
- "Design a technology-partnership program for our CRM add-on: who to partner with first, how deep, and who should own it internally."

## References

- [references/depth-ladder-and-tier-programs.md](references/depth-ladder-and-tier-programs.md) - the five-rung depth ladder with commercial models, graduation triggers, current tier structures across seven major platforms, and the certification-program comparison with renewal obligations.
- [references/attribution-and-case-studies.md](references/attribution-and-case-studies.md) - precise sourced/influenced definitions, the executive KPI set, named case studies (Okta, ecosystem multipliers, ELG stats) with sourcing labels, QBR mechanics, JDA-vs-JV detail, and the six core roles.

See also, same collection:

- `samber/developer-platform-skills@api-integration-surface-strategy` - the technical umbrella: which integration surfaces (API, webhooks, SDK, MCP…) the product offers. This skill decides who to build with, that one decides what integrations are built on.
- `samber/developer-platform-skills@connector-marketplace-strategy` - whether to run your own marketplace vs. joining others'. This skill covers the bilateral partnerships either way.
- `samber/developer-platform-skills@etl-connector-strategy` - your presence as a source connector on third-party ETL/ELT platforms, a specific partnership surface this skill only points at.
- `samber/developer-platform-skills@partner-app-onboarding` - the partner-developer onboarding path (docs, sandbox tenancy, certification steps) once the partners chosen here start building.