partner-tiering

The saved excerpt is a snapshot from when this skill was listed. The external source remains the complete and most current version.

---
name: partner-tiering
description: Design or redesign the tier structure inside an existing B2B partner program - qualification criteria, benefit bundles, tier count, promotion and demotion rules, review cadence for registered/silver/gold-style ladders, and migration of the current partner base. Also covers the B2C affiliate, creator and loyalty tier contrast. Use whenever the user mentions partner tiers, tier criteria, tier benefits, tier compression, demotion rules, or reseller, MSP and agency tier design, even if they never say tiering. Do NOT use for standing up a partner program from scratch - use mbfinotti/partnerships-skills@partner-channel-program instead. Affiliate commission payout tiers are a separate skill.
license: MIT
metadata:
  author: Maya-Beth Finotti
  version: "1.2.7"
---

# Partner Tiering

Define the criteria and benefits that separate partner tiers inside an existing B2B partner program. No single canonical tier-design methodology exists - say so plainly rather than invent one. What the field actually offers:

- **Forrester's 3-tier norm**: tiering is used by 98% of top IT partner programs, averaging three tiers named "good, better, best" (analyst assertion, not raw survey data).
- **The Alexander Group's three tier mechanics**: volume, engagement, or engagement pathways (points accumulated across multiple dimensions) - the first structural choice a designer makes.
- **Forrester's Channel Partner Segmentation Matrix** (Stephanie Sissler, Feb 2023): a 3x3 current-performance x future-potential grid, explicitly an internal overlay on a public tier ladder, never a replacement for it.
- **Jay McBain's critique** (an attributed practitioner viewpoint, not a framework): revenue is a lagging indicator, and non-transacting partners - tech/ISV, referral, advisory - structurally don't fit a revenue ladder.

## 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, MSP, agency, ISV/tech, referral? Which types actually transact?
- What are the current tiers, their criteria, and the current distribution - how many partners sit in each?
- What is the specific pain: top tier crowded, nobody advancing, benefits ignored, long tail neglected, channel conflict?
- How concentrated is partner-sourced revenue - roughly what share comes from the top 10-20% of partners?
- What does each tier cost to serve today: margin give, deal-registration uplift, MDF, PAM headcount?
- What is the review cadence today, and is demotion actually enforced?
- What is the average sales-cycle length? (Any deal-registration protection window offered as a tier benefit is sized at ≥75% of it, so a window picked from a stock range without this number can be half what the cycle needs.)
- By what date must the new structure be live, and by what date must its results show up in tier movement?
- Is this a one-off fix to a specific pain, or a compounding asset you will re-score every cycle from here on?
- What is the effort ceiling: partner-ops hours, data work available, and the political capital to actually enforce a demotion?
- Is this B2B channel only, or does the program also run B2C-facing affiliate, creator, or loyalty tiers?
- What is immovable: signed partner agreements, fiscal calendar, comp plans?
- Who must sign off: channel chief, CRO, finance, legal?

## Workflow

1. Run the Interview. Collect every current-state fact the design depends on.
2. Confirm scope: refine the tier layer of a program that already exists. Building a program from scratch or fixing individual-partner performance belongs to the sibling skills in the Reference section.
3. Build the baseline: partners, revenue contribution, and cost-to-serve per current tier. Expect a power law - 10-20% of partners driving 70-80% of channel revenue is the commonly cited pattern (PRM-vendor rule of thumb, not an empirical dataset).
4. Decide the tier