mbfinotti/partnerships-skillsチェック済み
SKILL DETAIL
partner-performance
mbfinotti/partnerships-skills/partner-performance
Measure and review the performance of individual partners in a B2B partner program - the per-partner scorecard (dimensions, weights, targets, red-flag thresholds, data sources), the review cadence and QBR structure, and the underperformance ladder from trigger through corrective action to de-tier or exit. Also covers the B2C affiliate and creator review contrast. Use whenever the user mentions a partner scorecard, partner reviews, a channel partner QBR, a partner health check, or an underperforming channel partner, even if they never say performance. One partner at a time. Do NOT use for designing the tier ladder itself - use mbfinotti/partnerships-skills@partner-tiering instead.
インストール · 511出典を見る
Installation
npx skills add https://github.com/mbfinotti/partnerships-skills --skill partner-performance
スキルファイル
SKILL.md
最終同期 · 2026/10/23
evals/evals.json›
{
"skill_name": "partner-performance",
"evals": [
{
"id": 1,
"prompt": "I run partner ops at Verrix Data, a B2B analytics vendor. We have 83 partners: 51 transacting resellers, 22 ISVs with product integrations who never resell a dollar, and 10 referral partners who just pass us intros. Leadership wants one partner scorecard live before the Q3 reviews. Give me the standard dimension weights everyone in the channel uses so I don't have to argue about them internally, then show me the scorecard.",
"expected_output": "A scorecard design that refuses to supply industry-standard weights, treats weights as Verrix Data's own decision, and produces separate tracks for the ISV and referral populations instead of one composite that blanks them.",
"files": [],
"expectations": [
"States that no published industry-standard or benchmark weight set exists for partner scorecards, rather than supplying weights presented as a channel norm",
"Presents every dimension weight as Verrix Data's own design decision, to be set with the user",
"Keeps revenue-class dimensions at or below roughly 50% of total weight so leading indicators can move the score",
"States that weights sum to 100% and expresses each weight as a number rather than high/medium/low",
"Proposes 4-6 dimensions rather than a longer list",
"Produces a separate scorecard track for the 22 ISV partners instead of scoring them on the reseller composite",
"Produces a separate scorecard track for the 10 referral partners instead of scoring them on the reseller composite",
"Names a non-revenue leading dimension for the ISV track such as integration attach rate on closed deals, joint-solution certifications, or integration adoption among shared customers",
"Names accepted referrals or referral-to-opportunity conversion as the lead dimension for the referral track",
"Attaches both a target and a red-flag floor to every KPI, never a target alone",
"Attaches a measurement window, a named data source, and a named owner to every KPI",
"Asks at least one clarifying question before finalizing the design, and does not batch several questions into one message"
]
},
{
"id": 2,
"prompt": "Meridian Fleet Systems here. Our CFO is sick of seeing two revenue lines on the partner scorecard and wants one 'partner revenue' number: sourced plus influenced, added together. Last year partners sourced $4.2M and influenced $9.8M, so the combined number would be $14M against $31M of total company revenue. Write the revenue dimension of the scorecard for our 40 resellers and 12 ISVs.",
"expected_output": "A revenue dimension that keeps sourced and influenced revenue as two separate capped KPIs, refuses the $14M blended figure, and explains why finance will reject a blended number.",
"files": [],
"expectations": [
"Refuses to combine partner-sourced and partner-influenced revenue into a single blended figure",
"Keeps partner-sourced revenue and partner-influenced revenue as two separate KPIs on the scorecard",
"Defines partner-sourced revenue as closed revenue from deals the partner originated, evidenced by an approved deal registration",
"States that influence credit must be capped so attributed partner revenue never exceeds actual revenue",
"Flags the proposed $14M combined figure as indefensible in front of finance",
"Treats the attribution model as an upstream input feeding the influenced-revenue KPI rather than as the scorecard itself",
"Notes that influenced revenue costs materially more effort (roughly a quarter of attribution work plus finance sign-off) than sourced revenue, which is near-zero wherever deal registration is enforced",
"Recommends influenced revenue specifically for the 12 ISVs, because without it they have nothing to score",
"Gives each revenue KPI both a target and a red-flag floor",
"States a measurement window on each revenue KPI and matches the revenue window to the sales cycle, such as a rolling 12 months for lumpy enterprise deals",
"Names a data source and a named owner for each revenue KPI"
]
},
{
"id": 3,
"prompt": "Draft our partner scorecard from the data we already collect at Halcyon Grid. Every quarter our 60 VAR partners fill in a form telling us four things: their forecasted pipeline for next quarter, how many of their sellers they have trained on our product, how many logos they have won with us, and how many marketing campaigns they ran. Four clean inputs, 25% each, done. Make it official.",
"expected_output": "A rejection of all four self-reported inputs, each replaced with an equivalent drawn from program-recorded systems, plus the gameability test applied explicitly.",
"files": [],
"expectations": [
"Rejects the partner-submitted forecasted pipeline as a scorecard input",
"Rejects the partner-reported trained-seller count as a scorecard input",
"Rejects the partner-reported logo count as a scorecard input",
"Rejects the partner-reported campaign count as a scorecard input",
"States the rule that scorecard inputs come only from systems the program itself records (CRM, PRM, LMS, MDF ledger) and can defend in a partner dispute",
"Applies the test 'could a partner improve this number without improving the underlying behaviour' to the proposed metrics",
"Replaces self-reported pipeline with deal-registration data the program records, such as deal-registration approval rate or registered pipeline value",
"Replaces the trained-seller count with certified headcount drawn from the LMS",
"States that certified headcount counts individuals holding a current certification, not course enrollments",
"Replaces the campaign count with MDF utilization tied to documented campaigns, or with portal engagement drawn from program systems",
"States that unclaimed MDF is a disengagement signal rather than savings",
"Notes that the proposed four-metric set carries no lagging revenue dimension and adds partner-sourced revenue from approved deal registrations"
]
},
{
"id": 4,
"prompt": "Northvale Systems. Three Gold-tier resellers have not registered a single deal in two quarters and their portals show zero logins since March. Legal already gave us a standard termination letter template last year. I want to send all three the termination notice this week and reallocate their accounts to partners who actually sell. Write me the notice and the internal justification.",
"expected_output": "A refusal to jump to termination, replaced by the staged ladder from trigger through diagnostic and a signed two-sided corrective plan, with legal review and the agreement's notice terms gating any exit.",
"files": [],
"expectations": [
"Declines to move straight to termination and stages the response instead",
"Names the staged sequence: trigger, then diagnostic intervention, then corrective action plan, then de-tier or exit",
"States that de-tier or exit is gated on a documented corrective action plan having failed at its final checkpoint",
"Reads zero deal registrations plus a quiet portal as a disengagement signal that triggers at-risk outreach or a diagnostic call, not termination",
"Requires the PAM to open the diagnostic conversation with scorecard data rather than accusation",
"Requires the cause to be diagnosed (lost champion, capacity, competing vendor, product gap) before any remedy is prescribed",
"Specifies a written corrective action plan signed by both sides",
"Requires the corrective plan to state what the vendor commits in return, such as enablement, leads, MDF, or executive attention, rather than partner obligations alone",
"Requires the corrective plan to state the consequence of missing the final checkpoint explicitly and in writing",
"Requires the corrective plan to cite the specific below-floor KPIs from the scorecard rather than opinion",
"Sets dated checkpoints across the plan with measurable recovery goals",
"Routes any de-tier or termination through legal review against the signed partner agreement and follows the agreement's notice terms rather than an ad-hoc letter",
"Names the escalation chain roles: PAM, partner or channel manager lead, channel chief, and channel chief plus legal jointly for exit",
"States that only a compliance breach, fraud, or brand damage bypasses the coaching stages"
]
},
{
"id": 5,
"prompt": "Our partner QBRs at Caldera Interactive are theatre. Fifty minutes of me reading slides at the partner, five minutes of 'any questions?', and then nobody does anything we agreed. I have 14 managed resellers. Rewrite the agenda for me. And while we are in there, our joint business plans with these partners are two years stale, so fold the replanning into the same meeting and save everyone a calendar slot.",
"expected_output": "A restructured QBR agenda that keeps joint-plan rebuilding out of the review, leads with the prior-action check as the highest-value fix, adds a pre-read, and inverts the backward/forward time split.",
"files": [],
"expectations": [
"Declines to fold joint business-plan rebuilding into the QBR",
"States that a QBR reviews performance against the joint plan rather than rebuilding it, and that a QBR drifting into replanning loses its accountability function",
"Recommends scheduling the joint plan rebuild as a separate exercise and points to mbfinotti/partnerships-skills@joint-gtm-planning for it",
"Opens the QBR agenda by reviewing last quarter's actions",
"Identifies the missing action-tracking loop as the highest-value, near-zero-effort fix, ahead of any other agenda restructuring",
"Specifies where owned, dated actions live between reviews",
"Requires a data pre-read sent to the partner beforehand so the session is a discussion rather than a data dump",
"Inverts the 50/5 split so the majority of the session is forward-looking and the least time goes to backward-looking numbers",
"Assigns every action an owner on both the vendor side and the partner side, plus a due date",
"Carries actions into the next QBR and checks their completion there",
"Closes the agenda with agreed next steps and the next QBR date",
"Pulls the scorecard numbers from the PRM or CRM so they are factual rather than asserted",
"Presents meeting duration and attendee list as Caldera Interactive's design decisions rather than industry norms"
]
},
{
"id": 6,
"prompt": "Sable Ridge Software. Two partner account managers, 140 partners between them. Our new VP wants a full quarterly QBR with every single partner, plus a monthly check-in for anything Silver and above, which is about 60 partners. Design the review calendar so I can take it back to him.",
"expected_output": "A ranked cadence ladder that tests the VP's ask against the 70-partners-per-PAM coverage ratio, defaults the long tail to async delivery, and deletes the unstaffable rung by name.",
"files": [],
"expectations": [
"States that two PAMs cannot staff quarterly QBRs across 140 partners and tests the proposed cadence against the coverage ratio of roughly 70 partners per manager",
"Presents the review vehicles as a ranked ladder of rungs rather than a single cadence applied to all partners",
"States the efficiency ordering explicitly, with async scorecard delivery highest per PAM hour and the quarterly QBR plus monthly executive check-in lowest",
"Sets async scorecard delivery as the default rung for the bulk of the 140 partners",
"Reserves the quarterly QBR, and the QBR-plus-monthly-check-in rung, for a far smaller subset than the 60 partners requested",
"Moves any red-flagged partner to an exception-triggered live review immediately, regardless of tier",
"Deletes the rung the coverage ratio cannot staff and names it as deleted with the reason, rather than listing it as later or phase-two work",
"States the condition that promotes a partner up a rung: the revenue or strategic bet it carries exceeds the PAM hours the next rung costs",
"Names what the efficiency order starves, the top rung carrying the highest value and the highest cost, and gives the condition that promotes it for a named partner anyway",
"Warns that a cadence promising reviews nobody has the hours to run fails at the first quarter, and fails in front of the partner",
"Presents durations and attendee lists as Sable Ridge Software's design decisions rather than industry standards"
]
},
{
"id": 7,
"prompt": "I have just inherited a partner program at Brackenhall Tech. It already has scorecards and quarterly reviews, so I am not starting from zero. Problems I catalogued in week one: last quarter's actions never get done; QBRs are one-way status updates; every partner gets the identical review whether they do $2M or $20K; partners argue with the numbers constantly; and nobody has ever been de-tiered even though four partners have flatlined for a full year. Two things worth knowing: partners already see their own live scorecards in the portal, and every one of our 62 partners is a reseller, there is no other partner type. Where do I start? I have about three weeks before my first reviews.",
"expected_output": "A fix list ordered by reviews repaired per hour rather than severity, with the two irrelevant rows struck by name, and ladder enforcement placed last but promoted on the four flatlined partners.",
"files": [],
"expectations": [
"Orders the fixes by reviews repaired per hour of change rather than by severity",
"Places the action-tracking loop first",
"Places the QBR pre-read and agenda fix second",
"States that the pre-read and the action-tracking loop tie on effort because each is a change to a meeting that already happens, and that the action loop wins on value because a review whose actions nobody tracks repeats itself",
"Places ladder enforcement last on the efficiency order and gives the reason: legal review gates it and a wrong demotion is expensive to reverse",
"Names the compliance cost carried by ladder enforcement - contract review of the demotion and termination terms, and a decision the partner can contest - and notes the other fixes carry none",
"Strikes the partner-visibility row from the plan because partners already see live scorecards, and states it as deleted rather than leaving it as pending work",
"Strikes the per-type tracks row from the plan because the program has a single partner type, and states it as deleted rather than leaving it as pending work",
"Identifies the four partners flatlined for a year as the condition that promotes ladder enforcement: partners who have already sat through repaired reviews and still miss their numbers",
"States that once that condition holds, further agenda fixes are motion",
"Diagnoses the disputed numbers as a data-source and visibility question - which system is the source of truth, and whether the partner sees the same data before the meeting",
"Diagnoses the identical review for every partner as a cadence-tiering fault rather than a scorecard fault",
"Fits the recommended first moves inside the three weeks available before the first reviews"
]
},
{
"id": 8,
"prompt": "Orlea Commerce runs two things under one partnerships team: 31 managed B2B resellers, and about 4,200 self-serve affiliates, mostly bloggers plus a handful of coupon sites. I want one unified partner performance system across all 4,231 of them - same scorecard, same quarterly review, same underperformance process - so my team stops maintaining two of everything. Our top 6 affiliates produce 40% of affiliate revenue. Design it.",
"expected_output": "Two separate systems rather than one: scorecards and QBRs for the 31 resellers, automated dashboards and cohort review for the affiliates, with the top 6 affiliates carved out for per-partner treatment.",
"files": [],
"expectations": [
"Declines to run one system across both populations and designs the B2B channel side and the affiliate side as two separate systems",
"Keeps per-partner scorecards and PAM-run QBRs for the 31 managed resellers",
"Replaces per-affiliate QBRs with automated dashboards and self-serve access for the roughly 4,200 affiliates",
"Reviews the affiliate population at cohort or segment level rather than per affiliate",
"Carves out the top 6 affiliates for per-partner treatment, on the grounds that human review is justified only where one partner materially moves the program",
"Replaces the staged human ladder on the affiliate side with automated re-engagement such as incentive changes, asset refreshes, or lifecycle emails",
"Names the B2B-side metric set as sales acceptance rate, MQL-to-SQL conversion, win rate on partner-sourced opportunities, and average deal size",
"Names the affiliate-side metric set as clicks, conversions, and earnings per action",
"States that raw click and lead volume is a vanity metric on the B2B side because of its longer, multi-touch sales cycle",
"States the four rules identical on both sides: every metric carries a target and a red-flag floor, the mix blends leading and lagging indicators, nothing scoreable is self-reported, and every review produces owned dated actions",
"Re-parameterizes those four rules for the affiliate side rather than rebuilding them per side",
"Points affiliate-program-level metrics to mbfinotti/partnerships-skills@affiliate-performance-dashboard as a separate discipline"
]
},
{
"id": 9,
"prompt": "My CRO asked me to prove the partner review program we launched last year is working. My plan is to show her the aggregate partner scorecard average, which went from 61 to 68 across our 45 partners, plus partner satisfaction. Two caveats: we have never actually de-tiered anyone, and we have never surveyed partners about the review process itself. What else should be in the deck?",
"expected_output": "System-level KPIs that judge the measurement program rather than the partners, rejecting the aggregate score as evidence, ordered by what the program already records, with the two uninstrumentable metrics deleted by name.",
"files": [],
"expectations": [
"States that the measurement system is judged by its own KPIs, and that individual partner scores are the system's input rather than its score",
"Rejects the aggregate partner scorecard average moving from 61 to 68 as evidence that the review program itself works",
"Recommends review completion rate against the planned cadence, broken out by tier",
"Recommends action-item completion rate between reviews",
"Recommends the share of partners holding a computable, current scorecard",
"Recommends dispute rate on scorecard numbers raised by partners",
"Recommends the share of red-flagged partners entering the ladder within its stated timeline",
"Orders the instrumentation so counts the program already records come first, and metrics needing ladder history or a partner survey come last",
"Deletes ladder outcomes from the instrumentation plan because the program has no ladder history, and names it as deleted rather than carrying it as pending",
"Deletes review-process PSAT or NPS from the instrumentation plan because there is no survey capacity, and names it as deleted rather than carrying it as pending",
"Gives the reason for naming both as deleted: carried as pending metrics, they let a later reader assume the ladder was evaluated",
"States the condition that promotes ladder outcomes back up the order: a review about whether to keep the ladder, or a contested de-tiering"
]
},
{
"id": 10,
"prompt": "Kestrel Logistics Software. Board meeting in five weeks and the CEO wants a partner scorecard on the slide. All 34 of our partners are resellers, identical model, no ISVs, no referral partners, nothing else. Our PRM is a spreadsheet. Portal login data and LMS completions exist somewhere inside two SaaS tools but nobody here can export them and we have no analyst. One partner ops person, half-time, and that person is me. What should the design be?",
"expected_output": "A weighted composite alone, computable from data Kestrel holds today, with the leading/lagging split and the per-type tracks each deleted by name and reason rather than deferred.",
"files": [],
"expectations": [
"Recommends the weighted composite alone as the design for this program",
"Deletes the leading/lagging split from the design because portal, LMS and deal-registration data cannot be exported and there is no capacity to build that plumbing, and names it as deleted rather than deferring it",
"Deletes the per-partner-type tracks from the design because the program holds a single partner type, and names it as deleted with that reason",
"Gives the reason deletions are named rather than deferred: an item listed as later reappears as a build nobody scoped, or gets read later as a metric that already exists",
"States that a hard date inside the current review cycle promotes whatever is computable today over whatever is better",
"Marks each candidate metric as computable today, computable with work, or unmeasurable, and builds only from what is computable today",
"Refuses to score any dimension on estimates",
"Notes that the leading/lagging split can be revisited only once the export capability exists",
"Keeps the composite to 4-6 dimensions with weights summing to 100%",
"Pairs every KPI with a target, a red-flag floor, a stated measurement window, a named data source, and a named owner",
"Tests the scorecard preparation workload against the half-time partner ops capacity across 34 partners",
"Warns that the dimension list must be settled before the scorecard is shown to partners, because a scorecard partners have already seen is close to irreversible"
]
}
],
"trigger_queries": [
{ "query": "How should I build a scorecard for our channel partners?", "should_trigger": true },
{ "query": "partner QBR agenda", "should_trigger": true },
{ "query": "What metrics belong on a per-partner scorecard for resellers?", "should_trigger": true },
{ "query": "Our quarterly partner reviews are one-way status updates, how do I fix them?", "should_trigger": true },
{ "query": "Three gold partners haven't registered a deal in two quarters, what's the process?", "should_trigger": true },
{ "query": "I need a partner health check for our top 20 resellers", "should_trigger": true },
{ "query": "How do I score an ISV partner that never resells anything?", "should_trigger": true },
{ "query": "what should the red flag threshold be before we act on a partner", "should_trigger": true },
{ "query": "Write the underperformance ladder for our channel program", "should_trigger": true },
{ "query": "when is it defensible to terminate a reseller for not selling", "should_trigger": true },
{ "query": "our partner managers each cover 70 accounts and can't run reviews on all of them", "should_trigger": true },
{ "query": "should partners be able to see their own scores in the portal?", "should_trigger": true },
{ "query": "how often should we sit down with each reseller and go through their numbers", "should_trigger": true },
{ "query": "we give every partner the same quarterly review regardless of size, is that wrong?", "should_trigger": true },
{ "query": "how do I weight revenue vs certifications vs engagement for partners", "should_trigger": true },
{ "query": "corrective action plan for a reseller who keeps missing targets", "should_trigger": true },
{ "query": "I want to prove to my CRO that our partner review program is actually working", "should_trigger": true },
{ "query": "our partner numbers look green but the partner has gone completely silent", "should_trigger": true },
{ "query": "what data do both sides need before a partner business review", "should_trigger": true },
{ "query": "how do I stop partners from arguing with the numbers in their reviews", "should_trigger": true },
{ "query": "we're merging sourced and influenced revenue into one number for partners", "should_trigger": true },
{ "query": "de-tier or keep coaching? partner missed two plan checkpoints", "should_trigger": true },
{ "query": "design the review process for our 80 channel partners", "should_trigger": true },
{ "query": "partner scorecard dimensions and weights", "should_trigger": true },
{ "query": "I inherited a channel program where nobody has ever been demoted for performance", "should_trigger": true },
{ "query": "how to measure referral partners who only pass us intros", "should_trigger": true },
{ "query": "our partners barely claim their MDF, should that show up anywhere?", "should_trigger": true },
{ "query": "how do I tell whether one specific reseller is actually performing", "should_trigger": true },
{ "query": "what happens between the first warning and the exit for a failing partner", "should_trigger": true },
{ "query": "channel partner business review structure", "should_trigger": true },
{ "query": "quarterly business review with a reseller, what sections do I need?", "should_trigger": true },
{ "query": "our scorecard says green but three of that partner's customers just churned", "should_trigger": true },
{ "query": "how do I keep partners from gaming the numbers we score them on", "should_trigger": true },
{ "query": "certifications or closed revenue, what should count more for partners?", "should_trigger": true },
{ "query": "I need to decide which partners get my PAMs' hours this quarter", "should_trigger": true },
{ "query": "we run both a managed reseller channel and 3000 affiliates, one review system or two?", "should_trigger": true },
{ "query": "what KPIs judge a partner measurement program itself rather than the partners", "should_trigger": true },
{ "query": "our partner reviews never produce anything anyone follows up on", "should_trigger": true },
{ "query": "is there a standard set of weights for partner scorecards?", "should_trigger": true },
{ "query": "help me set targets and floors for each partner metric", "should_trigger": true },
{ "query": "what measurement window should partner revenue metrics use", "should_trigger": true },
{ "query": "who owns it when a partner drops below threshold?", "should_trigger": true },
{ "query": "escalation path for a channel partner that keeps missing commitments", "should_trigger": true },
{ "query": "the partner says our numbers are wrong and honestly I can't prove them", "should_trigger": true },
{ "query": "our advisory and SI partners score zero because they don't resell", "should_trigger": true },
{ "query": "reviewing a partner against the plan we agreed with them in January", "should_trigger": true },
{ "query": "I want to stop running QBRs with the long tail", "should_trigger": true },
{ "query": "what belongs in the pre-read we send partners before the meeting", "should_trigger": true },
{ "query": "how do we document that we gave a partner a fair chance before removing them", "should_trigger": true },
{ "query": "partner ops here, building the quarterly scoring model from CRM and LMS data", "should_trigger": true },
{ "query": "our channel chief wants to know which partners are at risk", "should_trigger": true },
{ "query": "set up the recurring check-in rhythm with our strategic resellers", "should_trigger": true },
{ "query": "grading our VARs", "should_trigger": true },
{ "query": "we need a defensible paper trail before we drop a partner", "should_trigger": true },
{ "query": "How many tiers should our reseller program have?", "should_trigger": false },
{ "query": "What benefits go in gold versus silver?", "should_trigger": false },
{ "query": "Write the promotion and demotion rules for our tier ladder", "should_trigger": false },
{ "query": "Tier qualification criteria for MSP partners", "should_trigger": false },
{ "query": "Migrate our existing partner base into the new four-tier structure", "should_trigger": false },
{ "query": "Our tiers are compressed, 80% of partners sit in gold", "should_trigger": false },
{ "query": "Model the P&L for our biggest SI partner", "should_trigger": false },
{ "query": "Is this reseller worth the 30 points of margin we hand them?", "should_trigger": false },
{ "query": "Partner CAC versus direct CAC", "should_trigger": false },
{ "query": "What's the payback period on the SI partnership we're considering?", "should_trigger": false },
{ "query": "Rank these five candidate alliances by where we should invest", "should_trigger": false },
{ "query": "Which of these three named partners deserves a dedicated headcount?", "should_trigger": false },
{ "query": "Map our whole partner landscape and find the coverage gaps", "should_trigger": false },
{ "query": "Which partner category should we launch next, MSPs or agencies?", "should_trigger": false },
{ "query": "Build a channel program from scratch, we have none today", "should_trigger": false },
{ "query": "Are we even ready to start working with partners?", "should_trigger": false },
{ "query": "Design our partner certification curriculum", "should_trigger": false },
{ "query": "What training do partners need before their first deal?", "should_trigger": false },
{ "query": "Build a joint go-to-market plan with Norvant for next year", "should_trigger": false },
{ "query": "Plan a co-marketing webinar with our integration partner", "should_trigger": false },
{ "query": "Write our deal registration policy, protection window and approval SLA", "should_trigger": false },
{ "query": "How do we split deal credit between the direct rep and the partner?", "should_trigger": false },
{ "query": "Two partners are both claiming the Halverson account", "should_trigger": false },
{ "query": "Our direct reps keep poaching partner deals", "should_trigger": false },
{ "query": "What metrics belong on our affiliate program dashboard?", "should_trigger": false },
{ "query": "Affiliate program ROI reporting for the exec team", "should_trigger": false },
{ "query": "Audit this month's affiliate commission payout before we disburse", "should_trigger": false },
{ "query": "Some affiliates look overpaid, reconcile the payout run", "should_trigger": false },
{ "query": "What commission rate should we pay affiliates?", "should_trigger": false },
{ "query": "Lifetime versus 12-month recurring affiliate commission", "should_trigger": false },
{ "query": "This affiliate's conversion rate is impossibly high, is it fraud?", "should_trigger": false },
{ "query": "Cookie stuffing detection rules", "should_trigger": false },
{ "query": "Welcome email series for newly approved affiliates", "should_trigger": false },
{ "query": "Draft the outreach email to recruit new affiliates", "should_trigger": false },
{ "query": "Write our affiliate program terms and conditions", "should_trigger": false },
{ "query": "Is this creator's caption FTC compliant?", "should_trigger": false },
{ "query": "Brief the creator we just signed on the campaign deliverables", "should_trigger": false },
{ "query": "Shortlist creators for our spring campaign", "should_trigger": false },
{ "query": "How do I measure one creator campaign before it launches?", "should_trigger": false },
{ "query": "Negotiating usage rights with a creator's talent manager", "should_trigger": false },
{ "query": "Write the first DM to a podcaster we want to partner with", "should_trigger": false },
{ "query": "How big should our refer-a-friend reward be?", "should_trigger": false },
{ "query": "Customers are creating fake accounts to farm referral credits", "should_trigger": false },
{ "query": "Should we list on AWS Marketplace?", "should_trigger": false },
{ "query": "How do I break into partnerships as a career?", "should_trigger": false },
{ "query": "Design the interview loop for a channel manager hire", "should_trigger": false },
{ "query": "Write a performance review for my direct report", "should_trigger": false },
{ "query": "Annual performance review template for the sales team", "should_trigger": false },
{ "query": "Build a quota attainment dashboard for our sales reps", "should_trigger": false },
{ "query": "Supplier scorecard for our freight carriers", "should_trigger": false },
{ "query": "Vendor performance management for our IT suppliers", "should_trigger": false },
{ "query": "QBR deck for our biggest customer account", "should_trigger": false },
{ "query": "Our Next.js app is slow, audit the performance", "should_trigger": false },
{ "query": "Which partnerships skill should I use for this project?", "should_trigger": false }
]
}
references/b2b-vs-b2c-contrast.md›
# B2B vs B2C Partner Performance Review
The contrast below is now grounded in direct B2B-vs-B2C affiliate comparisons (impact.com), not just inferred from each side's own vendor materials described separately:
- B2B channel sources document multi-dimensional, human-reviewed scorecards with tiering and account-manager involvement.
- Affiliate programs describe automated dashboards with self-serve access and no human review cadence.
- The named metric split is real: B2C affiliate review leans on clicks, conversions, and earnings-per-action - fast, volume-driven, and matching B2C's shorter sales cycle. B2B channel and B2B-affiliate review instead track sales acceptance rate (of leads sent, how many sales accepts), MQL-to-SQL conversion, win rate on partner-sourced opportunities, and average deal size - because B2B's longer, multi-touch sales cycle makes raw click and lead volume a vanity metric.
Validate this contrast against your own program; it may not transfer to all affiliate and referral programs.
## What is identical
The measurement discipline does not change:
- Every metric carries a target and a red-flag floor.
- The mix blends leading and lagging indicators.
- Nothing scoreable is self-reported.
- A review that produces no owned, dated action was not a review.
Never rebuild these rules per side; only re-parameterize them.
## What differs (inferred)
| Dimension | B2B channel partner | B2C affiliate/creator |
| ------------------------- | --------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------ |
| Unit of review | Partner firm - few, large, negotiated | Individual affiliate/creator - thousands, self-serve |
| Review vehicle | Per-partner scorecard + PAM-run QBR | Automated dashboard; the partner self-serves their numbers |
| Review level | Per partner, every managed partner | Cohort/segment level; per-partner review only for the head of the distribution |
| Cadence | Periodic human reviews (quarterly-style), relationship-bound | Continuous, automated recalculation |
| Scorecard content | Multi-dimensional composite: revenue, pipeline, certifications, engagement, customer outcomes | Volume and conversion metrics: clicks, conversions, earnings per action |
| Underperformance handling | Staged human ladder: diagnostic → corrective plan → de-tier/exit | Automated re-engagement: incentive changes, asset refreshes, lifecycle emails |
| Who intervenes | A named PAM with an escalation chain | The program, at scale; 1:1 outreach is the exception |
## The Leadpages affiliate case
The Leadpages case (PartnerStack article, updated 2026-08-21 - vendor case study, self-reported, not independently audited): after a rebrand, affiliate-driven customer acquisition fell 63%. The fix:
- Raised the commission incentive ($148 → $2,000 for five customers).
- Refreshed self-serve marketing assets.
- Added light 1:1 support and milestone recognition.
Result: a reported 16% lift in new trials and 14% lift in trial conversion. Note what the fix was _not_: no scorecard redesign, no QBR, no corrective action plan - the affiliate world's levers are program-wide and automated.
## Design consequence
- Run a hybrid program as two systems, not one: the B2B side gets this skill's scorecard, QBR, and ladder; the affiliate side gets automated dashboards and cohort review.
- Apply per-partner treatment to a top affiliate the way B2B treats a partner firm - a scorecard and a human review are justified only where one partner materially moves the program.
- For affiliate-side program metrics themselves, use `mbfinotti/partnerships-skills@affiliate-performance-dashboard` - a different discipline.
references/review-cadence-and-qbr.md›
# Review Cadence and the Partner QBR
## Cadence tiering
Tailor review depth to tier: strategic partners get executive attention and a full session, smaller partners get a lighter, more frequent touch. Running identical reviews for every partner wastes time on small accounts and under-serves strategic ones.
Treat the review vehicles as rungs on a ladder of PAM hours, ranked by commitments renegotiated and blockers cleared per hour spent. Which partner sits on which rung is the user's design decision, not an industry norm.
- efficiency: async scorecard delivery > exception-triggered live review > semiannual live review > quarterly QBR > quarterly QBR plus monthly check-in
- value: quarterly QBR plus monthly check-in > quarterly QBR > semiannual live review > exception-triggered live review > async scorecard delivery
- effort: quarterly QBR plus monthly check-in > quarterly QBR > semiannual live review > exception-triggered live review > async scorecard delivery
1. **Async scorecard delivery** - the score reaches the partner, nobody meets. Near-zero recurring effort once the recalculation runs; buys visibility, settles nothing on its own.
2. **Exception-triggered live review** - a live session only when a red flag fires. Costs an hour per firing partner and catches exactly the cases worth an hour.
3. **Semiannual live review** with async quarterly scorecards - a half-day per partner per year, enough to reset commitments without a standing calendar.
4. **Quarterly QBR** - the full agenda below, prepared and followed up. A standing job across the tier that runs it.
5. **Quarterly QBR plus a monthly working check-in** with an executive sponsor - the most expensive rung in both PAM and executive time, justified only where one partner materially moves the number.
Default rung: async delivery for every partner. Move a partner up one rung when the revenue or strategic bet it carries exceeds the PAM hours the next rung costs. Move any red-flagged partner to rung 2 immediately regardless of tier, since that is what the rung exists for.
The efficiency order starves the top rung, the quarterly QBR with a monthly executive check-in: highest value, highest cost, last on the ratio for every partner in the program. The handful of partners who materially move the number are exactly the ones a ratio will never buy it for. Promote it for a named partner when a single account carries enough revenue, or enough of a strategic bet, that losing it costs more than a year of the executive hours it consumes.
The order is a default, not a law. Re-rank against the coverage ratio from the Interview:
- A PAM carrying 80 partners cannot staff rung 3 broadly no matter what the tier model says.
- A program with ten partners can start everyone at rung 4 and skip the ladder entirely.
Where the coverage ratio makes a rung unstaffable, delete it from the cadence design and say which rung was deleted - a cadence promising reviews nobody has the hours to run fails at the first quarter, and fails in front of the partner.
## QBR vs joint business plan - keep them distinct
A partner QBR _reviews performance against_ the joint plan: targets hit or missed, blockers, next-quarter commitments. _Building_ the joint GTM/business plan is a separate exercise - `mbfinotti/partnerships-skills@joint-gtm-planning`'s job. A QBR that drifts into replanning the whole partnership loses its accountability function; schedule plan rebuilds separately.
## The 10-section partner QBR agenda
1. **Executive summary** - the quarter in one slide: revenue vs target, key wins, key issues.
2. **Performance review** - the partner scorecard: revenue, pipeline, new logos, certifications, engagement, renewals - each vs target and vs prior quarter.
3. **Wins and case studies** - deals closed, reference-able customers.
4. **Challenges and blockers** - what got in the way, what support is needed.
5. **Pipeline review** - registered deals, forecast, deals needing help.
6. **Enablement and certification status** - gaps to close.
7. **Marketing and MDF review** - campaigns run, results, MDF utilization.
8. **Goals for next quarter** - specific, measurable targets.
9. **Joint action plan** - action, owner (vendor or partner side), due date for each item.
10. **Tier status and path to next tier.**
Close with agreed next steps and the next QBR date.
## Preparation and facilitation rules
- Pull the scorecard from PRM/CRM so the numbers are factual, not asserted.
- Send the pre-read to the partner beforehand - the meeting is a discussion, not a data dump.
- Open by reviewing last quarter's actions - this accountability loop is what makes QBRs drive results.
- Spend the least time on backward-looking numbers and the most on the forward action plan.
- Assign every action an owner on both sides, plus a due date; carry actions into the next QBR and check completion.
- Keep an executive sponsor in the room for top-tier partners.
- Tie next-quarter goals to tier advancement so the partner sees what is in it for them.
- Document outcomes in the PRM; follow up between quarters, not only at the next review.
## Duration and attendees
Design both with the user:
- Size the duration to the agenda density and the partner's tier - a long-tail check-in and a strategic QBR should not run the same length.
- Invite whoever will own actions on each side; an executive sponsor belongs in top-tier sessions.
## Failure modes
- One-way status update with no actions - nothing changes.
- Showing up with no data, or with conflicting numbers - erodes credibility.
- Never following up on prior actions - "trains everyone that commitments don't matter."
- Identical QBRs for every partner regardless of tier.
- Spending fifty minutes on the past and five on the future - "defeats the purpose."
references/scorecard-design.md›
# Partner Scorecard Design
## The four scorecard models
Partner measurement has four established approaches. PRM vendors rebrand often (Allbound became Channelscaler, Zift became Unifyr) and the concepts outlive the product names. Verify any vendor implementation before citing it to a user.
- Five-category engagement taxonomy, described by Unifyr/Zift, Kris Blackmon.
- Maturity-staged KPI taxonomy, described by PartnerStack.
- Continuous leveling model, described by Channelscaler.
- Four-step partner attribution journey, described by Forrester, Kathy Contreras.
## Dimension menu with metric definitions
Pick 4-6 dimensions; more get ignored. Fill those slots in efficiency order - decisions the dimension settles per hour of data plumbing - and stop when the slots run out. Each metric below is category-generic; map it to whatever CRM/PRM/LMS the program runs.
- efficiency: sourced revenue > pipeline > engagement > capability > customer outcomes > influenced revenue
- value: sourced revenue > customer outcomes > pipeline > capability > engagement
- effort: customer outcomes > influenced revenue > capability > engagement > pipeline == sourced revenue
Sourced revenue and pipeline tie on effort because both read from the same deal-registration records the program already keeps - approved registrations for one, their stage history for the other - so neither adds a data source. They do not tie on value, and sourced revenue leads.
Customer outcomes is what this order starves: second on value, first on effort, fifth on the ratio. It waits for a second pass that most programs never run, and it is the only dimension that catches a partner selling well to customers who then churn. Promote it when partner-sourced retention lags direct, or when tier benefits are being tied to customer success rather than volume.
Influenced revenue sits last on efficiency and jumps to first the moment non-transacting partners are in scope - without it they have nothing to score.
The order is a default, not a law. Re-rank it against the program: an LMS already joined to partner records makes capability near-free.
Delete rather than defer what the program rules out, and say in the spec that the dimension was deleted:
- A PRM with no portal logging removes engagement.
- A program with one transacting partner type removes influenced revenue.
A dimension left in the menu unbuilt gets read later as a metric that exists.
**Revenue (lagging)** - sourced is near-zero effort where deal registration is enforced; influenced costs a quarter of attribution work plus finance sign-off
- **Partner-sourced revenue**: closed revenue from deals the partner originated, evidenced by an approved deal registration. Never blend with influenced.
- **Partner-influenced revenue**: revenue the partner touched but did not originate. Cap influence credit so attributed revenue never exceeds actual revenue; track it as its own KPI. Forrester's attribution work (Kathy Contreras, 2025-09-09, analyst blog) argues sourced-only measurement undercounts non-transacting partners - treat the attribution model as an upstream input to this dimension.
**Pipeline (leading)** - near-zero effort wherever deal registrations are already logged in the PRM
- **Deal-registration approval rate**: approved registrations ÷ submitted. A falling rate signals declining deal quality or rules confusion.
- **Pipeline velocity**: time-in-stage of registered deals vs the program median. Slowing velocity precedes a revenue miss by one or two quarters.
- **Time-to-first-deal**: signup to first registered (or closed - pick one and state it) deal. The per-partner activation signal in PartnerStack's taxonomy (vendor taxonomy).
**Engagement (leading)** - an hour where portal logs and the MDF ledger export cleanly, a week where they do not
- **Portal/program engagement**: logins, content usage, campaign participation - from program systems only.
- **MDF utilization**: claimed vs allocated funds, tied to documented campaigns. Unclaimed MDF is a disengagement signal, not savings.
**Capability (leading)** - about a week, and most of it is joining LMS credentials to partner records
- **Certified headcount**: individuals holding a _current_ certification - count credentials, not course enrollments.
**Customer outcomes (lagging)** - a quarter, because renewal and CSAT records have to be joined back to the sourcing partner and defended to finance
- **Partner-driven retention/CSAT**: renewal rate or CSAT of customers the partner sourced or services - separates partners who sell well from partners whose customers stay.
## Weighting guidance
- Sum weights to 100%; state each as a number, not "high/medium".
- Keep revenue-class dimensions at or below ~50% so leading indicators can actually move the score - a revenue-only score is a rearview mirror.
- Weights are self-set, never copied from a published standard - no vendor publishes numbers:
- Unifyr/Zift calls sales metrics "the most visible and telling" but gives no numbers (vendor blog).
- PartnerStack prioritizes by program maturity, not weight (vendor taxonomy).
- Every weight is the user's design decision - write the reason next to it.
## Target + red-flag pattern
Give every KPI two numbers, never one:
- **Target**: what a healthy partner of that type and tier achieves.
- **Red-flag floor**: the value that triggers the underperformance ladder - not just a yellow cell.
A target alone hides decay; a partner can drift for quarters below "good" without ever crossing a line anyone acts on. Both numbers are user-set, treat them as design decisions, not industry-standard thresholds.
## Measurement windows
- Match the revenue window to the sales cycle: rolling 12 months smooths lumpy enterprise deals; a quarterly window suits high-velocity motions.
- Score activity metrics (registrations, engagement, certifications) on the current quarter - they are the early-warning layer.
- State the window on every KPI; two people computing the same metric over different windows will dispute the score.
## Gameability checks
- Reject self-reported pipeline, partner-attested activity, and logo counts - the documented gaming vectors.
- Accept only data recorded by program-owned systems (CRM, PRM, LMS, MDF ledger) that the program can defend in a partner dispute.
- Test each metric: "could a partner improve this number without improving the underlying behavior?" If yes, drop or redesign it.
## Scoring non-transacting partner types
Give each type its own track - never a blanked-out revenue scorecard. Each list below is in efficiency order: build left to right and stop when the track has enough dimensions to decide with. Counts the program already records come first; attributed revenue comes last everywhere, because attribution costs a quarter and invites the very dispute the scorecard exists to settle.
- **ISV/tech partners**: integration attach rate on closed deals > joint-solution certifications > integration adoption/health among shared customers > capped influenced revenue.
- **Referral partners**: accepted referrals > referral-to-opportunity conversion > sourced pipeline value > referral quality (win rate of referred deals, which needs a year of closed history before it means anything).
- **Advisory/SI partners**: co-delivered implementations > certified consultant headcount > implementation CSAT > capped influenced revenue.
Attach rate, accepted referrals and co-delivered implementations lead their tracks because each settles the same decision the composite settles for a reseller - is this partner producing - at near-zero plumbing cost. Re-rank per program:
- Product telemetry the team cannot query demotes attach rate and integration health below certifications.
- An attribution model already agreed with finance promotes influenced revenue to the front of every track.
## Negative example - a scorecard that fails
Illustrative; every listed flaw is a real anti-pattern:
- 14 metrics, no weights - nobody knows what matters, so nothing moves.
- "Pipeline" is partner-self-reported - inflated every quarter before review.
- One blended "partner revenue" number - sourced and influenced indistinguishable, finance rejects it.
- Targets only, no red-flag floors - decline is visible but never actionable.
- No data source or owner per metric - three teams compute three different scores.
- One identical scorecard for resellers and ISVs - every ISV scores zero on revenue and disengages.
references/underperformance-ladder.md›
# The Underperformance Ladder
## Design note
Every number in this ladder, trigger values, response times, plan durations, notice periods, is the user's design decision. Anything that can de-tier or terminate a partner needs legal review against the signed partner agreement before it ships.
The structure combines a trigger table with timelines and an escalation chain (adapted from carrier/supplier scorecarding practice in freight logistics, a structural parallel), and adds the coaching-first framing: flag at-risk partners in real time and intervene before formal ladder action starts.
## The staged structure
Never jump from a bad quarter to termination. Four stages, each documented - and they are also ranked, by partners recovered per unit of effort and irreversibility:
- efficiency: at-risk outreach > diagnostic conversation > corrective action plan > de-tier > exit
- value: de-tier > exit > corrective action plan > diagnostic conversation > at-risk outreach
- effort: exit > de-tier > corrective action plan > diagnostic conversation > at-risk outreach
- compliance cost: exit - notice terms in the signed agreement, legal sign-off, an outcome the partner can contest and nobody can undo - > de-tier, which may collide with tier commitments already promised in writing > corrective action plan, which becomes evidence for whichever side is right > diagnostic conversation == at-risk outreach, neither of which carries any
The stages:
1. **Trigger** - a KPI crosses its red-flag floor for a full measurement window, or a defined disengagement signal fires (deal registrations stop, portal goes quiet, certifications lapse).
2. **Intervention** - the PAM runs a diagnostic conversation within the stated response time: lead with the scorecard data, not accusation; diagnose cause (lost champion, capacity, competing vendor, product gap) before prescribing.
3. **Corrective action plan** - a written, signed plan (shape below) with checkpoints and a stated consequence.
4. **De-tier or exit** - only after the documented plan has failed at its final checkpoint.
De-tier outranks exit on value rather than tying with it: both reclaim the PAM's hours, but de-tiering leaves the partner's existing customers and pipeline in place and can be walked back if the diagnosis was wrong, where exit buys certainty and forfeits everything else permanently. They do not tie on any other axis either - exit costs more effort and carries the heavier compliance exposure.
Default rung: the diagnostic conversation, plus at-risk outreach ahead of the formal trigger wherever the scorecard recalculates often enough to see a partner drifting. The only condition that moves a partner up a rung is a dated checkpoint missed with a named owner - never a second bad quarter on its own, and never impatience.
The efficiency order starves the top two rungs: they carry the most value on the list and the most cost, so a ratio always finds another quarter of coaching cheaper, which is how a program accumulates partners nobody has ever removed. Promote de-tier the moment a signed corrective plan fails at its final checkpoint - at that point further coaching spends PAM hours the scorecard has already said are better spent elsewhere.
The order is a default, not a law. Re-rank against the program:
- A compliance breach or fraud skips every coaching rung by design (see the trigger table's carve-out).
- A partner with no signed tier commitments makes de-tiering cheap and reversible.
Where a PAM carries too many partners to notice drift, at-risk outreach is deleted from the ladder for that program and named as deleted - the ladder starts at the diagnostic conversation, rather than listing a rung nobody has the coverage to run.
## Trigger table
Deliver this as a table: trigger → action → timeline. Illustrative rows (values are examples for shape, not benchmarks):
| Trigger | Action | Timeline |
| ------------------------------------------------------------------------------- | ------------------------------------------------------------------------- | ---------------------------------------------------- |
| Any KPI below its red-flag floor for one full window | PAM diagnostic call; findings logged in PRM | Within the program's stated response time (user-set) |
| Two or more KPIs red-flagged in the same period | Formal performance review meeting; corrective plan drafted | User-set, faster than a single flag |
| Disengagement signal: no deal registrations plus no portal activity in a period | PAM outreach - treat as at-risk, not yet as failing | User-set |
| Corrective plan checkpoint missed | Escalate one step up the chain; consequence restated in writing | At the checkpoint date |
| Compliance breach, fraud, or brand damage | Escalate directly to channel chief and legal - bypass the coaching stages | Immediately |
## Escalation chain
Name a role at every step so no trigger dies in an inbox:
1. **PAM** - owns triggers, diagnostics, and the corrective plan day-to-day.
2. **Partner/channel manager lead** - owns repeated flags and missed checkpoints.
3. **Channel chief** - owns de-tier decisions and any plan touching a strategic partner.
4. **Channel chief + legal** - jointly own exit; termination follows the agreement's notice terms, never an ad-hoc email.
## Corrective action plan shape
- Cite the specific below-floor KPIs from the scorecard - data, not opinion.
- Set measurable recovery goals with dates; stage checkpoints across the plan (a 30/60/90-style staging is the analog's pattern - the actual lengths are the user's choice).
- State what the vendor commits in return: enablement session, leads, MDF, executive attention. A one-sided plan reads as a punishment memo.
- State the consequence of missing the final checkpoint - de-tier or exit - explicitly, in writing.
- Have both sides sign; log the plan and every checkpoint outcome in the PRM. The document trail is what makes a later exit defensible.
## De-tier vs exit
- **De-tier**: the partner stays in the program at a lower tier; apply the tier structure's own demotion, grace, and appeals rules (`mbfinotti/partnerships-skills@partner-tiering` owns those).
- **Exit**: termination under the partner agreement - gated on the documented corrective action having failed, except for the compliance/fraud carve-out, which still goes through legal.
- Record the reason and the evidence trail either way; an undocumented exit invites dispute and poisons the partner community's trust in the program.
references/worked-examples.md›
# Worked Examples
Every number below is illustrative - invented to show the expected level of specificity, not a benchmark. Replace all of them with the user's own targets and floors.
## Example 1 - transacting reseller scorecard
Partner: mid-tier reseller, ~$40K average deal, 12-month rolling revenue window, activity metrics scored per quarter.
| Dimension (weight) | KPI | Target | Red flag | Window | Source | Owner | Actual | Score |
| ----------------------- | -------------------------------------- | --------------------- | -------------------- | ----------- | ------------------------ | --------------- | --------------- | --------------- |
| Revenue (40%) | Partner-sourced revenue | $800K | $400K | Rolling 12m | CRM (approved deal regs) | Partner ops | $650K | 32/40 |
| Pipeline (20%) | Deal-reg approval rate | ≥85% | <60% | Quarter | PRM | PAM | 90% | 11/20 |
| | Registered pipeline value | $500K | $200K | Quarter | PRM | PAM | $260K | (blended above) |
| Capability (15%) | Certified headcount | 4 current | <2 | Quarter | LMS | Enablement lead | 3 | 11/15 |
| Engagement (15%) | Portal activity + MDF utilization | Active + ≥70% claimed | Inactive 60d or <30% | Quarter | PRM + MDF ledger | PAM | Active, 55% MDF | 10/15 |
| Customer outcomes (10%) | Retention of partner-sourced customers | ≥90% | <75% | Rolling 12m | Billing/CS system | Finance | 93% | 10/10 |
**Composite: 74/100.** Status bands (user-set): ≥80 healthy, 60-79 stable, 40-59 at-risk, <40 critical. Reading: revenue and retention solid; thin registered pipeline is the leading warning - raise it at the next check-in before it becomes a revenue miss. No red-flag floor crossed, so the ladder does not fire.
## Example 2 - non-transacting ISV/tech partner scorecard
Partner: integration ISV; no resold revenue, so revenue-track KPIs would score it blank. Its own track:
| Dimension (weight) | KPI | Target | Red flag | Window | Source | Owner | Actual | Score |
| ------------------ | --------------------------------------------- | --------- | -------- | ----------- | ----------------------- | ----------------- | ------ | ----- |
| Influence (35%) | Influenced revenue (capped) | $300K | $100K | Rolling 12m | CRM opportunity tags | Partner ops | $340K | 35/35 |
| Adoption (25%) | Integration attach rate on closed deals | ≥15% | <5% | Quarter | CRM + product telemetry | Partner ops | 11% | 17/25 |
| Health (20%) | Active shared customers using the integration | 60 | <25 | Quarter | Product telemetry | PAM | 58 | 19/20 |
| Capability (10%) | Joint-solution certifications | 2 current | 0 | Quarter | LMS | Enablement lead | 2 | 10/10 |
| Co-marketing (10%) | Qualified leads from joint campaigns | 25 | <5 | Quarter | Marketing automation | Partner marketing | 12 | 6/10 |
**Composite: 87/100 - healthy.** The partner never resells a dollar yet gets a real, defensible score - the point of per-type tracks.
## Example 3 - a worked underperformance sequence
Partner: reseller from Example 1's program, one year later.
1. **Q1 trigger.** Sourced revenue falls below its $400K floor for a full window; deal registrations stop; portal quiet 70 days. Two red flags → formal review per the trigger table. PAM logs it in the PRM within the program's stated response time.
2. **Diagnostic call.** Scorecard presented first - data, not accusation. Diagnosis: the partner's champion (their partnerships lead) left; nobody picked up the vendor's line.
3. **Corrective action plan (90 days, checkpoints at 30/60/90 - durations user-set).** Partner commits:
- Name a new partnership owner within 30 days.
- Re-certify 2 sellers by day 60.
- Register $150K of pipeline by day 90.
Vendor commits: a re-onboarding enablement session and 5 qualified leads. Consequence stated in writing: de-tier at the next tier review if the day-90 checkpoint fails. Both sides sign.
4. **Day-60 checkpoint.** New owner named, 1 of 2 certifications done, $60K registered. Partial - plan continues, escalated one step to the channel manager lead for visibility.
5. **Day-90 outcomes - two branches.**
- _Recovery_: both certifications current, $170K registered. Plan closed as recovered; partner returns to normal cadence; the episode and outcome stay logged in the PRM.
- _Failure_: registrations stall at $70K. The documented plan has failed - de-tier proceeds under the tier structure's demotion and appeals rules, communicated by the channel chief, with the paper trail attached.
SKILL.md›
---
name: partner-performance
description: Measure and review the performance of individual partners in a B2B partner program - the per-partner scorecard (dimensions, weights, targets, red-flag thresholds, data sources), the review cadence and QBR structure, and the underperformance ladder from trigger through corrective action to de-tier or exit. Also covers the B2C affiliate and creator review contrast. Use whenever the user mentions a partner scorecard, partner reviews, a channel partner QBR, a partner health check, or an underperforming channel partner, even if they never say performance. One partner at a time. Do NOT use for designing the tier ladder itself - use mbfinotti/partnerships-skills@partner-tiering instead.
license: MIT
metadata:
author: Maya-Beth Finotti
version: "1.1.4"
---
# Partner Performance
Define how a B2B partner program measures and reviews individual partners: the per-partner scorecard, the review cadence and partner QBR, and the underperformance ladder. No single canonical partner-performance methodology exists - say so plainly rather than invent one. What the field genuinely offers for per-partner measurement:
- **A five-category engagement taxonomy**: sales performance, partner satisfaction, training/certification completion, marketing/lead generation, partner lifecycle and retention. No numeric weights are published anywhere - set them with the user. Evidence class: vendor blog.
- **A maturity-staged KPI taxonomy**: recruitment → activation → engagement → revenue efficiency, prioritized by program maturity rather than by fixed weights. Evidence class: vendor taxonomy.
- **Continuous leveling**: partner scores recalculated from CRM, LMS and portal data, visible to the partner, with at-risk flags that trigger coaching before de-tiering. Evidence class: vendor product model.
- **A four-step partner attribution journey** - crediting value to partners including non-transacting ones - is about attribution, not a per-partner scorecard. Use it upstream, as an input to the scorecard's revenue dimension. Evidence class: analyst blog.
These four are evidence inputs, not a menu to choose from - the choice the user actually makes is the scorecard approach, ranked under "Designing the system with the user". Each model is named to its originating vendor or analyst in [references/scorecard-design.md](references/scorecard-design.md); the concepts above are what the skill actually applies. Keep it that way - PRM vendors rebrand and restructure often, so a body written around today's product names dates faster than the ideas in it.
## Interview
Ask before designing anything. One question per message; offer multiple-choice options; skip whatever the user already answered.
- How many partners, and of which types - reseller, VAR/MSP, agency, SI, ISV/tech, referral, distributor? Which types actually transact?
- What is measured today, and where does the data live - CRM, PRM, LMS, spreadsheets, nowhere?
- Do partners currently see their own numbers?
- What is the review cadence today, and does it differ by tier?
- What does "underperforming" mean today - and does anything actually happen when a partner hits it?
- Roughly how much partner revenue is sourced vs influenced - and can your systems tell the two apart?
- Review culture today: is a QBR a working session or a status update?
- How many partner managers (PAMs), and what is the coverage ratio - partners per manager?
- Is this B2B channel only, or does the program also include affiliate/creator partners?
- What is immovable: signed partner agreements, fiscal calendar, existing tier commitments?
- Who signs off: channel chief, CRO, finance, legal?
- By what date must the first scored review actually land - inside the current review cycle, next fiscal year, no fixed date? A date inside the current cycle promotes the weighted composite alone and defers everything the program's partner mix does not force.
- Is this a one-off exercise - a board or QBR question you must answer once - or a system meant to run every quarter? A one-off stops at the composite; a compounding system justifies the leading/lagging split and per-type tracks, which only pay back across repeated reviews.
- What is the effort ceiling: partner-ops hours available, whether anyone can export portal, LMS and deal-registration data, and whether the design can still change once partners have seen it? No export capacity deletes the leading/lagging split from this design rather than deferring it; a scorecard partners have already been shown is close to irreversible, so settle the dimension list before socializing it.
Those last three answers re-rank the design options in the next sections - ask them before proposing anything, not while presenting the menu.
## Workflow
1. Run the Interview; collect every current-state fact the design depends on.
2. Confirm scope: measuring and reviewing individual partners in a running program. Tier design, program design, single-partner economics, and building the joint GTM plan belong to sibling skills (see Reference) - this skill reviews performance against a joint plan, it never builds one.
3. Inventory the data: mark each candidate metric computable today, computable with work, or unmeasurable. Never score on estimates.
4. Pick the scorecard approach from the ranked rungs in "Designing the system with the user", then design it: dimensions with weights, per-KPI target and red-flag floor, measurement window, data source and owner - with a track per partner type, including non-transacting ones. See [references/scorecard-design.md](references/scorecard-design.md).
5. Set recalculation cadence and partner visibility - what the partner sees, and when.
6. Design the review cadence by tier and the partner QBR. See [references/review-cadence-and-qbr.md](references/review-cadence-and-qbr.md).
7. Design the underperformance ladder: triggers → intervention → corrective action → de-tier/exit. Route anything that can de-tier or terminate through legal. See [references/underperformance-ladder.md](references/underperformance-ladder.md).
8. Validate per that same section: present the spec one section at a time and gate each before writing the next.
9. Dry-run the draft scorecard against real partners; inspect the score distribution and the PAM workload it implies; adjust.
10. Check the pass threshold; iterate until every check holds.
11. Stop at the approval gate - finalize nothing without the user's explicit approval of the full spec.
12. If your harness has persistent memory, memorize the approved scorecard, thresholds, and first review date; otherwise tell the user to store the spec where partner ops can retrieve it.
- If you can browse the web, verify any vendor model before citing it by name to the user; the attributions and their dates are in [references/scorecard-design.md](references/scorecard-design.md).
- Otherwise, flag vendor examples as possibly stale.
## Designing the system with the user
Run the design the way channel teams actually work - through partner ops modeling and stakeholder review, not as a solo spreadsheet exercise:
- Ask one question per message throughout; never batch questions.
- Assemble the data channel teams bring: sourced vs influenced revenue split, deal-registration records, certification/LMS completion, portal engagement, PSAT/NPS, MDF utilization. Model with what exists; name what is missing.
- Map who must be involved: channel chief accountable, partner ops builds the model, finance validates the numbers, PAMs must be able to run it, legal reviews anything that can trigger de-tiering or termination.
- Present the three candidate scorecard approaches below in the ranked order given, with your recommendation and its reason. They are rungs, not rivals - each layers onto the one before.
- Once the user picks a rung, present the spec one section at a time - scorecard, then cadence and QBR, then ladder - and validate each before writing the next.
- Socialize the near-final design with a partner advisory council or a pilot cohort before rollout; a measurement system partners never saw breeds disputes, not performance.
- Gate finalization on explicit user approval of the assembled spec.
### Ranking the scorecard approaches
Rank by what each approach settles per hour of partner-ops build time. This is pass threshold 5 - "a PAM can prepare a scorecard in the time they actually have" - applied to the design work as well as the review prep.
- efficiency: weighted composite > leading/lagging split > per-partner-type tracks
- value: weighted composite > per-partner-type tracks > leading/lagging split
- effort: per-partner-type tracks > leading/lagging split > weighted composite
1. **Weighted composite** - 4-6 dimensions, one number per partner. Settles the triage decision: which partners get the PAM's hours this quarter. Costs about a week of partner-ops work to define and near-zero per review afterwards, and it runs on CRM/PRM data most programs already hold. Fully reversible until partners see it.
2. **Leading/lagging split** - a results score beside an early-indicator score. Settles the timing decision: intervene now, or wait a quarter. Near-zero effort when the composite already carries pipeline, engagement or certification dimensions - tag each one and subtotal. A quarter of plumbing when portal, LMS or deal-registration data cannot be exported yet, and that case is what drops it below the composite.
3. **Per-partner-type tracks** - one dimension set per partner type. Settles the coverage decision: whether a non-transacting partner earns its investment, a question a single composite answers with a blank. Costs a week per type to define, each with its own data sources and negotiated targets, then becomes a standing job as partner types multiply.
Per-partner-type tracks are what this efficiency order starves: second on value, first on effort, last on the ratio. A program that only computes efficiency scores its transacting resellers well and leaves its ISVs, referral and advisory partners on a composite that reads as a blank. Promote rung 3 above rung 2 the moment the program holds a non-transacting partner type - pass threshold 3 requires a real score for it, and no amount of composite tuning produces one.
Defaults, and what moves them:
- Start every program at rung 1; add rung 2 as soon as the leading data exports cleanly.
- A program with one partner type deletes rung 3 from the design, and the spec names it as deleted with that reason - a track listed as "later" reappears as a build nobody scoped.
- A program that cannot export portal, LMS or deal-registration data, and has no capacity to build that plumbing, deletes rung 2 the same way - revisit it only once the export exists.
The order is a default, not a law: it shifts with context and with who executes it. Re-rank it against what the Interview already told you:
- A PRM that already reports leading indicators makes rung 2 near-free and promotes it above further composite tuning.
- A partner manager with no analyst support should ship rung 1 rather than a three-track design nobody can recompute next quarter.
- A hard date inside the current review cycle promotes whatever is computable today over whatever is better.
## The Partner Performance System
Deliver the engagement as this artifact - a decision record the user hands to partner ops, PAMs, and legal:
```
PARTNER PERFORMANCE SYSTEM , <program>, <date>
Scorecard:
Dimensions : each with a weight; weights sum to 100%
Per KPI : definition + target + red-flag floor + measurement window
+ data source + owner
Tracks : one per partner type, incl. non-transacting
(ISV/tech, referral, advisory/SI)
Recalculation : continuous | monthly | quarterly, and who recomputes
Partner visibility: what each partner sees, and when
Review:
Cadence by tier : which partners get a full QBR, which get lighter
check-ins; duration and attendees (user's design decision)
QBR agenda : sections, opening with last quarter's action check,
closing with a joint action plan
Action tracking : where owned, dated actions live between reviews
Underperformance ladder:
Triggers : trigger → intervention → timeline table
Escalation chain : named roles per step
Corrective plan : shape, duration, checkpoints, stated consequence
De-tier / exit : criteria, gated on documented corrective action having
failed; legal-reviewed
System KPIs : how the measurement system itself is judged,
with the first review date
```
Rules about the spec itself:
- Attach a data source and a named owner to every KPI - a metric nobody computes reviews nobody.
- Pair every target with a red-flag floor; a lone target hides decay until it becomes a crisis.
- Reject any metric a partner can self-report or game; use only data the program itself records.
- Present durations, attendee lists, thresholds, and timelines as the user's design decisions, they are self-set, not industry norms.
## Pass threshold
Ship nothing until all five hold; iterate the design until they do:
1. **Every KPI is fully specified**: target, red-flag floor, measurement window, named data source, named owner.
2. **Nothing is self-reported or gameable** - every scorecard input comes from data the program records and can defend in a dispute.
3. **Every non-transacting partner type is scorable** without resold revenue - an ISV, referral, or advisory partner gets a real score, not a blank.
4. **Every review ends with owned, dated actions** - and the next review opens by checking them.
5. **A PAM can prepare a scorecard in the time they actually have** - test the prep workload against the coverage ratio from the Interview.
## Diagnosing an existing review system
When the user arrives with a running system instead of a blank page, work the table top-down. The rows are ordered by reviews repaired per hour of change, not by severity:
- efficiency: action-tracking loop > QBR pre-read and agenda > cadence tiering > partner visibility > leading-indicator mix > per-type tracks > ladder enforcement
- effort: ladder enforcement > per-type tracks > leading-indicator mix > partner visibility > cadence tiering > QBR pre-read and agenda == action-tracking loop
- compliance cost: ladder enforcement - contract review of the demotion and termination terms, and a decision the partner can contest - > every other fix here, which carries none
The QBR pre-read and the action-tracking loop tie on effort because each is a change to a meeting that already happens - one line added to an agenda template, one shared document where actions live - with no new data source, no new system and nobody's sign-off. They part on value, and the action loop wins, since a review whose actions nobody tracks repeats itself.
The top two rows cost near-zero and change every review that follows. What that ordering starves is ladder enforcement: it is the only fix on the list that changes what happens to a partner who never improves, and it lands last because legal review gates it and a wrong demotion is expensive to reverse.
Promote it when partners have already sat through repaired reviews and still miss their numbers - at that point the review process is not the fault, and every further agenda fix is motion.
Re-rank against the program in front of you, and strike what does not apply:
- A program whose partners already see live scorecards has no visibility row.
- A program with a single partner type has no tracks row.
Delete both from the plan rather than leaving them as pending work.
| Symptom | Check first | Design variable at fault |
| ----------------------------------------------------- | ------------------------------------------------------------------------------------------------------------- | ------------------------------------- |
| Actions from last quarter never got done | Whether the QBR opens with the prior action check, and where actions are stored between reviews | Action-tracking loop |
| QBRs are one-way status updates | Whether a data pre-read goes out, and what share of the agenda is forward-looking | QBR agenda and pre-read discipline |
| Every partner gets the same review regardless of size | Whether cadence and depth vary by tier | Cadence tiering |
| Partner disputes the numbers | Whether the partner sees the same data before the meeting, and which system is the source of truth | Data source and partner visibility |
| Scorecard says green but the partner has gone quiet | Whether any leading indicator (portal logins, deal registrations, certification activity) is on the scorecard | Dimension mix - lagging-only |
| Only transacting partners have a score | Whether per-type tracks exist for ISV/referral/advisory partners | Scorecard tracks |
| Nobody is ever de-tiered | Whether ladder triggers have owners and timelines, and what legal blocks exist | Ladder enforcement, not the scorecard |
## KPIs
Judge the measurement system, not the partners - individual partner numbers are the system's input, not its score:
Instrument them in this order when nobody has analyst support - the first three are counts the program already records, the last two need a year of ladder history or a partner survey:
- efficiency: review completion rate > action-item completion rate > share with a current scorecard > dispute rate > ladder timeliness > ladder outcomes > review-process PSAT
1. Review completion rate against the planned cadence, by tier.
2. Action-item completion rate between reviews.
3. Share of partners with a computable, current scorecard.
4. Dispute rate on scorecard numbers raised by partners.
5. Share of red-flagged partners entering the ladder within its stated timeline.
6. Ladder outcomes: share recovering after corrective action vs de-tiered or exited.
7. Partner satisfaction (PSAT/NPS) with the review process itself.
That order starves ladder outcomes: it is the only number that says whether the underperformance ladder does anything, and it needs a year of ladder history before it reads at all, so a ratio buries it every quarter behind counts the program already holds. Promote it whenever the review in front of you is about whether to keep the ladder, or whenever de-tiering is being contested. Where the program has no ladder history and no survey capacity, delete rows 6 and 7 from the instrumentation plan and name them as deleted - carried as pending metrics, they let a later reader assume the ladder was evaluated.
## B2B vs B2C
Identical in both worlds:
- Every metric carries a target and a red-flag floor.
- The metric mix blends leading and lagging indicators.
- Nothing is self-reported.
- Every review produces owned actions.
Different:
- **B2B channel**: human-reviewed, relationship-bound - per-partner scorecards, PAM-run QBRs, a staged human ladder.
- **B2C affiliate/creator**: automated dashboards, cohort-level review, automated re-engagement - per-partner review only for the head of the distribution.
See [references/b2b-vs-b2c-contrast.md](references/b2b-vs-b2c-contrast.md) for the full contrast with its evidence caveats.
## Invocation Examples
- "Design the per-partner scorecard for our channel program - 80 partners, mix of transacting resellers and non-transacting ISVs."
- "Three Gold partners have not sold in two quarters. Write the underperformance ladder from trigger to de-tier."
- "Our partner QBRs are status theater. Restructure the agenda and tell me what data both sides need before the meeting."
## Reference
- [references/scorecard-design.md](references/scorecard-design.md) - the dimension menu with metric definitions, weighting guidance, target/red-flag pattern, windows, gameability checks, non-transacting tracks, and a negative example.
- [references/review-cadence-and-qbr.md](references/review-cadence-and-qbr.md) - cadence tiering, the 10-section partner QBR agenda, preparation rules, and failure modes.
- [references/underperformance-ladder.md](references/underperformance-ladder.md) - trigger table, escalation chain, corrective-action-plan shape, and exit criteria.
- [references/worked-examples.md](references/worked-examples.md) - a worked transacting scorecard, a worked non-transacting ISV scorecard, and a worked underperformance sequence.
- [references/b2b-vs-b2c-contrast.md](references/b2b-vs-b2c-contrast.md) - the full B2B/B2C review contrast.
Sibling skills (same collection):
- `mbfinotti/partnerships-skills@partner-economics` - single-partner P&L and unit-economics modeling.
- `mbfinotti/partnerships-skills@partner-ecosystem` - ecosystem-level health metrics; it hands per-partner scorecards and review cadences to this skill.
- `mbfinotti/partnerships-skills@partner-enablement` - measuring whether the enablement program worked, at program level.
- `mbfinotti/partnerships-skills@joint-gtm-planning` - builds the joint GTM/business plan with a partner; this skill reviews performance against that plan, never builds it.
- `mbfinotti/partnerships-skills@partner-channel-program` - designing a whole partner program from scratch.
- `mbfinotti/partnerships-skills@affiliate-performance-dashboard` - affiliate program metrics, a different discipline.