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.
- Skill ID
- mbfinotti/partnerships-skills/partner-performance
- Publisher
- mbfinotti
- Repository
- partnerships-skills
- Installs
- 513
- Files
- 7
- License
- MIT
- Synced
- Oct 23, 2026
Open any RiverX project, open the Skills panel in the chat, and search for this identifier. The files are fetched from the source repository at install time.
mbfinotti/partnerships-skills/partner-performanceInstalls these files- SKILL.md
- evals/evals.json
- references/b2b-vs-b2c-contrast.md
- references/review-cadence-and-qbr.md
- references/scorecard-design.md
- references/underperformance-ladder.md
- references/worked-examples.md
What this skill tells the agent
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; 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
- Run the Interview; collect every current-state fact the design depends on.
- 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.
- Inventory the data: mark each candidate metric computable today, computable with work, or unmeasurable. Never score on estimates.
- 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.
- Set recalculation cadence and partner visibility - what the partner sees, and when.
- Design the review cadence by tier and the partner QBR. See references/review-cadence-and-qbr.md.
- 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.
- Validate per that same section: present the spec one section at a time and gate each before writing the next.
- Dry-run the draft scorecard against real partners; inspect the score distribution and the PAM workload it implies; adjust.
- Check the pass threshold; iterate until every check holds.
- Stop at the approval gate - finalize nothing without the user's explicit approval of the full spec.
- 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.
- 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
More from mbfinotti
Use this skill in a project
Open any RiverX project, search the Skills panel for mbfinotti/partnerships-skills/partner-performance, and install it in one click.
