mbfinotti/partnerships-skillsMIT6 files

Partner Tiering

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.

Specification
Skill ID
mbfinotti/partnerships-skills/partner-tiering
Publisher
mbfinotti
Repository
partnerships-skills
Installs
516
Files
6
License
MIT
Synced
Oct 23, 2026
How to use it

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-tieringInstalls these files
  • SKILL.md
  • evals/evals.json
  • references/distribution-and-cadence.md
  • references/tier-benefits.md
  • references/tier-criteria.md
  • references/worked-examples.md

What this skill tells the agent

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 count (default 3; collapse to 2 below roughly 50 partners) - see references/distribution-and-cadence.md. Then pick the mechanic here, where the choice is actually made:
  • Volume - revenue thresholds only. Near-zero to run: the CRM already holds the number. Buys the weakest ranking, because revenue is a lagging indicator and every non-transacting partner scores zero on it.
  • Engagement - revenue plus certifications, competencies, or retention. About a quarter to stand up, near-zero per cycle afterwards. Buys criteria a partner cannot dispute at appeal, and a rung non-resellers can climb.
  • Points pathway - a published formula scoring several motions at different weights. A standing job: the formula, the per-category minimums, and a recalculation you owe partners every cycle. Buys the finest ranking, and it is the only mechanic that orders a base no single metric ranks correctly.
  • efficiency (best ratio first): engagement > volume > points pathway
  • value (ranking power bought): points pathway > engagement > volume
  • effort (heaviest first): points pathway > engagement > volume
  • Cost gets no line of its own: a mechanic's only cost is the work of running it, so its cost order is its effort order.
  • Default to engagement. Move up to a points pathway when partners transact across several motions - sourced, assisted, managed. No single metric ranks them in an order the channel team will defend.
  • This order starves the points pathway: highest value, highest effort, so it loses every round. Promote it anyway when the program is already losing demotion disputes, or when tier assignments get argued case by case each cycle.
  • Delete volume outright once a material share of the base never transacts. A volume ladder cannot rank those partners at all, and leaving it on the shortlist reinstates the ladder that reads ISV and referral partners as bad partners.
  • Re-rank against the Interview answers:
  • a hard date inside one quarter promotes volume and removes the points pathway from this round
  • a compounding mandate promotes it
  • an effort ceiling with no partner-ops hours removes it
  • Then give non-transacting partner types criteria that fit them, or a separate track.
  1. Define qualification and maintenance criteria before touching benefits - criteria decide who lands where; benefits designed first get promised to a population never modelled. See references/tier-criteria.md.
  2. Backtest the proposed criteria against the existing partner base:
  • Inspect the resulting distribution against the pass threshold below.
  • Adjust thresholds and rerun.

This step produces the modelled tier headcount the next one prices against - a bundle costed before the backtest is a guess about a population nobody has counted.

  1. Price each tier's benefit bundle and check the exchange balances both ways: the tier's revenue covers its bundle cost, and each step up visibly rewards the partner's climb. See references/tier-benefits.md.
  2. Design promotion, demotion, review cadence, measurement window, grace period, grandfathering, and appeals path.
  3. Plan migration and socialization: partner advisory council preview, notice period, migration comms, published decision dates.
  4. Brainstorm and validate per the next section: candidate structures first, then the spec section by section.
  5. Check the pass threshold; iterate criteria, benefits, or tier count until every check holds.
  6. Stop at the approval gate - finalize nothing without the user's explicit approval of the full spec.
  7. If your harness has persistent memory, memorize the approved structure, 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 named vendor structure before citing it - major programs restructured repeatedly across 2022-2026. Otherwise flag vendor examples as possibly stale.

Every ordering in this skill and its reference files - mechanics above, criteria, benefits, cadence and demotion posture in the references - is a default, not a law. It shifts with the program's context and with who executes it.

Re-rank each one against what you already know about this user:

  • a live certification registry drops the engagement mechanic's setup to near-zero and it wins outright
  • per-motion attribution already built in the warehouse turns the points pathway's standing job into a query
  • a channel chief with no political capital for demotions this year changes the cadence order

Say which of the user's facts moved which option, rather than restating the default.

Brainstorming the structure

More from mbfinotti

Use this skill in a project

Open any RiverX project, search the Skills panel for mbfinotti/partnerships-skills/partner-tiering, and install it in one click.

Use this skill