mbfinotti/partnerships-skills已通过检查
SKILL DETAIL
partner-tiering
mbfinotti/partnerships-skills/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.
安装量 · 511查看来源
Installation
npx skills add https://github.com/mbfinotti/partnerships-skills --skill partner-tiering
技能文件
SKILL.md
最近同步 · 2026年10月23日
evals/evals.json›
{
"skill_name": "partner-tiering",
"evals": [
{
"id": 1,
"prompt": "I run channel at Thalloway Systems - we sell a data-residency platform into regulated enterprises. 210 partners: 130 VARs and 80 SIs. Right now everyone gets a flat 22% off list and nothing else, and our biggest SIs keep asking what they get for hitting numbers nobody else hits. Our average sales cycle, from the moment a partner registers an opportunity to closed-won, is 11 months. Build me the tier ladder. I'm thinking Silver at 18%, Gold at 22%, Platinum at 26% off list, plus deal registration protection and priority support at Gold and above. My CFO wants the whole thing costed before I take it to her.",
"expected_output": "A three-tier structure where qualification criteria are defined and backtested against the 210-partner base before any bundle is priced, the deal-registration protection window is sized from the 11-month cycle rather than a stock range, 'priority support' is replaced with a defined SLA, and each step up carries a non-discount economic benefit.",
"files": [],
"expectations": [
"Sizes the deal-registration protection window at 75% or more of the stated 11-month sales cycle - roughly eight months or longer - rather than a stock 60-90 day window.",
"Names the 11-month sales cycle as the input that determines the protection window length.",
"Rejects or replaces 'priority support' as an undefined promise and specifies a concrete response-time SLA in its place.",
"Explains that an undefined support promise becomes an open-ended services commitment that support staffing must honor.",
"Flags that a ladder differentiated mainly by a few discount points plus a badge gives partners no rational reason to climb.",
"Adds at least one non-discount economic benefit at every step up, such as deal-registration uplift, back-end rebate, MDF access, or dedicated partner-manager coverage.",
"Defines qualification criteria for each tier before pricing any benefit bundle.",
"Requires backtesting the proposed criteria against the existing 210-partner base to produce a modelled headcount per tier.",
"Costs each tier's bundle as benefit unit cost multiplied by the backtested tier headcount, and checks it against that tier's modelled revenue contribution.",
"Warns that the base discount sits inside the signed partner agreement, so it is effectively irreversible once granted and needs legal review before it is offered.",
"Stops short of finalizing the structure and asks the user to approve it explicitly."
]
},
{
"id": 2,
"prompt": "Vestrabyte - observability tooling, small team. We have 34 partners today, mostly boutique consultancies. Our CEO wants a five-level partner program modelled on what he saw at his last company: Registered, Bronze, Silver, Gold, Platinum. I've drafted revenue thresholds for each of them. How do I split 34 partners across five levels so that each one actually has somebody in it?",
"expected_output": "A refusal to fill five levels at this base size, a recommendation to collapse to roughly two earned tiers plus an unranked entry rung, and the base-size reasoning behind it.",
"files": [],
"expectations": [
"Refuses to spread 34 partners across five levels and recommends collapsing to roughly two earned tiers.",
"Ties the two-tier recommendation to base size, naming roughly 50 partners as the threshold below which three tiers cannot be filled.",
"Names five or more tiers with overlapping criteria as a documented bloat failure - a ladder nobody inside or outside the company can explain quickly.",
"Allows an unranked registered or entry rung below the earned tiers and distinguishes it from an earned tier.",
"States that three is the default earned-tier count for a larger base.",
"Applies a reachability check to the top tier of roughly 10% or more of partners.",
"Warns against a top tier that would hold only one or two partners at this base size.",
"Asks at least one clarifying question about the current base - partner types, distribution, or revenue concentration - before finalizing the structure.",
"Does not treat the five-level model as workable simply because a larger company ran it.",
"Recommends revisiting the tier count if the base grows, rather than designing now for a headcount the program does not have."
]
},
{
"id": 3,
"prompt": "Korrindale Labs. 180 partners in the program: 71 resellers and 47 agencies that actually transact, plus 62 technology/ISV and advisory partners who never touch a purchase order - they build integrations, they refer deals, they co-market with us. Our current ladder is pure revenue: $250k for Silver, $750k for Gold, $2M for Platinum. Every one of those 62 sits at the bottom rung, and two of them told me last week that the program reads them as second-class partners. What do I do with the revenue thresholds so they can climb?",
"expected_output": "A separate track for the 62 non-transacting partners with its own criteria drawn from integration depth, joint customers, marketplace presence, and CRM-verified introductions, rather than lowered or proxied revenue thresholds.",
"files": [],
"expectations": [
"Recommends a separate track for the non-transacting partners rather than fitted criteria bolted onto the existing revenue ladder.",
"Justifies the separate track by the non-transacting share of the base - 62 of 180, roughly a third - and by their desired benefits barely overlapping the transacting ladder's payouts.",
"Removes the revenue-threshold mechanic for these partners outright rather than lowering, proxying, or discounting the dollar thresholds.",
"States that a revenue ladder cannot rank non-transacting partners at all, not merely that it ranks them poorly.",
"Proposes ISV and technology criteria built from integration depth or maturity, joint customer count, and marketplace listing presence.",
"Proposes referral and advisory criteria built from accepted-introduction volume and influenced pipeline, both verified in the vendor's own CRM.",
"Rejects self-reported pipeline or partner-submitted figures as criteria for the referral and advisory partners.",
"Levels partners within their own track rather than ranking them against partners in other tracks.",
"Notes that revenue is a lagging indicator of partner contribution.",
"Acknowledges the standing cost of a separate track: its own benefit set, cadence, governance, and communications, permanent once launched.",
"Leaves the transacting ladder's own criteria intact rather than rewriting them to accommodate the non-transacting partners."
]
},
{
"id": 4,
"prompt": "I inherited the channel program at Bramworth Analytics and it's a mess. I have one partner-ops analyst. Five tiers - Authorized, Certified, Premier, Elite, Elite Plus - with criteria that overlap so badly I genuinely cannot explain to a partner how Premier differs from Elite. 44% of our 315 partners sit in Elite or above. The thresholds were set in 2021 and have never been touched since. Partners tell me the ladder isn't worth investing in. And our churn spikes every year in the month after we publish review results. One constraint: the benefit bundles are written into signed partner agreements through the end of next fiscal year, so I cannot change what any tier gets until then. Where do I start?",
"expected_output": "An explicit fix order across the symptoms, leading with threshold escalation, striking the benefit-differentiation fix as blocked by signed agreements, mapping the churn spike to cadence and grace, and placing tier-count collapse last while naming the condition that would promote it.",
"files": [],
"expectations": [
"States an explicit fix order across the symptoms rather than addressing them in the order the user listed them.",
"Places criteria-threshold escalation first and justifies it as a spreadsheet change against data the program already holds that lands at the next review.",
"Notes that the crowded top tier and the unexplainable ladder are usually the same problem, and that the threshold fix addresses both.",
"Strikes the benefit-differentiation fix for this cycle and says explicitly that it is struck because signed agreements fix the current bundles, rather than parking it at the bottom of a list.",
"Maps the post-review churn spike to cadence, grace period, and communications - demotion surprise - not to the tier count or the benefit bundles.",
"Prescribes advance written notice, published decision dates, and an appeals path with a named decision owner.",
"Identifies the 44%-in-top-tiers figure as tier compression caused by thresholds not keeping pace with base growth since 2021.",
"States that the efficiency-based ordering ranks tier-count collapse last, and names why: it is a migration, a communications plan, and an agreement amendment.",
"Names the condition that would promote the tier-count fix anyway - adjacent tiers no longer differing on both criteria and benefits, or a migration already happening for another reason.",
"Accounts for the single partner-ops analyst as an effort ceiling when ordering the fixes.",
"Does not recommend collapsing the five tiers as the first action.",
"Applies a top-tier reachability target of roughly 10% of partners when setting the escalated thresholds."
]
},
{
"id": 5,
"prompt": "Quillstone Data. We've drafted new Gold and Platinum criteria and my VP wants proof before we roll them out. The plan is to randomly split our 260 channel partners into two groups: half stay on the current criteria, half get the new ones, run it for two quarters, then compare partner-sourced revenue and PSAT between the groups. Our growth team does this for pricing all the time. Help me design the test - sample size, what to measure, how long to run it.",
"expected_output": "A refusal to randomize tier criteria across the partner base, with the reason grounded in B2B channel tiers being negotiated and agreement-bound, plus a backtest, a pilot cohort, and advisory-council socialization as the substitute.",
"files": [],
"expectations": [
"Declines to run a randomized A/B test of the tier criteria across the partner base.",
"Explains the refusal by the nature of B2B channel tiers - negotiated, relationship-bound, governed by partner agreements - not by sample size or statistical power.",
"Contrasts this with affiliate, creator, or consumer loyalty ladders, which can legitimately be tested across a large base.",
"Proposes backtesting the proposed criteria against the existing 260-partner base as the modelling substitute for the experiment.",
"Proposes a pilot with a defined cohort rather than a randomized split.",
"Recommends socializing the near-final structure through a partner advisory council before any public announcement.",
"Reports the backtest as a modelled headcount per tier and as a percentage of the base.",
"Checks where key partners land in the backtest, including advisory-council members.",
"Does not produce sample sizes, test duration, or significance thresholds for the proposed split.",
"Recommends a notice period and published decision dates ahead of rollout."
]
},
{
"id": 6,
"prompt": "Here's the criteria sheet we drafted for Nyquist Cloud's new three-tier reseller program - tell me if it holds up. Silver: 3 customer logos in the last year plus $50k of partner-reported pipeline. Gold: 10 logos plus $300k reported pipeline plus a signed joint business plan with a committed number. Platinum: 25 logos plus $1M reported pipeline plus the joint business plan plus attendance at our annual partner summit. We picked these deliberately because partners can self-report them in the portal and we don't have to touch the CRM.",
"expected_output": "A rejection of every self-reported and logo-count criterion, replaced with criteria the program records itself - sourced revenue, certified headcount, a retention gate at the top - each with a measurement window and data source.",
"files": [],
"expectations": [
"Rejects partner-reported pipeline as a criterion outright rather than retaining it at a lower weight.",
"Rejects logo counts as a vanity metric behind documented pay-to-play failures.",
"Rejects the joint business plan's committed number as a self-reported, gameable input.",
"States the test explicitly: whether the partner can move the number without creating real value, or whether the criterion survives a disputed demotion.",
"Replaces the sheet with criteria the program itself records, such as sourced revenue from the vendor's CRM and certified headcount from a certification registry.",
"Recommends a retention or gross-revenue-retention gate at the top tier.",
"Admits deal registrations only when vendor-accepted, and only as an input to sourced revenue rather than as a criterion of its own.",
"Attaches a measurement window and a named data source to every threshold it proposes.",
"Derives threshold levels from what the program's already-successful partners actually do, rather than from aspiration.",
"Does not accept 'easy to self-report in the portal' as a reason to keep a criterion.",
"Drops summit attendance as a qualification criterion, or replaces it with an auditable competency or certification requirement."
]
},
{
"id": 7,
"prompt": "Feldmarsh Networks. One of our resellers closed a single $1.4M deal in Q2 of last year, cleared our calendar-year revenue test, hit Platinum - and has done $60k in the fifteen months since. Still Platinum, still on the 27% discount, still has a dedicated partner manager. Three other partners are in exactly the same position. We recalculate once a year in January off the prior calendar year's numbers. Base is 120 partners and most of them transact every month. Fix the measurement so this stops happening.",
"expected_output": "A rolling trailing-4-quarter window replacing the calendar-year test, a recalculation cadence moved off annual with monthly considered given the continuous transaction pattern, and a graced, noticed demotion path for the four affected partners.",
"files": [],
"expectations": [
"Replaces the calendar-year measurement with a rolling trailing-12-month or trailing-4-quarter window.",
"Names the failure the rolling window prevents: one spike period buying lasting status, sometimes called tier tourism.",
"Treats the measurement window and the recalculation moment as two separate decisions.",
"Moves the recalculation off annual and identifies annual as the cadence that lets partners coast for eleven months.",
"Recommends a cadence at least as frequent as quarterly.",
"Considers monthly recalculation and ties it to this base transacting continuously, rather than dismissing it as too much work.",
"States the recurring effort the chosen cadence commits to - a recalculation, a communications wave, an appeals queue - rather than presenting it as free.",
"Plans a grace period before the four affected partners actually lose status.",
"Warns that demotion is the highest-risk moment in the program and raises switching intent, worst for the largest drops.",
"Requires written notice and published decision dates before any status change takes effect.",
"Recommends letting old achievements age out of the rolling window rather than accumulating indefinitely."
]
},
{
"id": 8,
"prompt": "Ardenhold Software. The new tier structure is signed off internally. When we backtest it against our 410 partners, 96 of them come out lower than they are today, including 11 that drop two levels at once. Four of the 96 sit on our partner advisory council. We announce at our partner conference on 3 March and want everyone moved onto the new structure by 1 April. Write me the migration plan.",
"expected_output": "A phased multi-quarter migration with the advisory-council preview moved ahead of the public announcement, an explicit grandfathering choice, a grace period, differentiated handling of the two-level drops, and an appeals path.",
"files": [],
"expectations": [
"Moves the advisory-council preview ahead of the public announcement rather than briefing the council at the conference.",
"Rejects the four-week announcement-to-cutover timeline and proposes a phased, multi-quarter transition with published milestones.",
"Presents both grandfathering options - setting each partner to the best status earned during the review period, or publishing an explicit no-loss date - as a choice rather than asserting one default.",
"States that the two grandfathering options cost the same effort because both fall out of the backtest already run.",
"Warns that a single no-loss date concentrates all 96 demotions onto one day, while best-status-earned lets them land one partner at a time as each window expires.",
"Flags the 11 two-level drops as the highest-risk cases and handles them separately from single-level drops.",
"Cites that status demotion raises negative emotion, threatens identity, and increases switching intent, worst for the largest drops.",
"Specifies a grace period before demotions take effect, with one review cycle - roughly 90 days - as the default.",
"Handles the four advisory-council members explicitly, either by reworking thresholds or by targeted socialization before announcement.",
"Defines an appeals path with a named decision owner and published decision dates.",
"Requires written notice to every affected partner before their status changes.",
"Includes post-demotion churn measured against baseline partner churn as a KPI to track after migration."
]
},
{
"id": 9,
"prompt": "Marchetti Grid, 140 channel partners. The board committed publicly to a new partner structure going live by the end of this quarter - that's 9 weeks away, and the date is already out there. My partner-ops team is one person at 50% allocation, and there's no analytics support available before next fiscal year. Our partners transact across sourced, assisted and managed motions and honestly I'd love something that scores all three properly. What mechanic should the new tiers run on?",
"expected_output": "A recommendation against a points pathway this cycle, naming the deadline and the capacity ceiling as the two facts that remove it, with volume or engagement chosen instead and the condition for revisiting the pathway later.",
"files": [],
"expectations": [
"Does not recommend a points pathway for this round.",
"Names the 9-week public deadline as the fact that removes the points pathway from this round.",
"Names the half-a-person partner-ops capacity and absent analytics support as a second, independent reason the points pathway is out.",
"States explicitly which of the user's own facts moved which option, rather than restating a generic default ranking.",
"Recommends either volume or engagement as the mechanic for this cycle, with a stated reason.",
"States that engagement is the default mechanic absent constraints.",
"Expresses the mechanics' relative effort in orders of magnitude - near-zero, about a quarter to stand up, a standing job - rather than in currency amounts.",
"Acknowledges that the points pathway buys the strongest ranking power and that it loses here on effort, not on value.",
"Names the condition under which the points pathway should be revisited in a later cycle, such as multi-motion partners combined with partner-ops capacity, disputed tier assignments, or a compounding mandate.",
"Warns that a volume-only ladder scores every non-transacting partner at zero, and checks whether this base contains such partners."
]
},
{
"id": 10,
"prompt": "Our CMO went to an analyst day and came back with a 3x3 grid - current performance on one axis, future potential on the other. She wants our partner program rebuilt around it: nine boxes, nine partner levels, and every partner gets told which box they're in so they know exactly where they stand. We have 230 partners. I'm supposed to have criteria drafted for all nine boxes by Friday. Can you write them?",
"expected_output": "A refusal to publish the nine-box grid as the partner-facing ladder, with the grid retained as an internal overlay, roughly three earned tiers recommended instead, and an alternative deliverable offered for the Friday deadline.",
"files": [],
"expectations": [
"Refuses to publish the nine-box grid as the partner-facing tier ladder.",
"States that a current-performance by future-potential grid is an internal segmentation overlay on a public tier ladder, never a replacement for it.",
"Rejects telling partners which box they are in.",
"Identifies future potential as a vendor judgment a partner cannot compute or contest, failing the dispute test for a qualification criterion.",
"Names nine levels as tier bloat, well past the point where a ladder becomes unexplainable inside or outside the company.",
"Recommends roughly three earned tiers for a 230-partner base.",
"Keeps the grid in the design as an internal sanity-check on where key partners would land.",
"Proposes partner-facing, repeatable tier names rather than box numbers or 'Tier 2'-style labels.",
"Requires every published criterion to carry a measurement window and a data source.",
"Does not produce criteria for all nine boxes as asked.",
"Offers a specific alternative deliverable the user can bring to the Friday deadline instead of only refusing."
]
},
{
"id": 11,
"prompt": "Pelloran Systems, budget review next week. We allocate 5% of channel revenue to MDF across our three partner tiers, weighted to the top. Last year $1.9M was allocated and $820k was actually claimed. Nobody owns the claims process - it's been unassigned since our partner marketing manager left in January. Meanwhile our top 14 partners out of 190 drive most of our channel revenue and they keep asking for a named contact and hands-on technical training, which I've been telling them we can't afford. Finance wants me to cut something. What goes?",
"expected_output": "MDF removed outright because no one owns the claims process, with the partner-manager coverage and delivered training funded at the top tier instead, justified by that cohort's revenue contribution rather than by an efficiency ratio.",
"files": [],
"expectations": [
"Recommends removing MDF from the benefit set outright rather than reallocating or trimming it.",
"Ties that recommendation to nobody owning the claims process, not to the size of the budget line.",
"Notes that roughly $820k claimed against $1.9M allocated leaves over half unclaimed, consistent with the commonly cited 40-60% unclaimed range.",
"Recommends funding dedicated partner-manager coverage and hands-on training for the top tier rather than cutting them.",
"Justifies that by the top cohort's revenue contribution covering the cost, and explicitly rejects a pure efficiency ratio as the right test at the top tier.",
"Observes that 14 of 190 partners producing most of channel revenue matches the expected concentration pattern of 10-20% of partners driving 70-80% of revenue.",
"Names dedicated partner-manager coverage and delivered training as exactly the benefits an efficiency ordering systematically starves.",
"Proposes at least one near-zero-cost benefit such as directory or marketplace listing placement, or internal-use (NFR) licenses.",
"States that an unfunded benefit lands as a liability and erodes trust in the whole ladder.",
"Assigns a named owner to any retained benefit that requires a recurring process to run.",
"Does not present cutting the partner-manager coverage or the training as the answer to the finance request."
]
}
],
"trigger_queries": [
{ "query": "Redesign the partner tier structure for our existing channel program", "should_trigger": true },
{ "query": "our top tier is overcrowded and demotion has never once been enforced", "should_trigger": true },
{ "query": "what should qualify a reseller for gold status", "should_trigger": true },
{ "query": "we have silver and gold and nobody here can tell me the difference", "should_trigger": true },
{ "query": "everyone gets a flat 20% discount and our best partners keep asking what more they get", "should_trigger": true },
{ "query": "how many partner levels should we have with 240 resellers", "should_trigger": true },
{ "query": "our MSPs stall at the entry level and never advance", "should_trigger": true },
{ "query": "should we demote partners who drop below their threshold", "should_trigger": true },
{ "query": "help me write the maintenance requirements for each partner level", "should_trigger": true },
{ "query": "our 25 ISV partners cannot qualify for anything because they never resell", "should_trigger": true },
{ "query": "design a points formula so partners can see exactly how they earn platinum", "should_trigger": true },
{ "query": "tier compression - 38% of our partners sit in the top band", "should_trigger": true },
{ "query": "we want to add a fourth partner tier, is that a good idea", "should_trigger": true },
{ "query": "what benefits should separate our mid partner level from the top one", "should_trigger": true },
{ "query": "how long should a partner keep their status after one bad quarter", "should_trigger": true },
{ "query": "put together the qualification thresholds for our new reseller ladder", "should_trigger": true },
{ "query": "our partner badges mean nothing, everyone has the top one", "should_trigger": true },
{ "query": "we're moving 300 agency partners onto a new structure, what do we do about the ones who lose status", "should_trigger": true },
{ "query": "should partner status reviews be quarterly or annual", "should_trigger": true },
{ "query": "what's a fair grace period before a partner loses their level", "should_trigger": true },
{ "query": "our channel chief wants five tiers and I think that's too many", "should_trigger": true },
{ "query": "we need a way to rank partners who transact across sourced, assisted and managed deals", "should_trigger": true },
{ "query": "how do we stop one big quarter from buying a partner a whole year of gold status", "should_trigger": true },
{ "query": "which of our requirements can a partner actually argue with when we downgrade them", "should_trigger": true },
{ "query": "plan the migration onto our new partner ladder", "should_trigger": true },
{ "query": "our deal registration uplift is identical at every level and partners don't care", "should_trigger": true },
{ "query": "we need an entry rung for partners who just signed but have not sold anything yet", "should_trigger": true },
{ "query": "rework the benefit bundles across our reseller levels so the steps actually mean something", "should_trigger": true },
{ "query": "how do I decide the revenue threshold for each partner band", "should_trigger": true },
{ "query": "our program has bands but nobody can explain how you move between them", "should_trigger": true },
{ "query": "should we score partners on certifications or just on revenue", "should_trigger": true },
{ "query": "what does a healthy distribution across partner levels look like", "should_trigger": true },
{ "query": "the partners with our highest badge produce the least revenue", "should_trigger": true },
{ "query": "can you help me restructure the reseller ladder before our fiscal year starts", "should_trigger": true },
{ "query": "we want to gate dedicated partner manager coverage - who should get one", "should_trigger": true },
{ "query": "MDF is allocated by partner band but half of it goes unclaimed every year", "should_trigger": true },
{ "query": "a partner is appealing their downgrade and we have no process for that", "should_trigger": true },
{ "query": "how do we set requirements our referral partners can actually meet", "should_trigger": true },
{ "query": "define what partners have to do each year to keep their status", "should_trigger": true },
{ "query": "we're collapsing our partner levels from five to three, what breaks", "should_trigger": true },
{ "query": "backtest these thresholds against our current 190 partners", "should_trigger": true },
{ "query": "our agency partners and our resellers are judged on the same numbers and it isn't working", "should_trigger": true },
{ "query": "what should the top band of a channel program require", "should_trigger": true },
{ "query": "give me a spec I can hand to partner ops for the new partner structure", "should_trigger": true },
{ "query": "partners complain that the jump from silver to gold isn't worth the investment", "should_trigger": true },
{ "query": "we never review partner status and it shows", "should_trigger": true },
{ "query": "how do we stop expired certifications from counting toward partner status forever", "should_trigger": true },
{ "query": "the requirements to reach our top partner level haven't changed since 2021", "should_trigger": true },
{ "query": "we're rebuilding the reseller ladder and finance wants to know what each band costs us", "should_trigger": true },
{ "query": "churn spikes every time we publish the partner review results", "should_trigger": true },
{ "query": "our partner levels are just badges with no economics behind them", "should_trigger": true },
{ "query": "help me pick between revenue thresholds and a scoring model for partner levels", "should_trigger": true },
{ "query": "how do affiliate status ladders differ from B2B channel partner ones", "should_trigger": true },
{ "query": "we have no partner program at all, help me build one from scratch", "should_trigger": false },
{ "query": "are we even ready to launch a channel?", "should_trigger": false },
{ "query": "design the partner value proposition and governance for a brand new channel program", "should_trigger": false },
{ "query": "build a scorecard to review one underperforming reseller", "should_trigger": false },
{ "query": "structure the QBR agenda for our biggest partner", "should_trigger": false },
{ "query": "this MSP missed target two quarters running, what's the corrective action path", "should_trigger": false },
{ "query": "should our affiliates get 20% or 30% commission", "should_trigger": false },
{ "query": "design the commission ladder for affiliates - 10/15/20% at revenue milestones", "should_trigger": false },
{ "query": "should affiliate commissions be lifetime or capped at 12 months", "should_trigger": false },
{ "query": "how big should our refer-a-friend reward be", "should_trigger": false },
{ "query": "give-X-get-Y - what should each side actually get", "should_trigger": false },
{ "query": "model the P&L for this one MSP relationship", "should_trigger": false },
{ "query": "is this reseller worth the margin we're giving up", "should_trigger": false },
{ "query": "rank these five candidate alliance partners by expected value", "should_trigger": false },
{ "query": "which of these three integration partners deserves our engineering time", "should_trigger": false },
{ "query": "write our deal registration approval SLA for direct versus partner sellers", "should_trigger": false },
{ "query": "how should we split deal credit between partner-sourced and partner-influenced", "should_trigger": false },
{ "query": "two partners are claiming the same account, who wins", "should_trigger": false },
{ "query": "our direct reps are poaching partner deals, write the rules of engagement", "should_trigger": false },
{ "query": "sequence the certification curriculum for newly signed partners", "should_trigger": false },
{ "query": "what training does a partner need before their first deal", "should_trigger": false },
{ "query": "is an AWS marketplace listing worth it for us", "should_trigger": false },
{ "query": "should we list on the Salesforce AppExchange or not", "should_trigger": false },
{ "query": "which partner category should we launch next, SIs or MSPs", "should_trigger": false },
{ "query": "map our channel coverage gaps and account overlap", "should_trigger": false },
{ "query": "plan a joint webinar and launch sequence with our integration partner", "should_trigger": false },
{ "query": "write the co-marketing plan for our better-together story", "should_trigger": false },
{ "query": "shortlist creators for our spring campaign", "should_trigger": false },
{ "query": "write the DM pitching this YouTuber a collab", "should_trigger": false },
{ "query": "what usage rights should I ask for from this creator", "should_trigger": false },
{ "query": "draft the campaign brief for the creator we just signed", "should_trigger": false },
{ "query": "how do I measure this creator campaign before it launches", "should_trigger": false },
{ "query": "audit our affiliate payout run before we disburse the money", "should_trigger": false },
{ "query": "this affiliate's conversion rate looks impossible, is it fraud", "should_trigger": false },
{ "query": "does this sponsored post's disclosure meet FTC rules", "should_trigger": false },
{ "query": "draft the terms affiliates accept when they join the program", "should_trigger": false },
{ "query": "write the welcome email series for newly approved affiliates", "should_trigger": false },
{ "query": "draft outreach to recruit coupon and cashback sites into our program", "should_trigger": false },
{ "query": "what metrics belong on our affiliate program dashboard", "should_trigger": false },
{ "query": "customers are creating fake accounts to farm referral rewards", "should_trigger": false },
{ "query": "how do I break into channel partnerships from a sales role", "should_trigger": false },
{ "query": "write the job posting for a partner manager", "should_trigger": false },
{ "query": "design our interview loop for an alliances lead", "should_trigger": false },
{ "query": "which partnerships skill should I be using for this", "should_trigger": false },
{ "query": "design our SaaS pricing tiers - starter, pro, enterprise", "should_trigger": false },
{ "query": "what should we charge for the enterprise plan", "should_trigger": false },
{ "query": "define our support ticket priority tiers P1 through P4", "should_trigger": false },
{ "query": "level our engineering job ladder from L3 to L7", "should_trigger": false },
{ "query": "tier our inbound leads A/B/C for SDR routing", "should_trigger": false },
{ "query": "set up S3 lifecycle rules to move objects into colder storage tiers", "should_trigger": false },
{ "query": "which loyalty app should I install on our Shopify store", "should_trigger": false },
{ "query": "build a customer health score for our CS team", "should_trigger": false },
{ "query": "segment our enterprise accounts into A/B/C for coverage planning", "should_trigger": false }
]
}
references/distribution-and-cadence.md›
# Distribution, Backtesting, and Cadence
How many tiers, how partners spread across them, and how movement between them is governed.
## Choosing the tier count
No efficiency ranking here, deliberately: tier count is set by the size and heterogeneity of the base, not by what each count returns per unit of effort. Ordering 2, 3 and 4 against each other would be false precision, because the right count moves entirely with the base and a wrong count is not an inefficient choice but an unfillable one.
- Default to 3 - the "good, better, best" norm across 98% of top IT partner programs (Forrester analyst assertion, not raw survey data).
- Collapse to 2 below roughly 50 partners; a small base cannot fill three meaningful cohorts.
- Add a 4th only when the base is large and genuinely heterogeneous. Five or more tiers "with overlapping criteria... that no one inside or outside the company can explain quickly" is the documented bloat failure.
- Consider an unranked "registered" entry rung below the first earned tier - it absorbs new signups without diluting the earned ladder.
## Backtesting against the current base
1. Pull 4-8 quarters of real partner data: revenue by motion, certifications, retention, registered deals.
2. Apply the proposed criteria; count who lands in each tier.
3. Compare the resulting shape to the targets below; escalate or relax thresholds; rerun until it fits.
4. Check key partners by name: where do the advisory-council members land? A design that demotes half the council needs either rework or heavy socialization before announcement.
## Target distribution shape
- Aim for a pyramid: a broad base, a substantial middle, a selective top.
- Keep the top tier reachable by roughly >=10% of partners (a PRM-vendor rule of thumb, not an empirical dataset) - but not crowded. Compression at the top is the most common sign criteria haven't kept pace with ecosystem growth.
- Avoid the documented most-common mistake: tiers "too easy to achieve at the bottom and too hard at the top".
- Avoid cliff effects: a partner narrowly missing a threshold should not face a dramatic benefit drop - smooth the step or add an intermediate criterion.
- Expect revenue concentration of 10-20% of partners producing 70-80% of channel revenue (consultancy rule of thumb); a backtest wildly off that pattern deserves a data check before a design change.
## Review cadence and measurement windows
Three cadences compete for one job: keeping status current without making it feel unstable.
- efficiency (best ratio first): `quarterly > annual > monthly`
- value (status that reads as current and earned): `monthly > quarterly > annual`
- effort (heaviest first): `monthly > quarterly > annual`
- **Quarterly** (default rung): four scheduled runs a year track a base that moves, and each is a run rather than a standing job.
- **Annual**: near-zero effort, and lets partners coast for eleven months.
- **Monthly**: a standing job - a recalculation, a comms wave and an appeals queue every month - and it spends goodwill besides, since status that can move monthly feels unstable and feeds anxiety and churn (practitioner convention, not a study). At least one major program runs it anyway, on a fixed day.
- Move up to monthly when the mechanic's inputs already compute themselves and the base transacts continuously. Drop to annual only when partner agreements or the fiscal calendar force it, and expect coasting.
- This order starves monthly, the most responsive cadence and the most expensive to run. Promote it anyway for a high-volume transactional base, where a quarter of stale status is a quarter of misapplied discounts.
- Use a rolling trailing-4-quarter window to prevent tier tourism (one spike quarter buying lasting status).
- Publish decision dates in advance - partners should never discover a review happened by losing a badge.
## Promotion, demotion, and grace
- Promote at recalculation, effective immediately; delaying a promotion only punishes momentum.
- Enforce demotion. Never demoting anyone makes status meaningless and quietly inflates every tier.
- Treat demotion as the highest-risk moment in the program. Peer-reviewed loyalty research finds status demotion heightens negative emotions, threatens identity, and raises switching intent - worst for top-to-bottom drops. The findings generalize to any hierarchical status system.
Three documented postures exist for the same goal:
- one vendor's public terms demote automatically one tier at the annual audit
- another removes the badge at the next quarterly update with no stated grace
- the practitioner convention grants a cycle of grace
- efficiency (best ratio first): `one review cycle of grace > automatic single-tier demotion at the audit > badge removed at the next update, no grace`
- value (discipline restored): `automatic single-tier demotion == badge removed with no grace > one cycle of grace`
- effort (heaviest first): `one cycle of grace > automatic single-tier demotion == badge removed with no grace`
- Both ties are one fact seen twice: the two harsh postures are a single automated status change at the review with a single notification, so they restore the same discipline at the same cost and differ only in how far a partner falls. Grace splits from them on both axes - it buys nearly all the discipline while spending far less goodwill at the program's highest-risk moment, and it costs a warned state to track, a second comms wave, and the appeals traffic in between.
- Default to one review cycle (~90 days) of grace. Move to the harsher end when the top tier is already compressed and grace would postpone the reset another full year; the trade is goodwill for discipline, and reversing it later means telling partners something other than what their agreement says.
- Pre-communicated, criteria-backed demotion can open a constructive conversation. Cody Jones of Zapier: "Nothing grabs their attention quite like a tier change." A surprise demotion just churns.
## Grandfathering, migration, and appeals
- On migration, choose between the two documented vendor practices: set each partner to the best status they earned during the review period, or publish an explicit no-loss date. Efficiency: `best status earned > published no-loss date`, with effort `==` - both fall out of the backtest already run, so neither adds work. They split on value: best-status-earned lets demotions land one partner at a time as each window expires, while a single no-loss date concentrates every demotion in the program's history onto one day.
- Run structural overhauls as phased multi-quarter transitions with published milestones; the largest 2026 redesigns all did.
- Give written notice before any status change and an appeals path with a named decision owner and published decision dates.
## Preventing tier inflation
- Revisit thresholds at least annually; a growing base under static thresholds compresses the top by default.
- Expire stale inputs: one vendor stops counting expired certifications toward tier points immediately.
- Keep windows rolling so old achievements age out instead of accumulating forever.
references/tier-benefits.md›
# Tier Benefit Design
What each tier unlocks, what it really costs, and how to price the bundle so the exchange balances both ways.
## The benefit menu, ranked by pull per unit of vendor effort
Rows run in efficiency order, best ratio first. Reliability warning: most tier-by-tier percentages below are vendor marketing claims or practitioner ranges, not audited benchmarks. Flags are per row.
- efficiency (best ratio first): `directory placement > NFR licenses > deal-registration uplift > back-end rebates > training credits > MDF > base discount > support SLA > dedicated PAM`
- value (pull that actually makes a partner climb): `deal-registration uplift > directory placement > base discount > dedicated PAM > MDF > back-end rebates > NFR licenses == training credits > support SLA`
- effort (heaviest first): `dedicated PAM > MDF > deal-registration uplift > support SLA > training credits > back-end rebates > base discount > directory placement == NFR licenses`
- compliance cost (heaviest first): `base discount > deal-registration uplift > support SLA > MDF`; every other benefit here is withdrawable at the next review with notice and carries no contractual exposure.
The two ties are real, not a refusal to decide. On value, NFR licenses and training credits both buy the partner internal capability their customer never sees, so a partner weighs them the way it weighs any free internal tooling. On effort, directory placement and NFR licenses are both a configuration change against inventory you already own - a listing slot, a software seat - and neither puts a recurring obligation on anyone's calendar.
| Benefit | Typical differential | Real cost to the vendor | Effort to run | Reliability |
| ---------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Directory / marketplace placement | Better listing position by tier | Near zero | An hour - a field on the listing | Zapier found partners "prioritize exposure more than anything else" (Cody Jones) |
| NFR / internal-use licenses | Free internal-use product | Near-zero COGS for software | An hour - a seat you already own | Named vendor practice (Red Hat, VMware by Broadcom's BAP program): both tie NFR quantity and duration to partner tier and use case, though neither publishes the per-tier quantities as a benchmark |
| Deal-registration uplift | +5-15 additional margin points on registered deals; protection window sized at ≥75% of the average sales cycle, not from a stock range - the commonly quoted 60-90 days fits a ~4-month cycle and is roughly half what a 9-12 month enterprise cycle needs | Extra margin on registered deals only, not on every dollar | A standing job - enforcement against your own direct sales, and the political capital that takes | Practitioner range (PRM/channel-consultancy sources); the 75% sizing rule is owned by `mbfinotti/partnerships-skills@partner-channel-conflict` |
| Back-end rebates | 1-5%, tier-scaled | Rebate accrual against partner revenue, paid in arrears on revenue already booked | A quarterly accrual with finance | Practitioner range |
| Training and certification credits | Training subscriptions at top tiers | Real delivery cost per seat | A quarter of delivery capacity to stand up | One vendor allocated $60M of an $80M program investment to top-designation training (vendor claim) |
| MDF / co-op funds | 2-6% of channel revenue, weighted to top tiers | Budget line - but 40-60% typically goes unclaimed | A standing job - claims process, proof-of-performance review, partner-marketing bandwidth | Recurring industry figure |
| Base margin / discount | Entry ~15% off list rising to ~25%+ at top tiers | Margin surrendered on every partner-sold dollar | Near-zero to grant, effectively irreversible to withdraw | Industry range from pricing-content sources; anecdotal |
| Support SLA | Priority routing at upper tiers | Support staffing to honor it; an undefined "priority support" promise becomes an open-ended services commitment - a documented failure | A quarter to staff, then a queue someone owns forever | Documented failure mode |
| Dedicated PAM coverage | Top tiers only | Headcount divided by covered partners - often the largest per-partner cost | A standing job, and a hiring decision before it | No published partners-per-PAM ratio exists; CompTIA's Carolyn April frames the benefit as tier-gated, not headcount-sized - "it's only when [partners] reach the higher rung [of the tiers] do they have a dedicated PAM" (TechTarget) |
What the compliance line means in practice:
- **Base discount**: sits inside the signed agreement, so withdrawing it reopens every contract and needs legal before it is offered, not after.
- **Deal-registration uplift**: a promise enforceable against your own direct sales, and its breaches escalate - deal-registration enforcement failures, not thin margins, are cited as the largest single source of partner-program churn.
- **Support SLA**: a services commitment support staffing must honor. An undefined one is the same commitment with no boundary.
- **MDF**: auditable spend with proof-of-performance rules finance and tax will ask about.
Default bundle: directory placement and NFR licenses at every earned tier, the deal-registration uplift at the first tier a partner has to earn. Move up a rung when the tier's modelled revenue covers the next benefit at its backtested headcount and the step above still reads as visibly better than the step below. The base discount is a floor to clear rather than a rung to climb - partners clearing less than roughly 15% gross margin on a vendor's products tend to deprioritize that vendor (analyst commentary; treat as plausible, not proven).
This order starves dedicated PAM coverage and delivered training: the two heaviest lines, and the two that the partners producing most of the revenue actually want. An efficiency order never buys them. Buy them at the top tier anyway - that cohort produces 70-80% of channel revenue, so the ratio is the wrong test there, and the right one is whether the cohort's contribution covers the headcount.
Delete MDF from the menu outright when nobody owns a claims process. An allocated fund running 40-60% unclaimed is the documented failure, and a benefit parked at the bottom of a menu still finds its way into the announcement.
## Pricing the bundle
1. Compute each tier's bundle cost: sum of (benefit unit cost x modelled tier headcount from the backtest).
2. Compare against the tier's modelled revenue contribution - the tier must be self-funding.
3. Check the partner's side of the exchange too. Forecastable's framing: a tier "is a contract or it is nothing"; a ladder with steep requirements and thin rewards gives partners no reason to climb.
4. Allocate by the efficiency order above rather than by generosity: its top is table stakes at every earned tier, its middle splits mid and top, and the heaviest lines - PAM, delivered training, the defined SLA - stay top-only.
5. Fund every promise. An unfunded benefit - an SLA without staffing, MDF without a claims process - lands as a liability and erodes trust in the whole ladder.
## Negative example: the badge ladder
A structure that fails the differential check:
| | Silver | Gold |
| -------- | ------------------------------ | ------------------------------ |
| Discount | 18% | 20% |
| Badge | Standard | Nicer |
| Support | "Priority support" (undefined) | "Priority support" (undefined) |
The documented verdict on exactly this shape: "If the primary difference between Silver and Gold is a 2% better discount and a nicer badge... most partners will rationally conclude that the additional investment... isn't worth making."
The fix keeps the same tiers but makes the step economically visible. Gold adds, each with a modelled cost and a funding owner:
- a deal-registration uplift of +10 margin points with a protection window sized to this program's own sales cycle (90 days against a 110-day average, so 82%)
- a defined 8-business-hour support SLA
- access to the MDF pool
references/tier-criteria.md›
# Tier Qualification Criteria
What earns a tier, over what window, and how to keep it undisputable. Decide criteria before benefits - criteria fix the population each benefit bundle gets promised to.
## The criteria menu, ranked by ranking power per unit of effort
Rows run in efficiency order, best ratio first. Effort here is data availability and the audit or adjudication each criterion commits you to - never a budget.
- efficiency (best ratio first): `sourced revenue > certified headcount > managed revenue/GRR > competencies > influenced revenue > CSAT`
- value (ranking power that survives a dispute): `competencies > managed revenue/GRR > sourced revenue > CSAT > certified headcount > influenced revenue`
- effort (heaviest first): `competencies > CSAT > influenced revenue > managed revenue/GRR > certified headcount > sourced revenue`
- compliance cost (heaviest first): `CSAT > competencies > influenced revenue`; the other three run on records the program already keeps and carry none.
| Criterion | What it measures | Gameability | Effort to run | Notes |
| --------------------------------- | ----------------------------------------------- | ------------------------------------- | -------------------------------------------------------------- | ------------------------------------------------------------------------------------------ |
| Sourced revenue | Deals the partner originated | Low when verified in the vendor's CRM | Near-zero - the CRM already holds it | Production points systems weight sourced above assisted and managed |
| Certified headcount | Individuals holding current certifications | Low - auditable | Near-zero once a certification registry exists | Expire stale certs: one vendor stops counting expired certifications immediately |
| Managed revenue / retention (GRR) | Health of the partner's installed book | Low | About a week - retention has to be computed per partner book | The strongest top-tier gate - one major program requires >=80% GRR for its top earned tier |
| Competencies / specializations | Validated, audited delivery depth | Low - vendor-audited | A standing job - someone audits delivery evidence every cycle | The direction of travel: one vendor cut ~170 badges to 28 competencies in 2026 |
| Influenced / co-sold revenue | Deals the partner touched but didn't originate | Medium - attribution disputes | A standing job - every contested touch is adjudicated | Require a verifiable touch, not a claim |
| CSAT / customer outcomes | Measured satisfaction of partner-delivered work | Medium - respondent selection | A standing job - a survey program you run, not one you receive | Gate on vendor-run surveys, never partner-collected ones |
Compliance cost, concretely:
- **CSAT**: surveys reach the partner's customers, so consent and data-handling review comes before the first send, and a survey you must stop running is a criterion you must stop demoting on.
- **Competencies**: audits need the partner's project evidence under NDA.
- **Influenced revenue**: attribution rules have to survive the appeals path with legal reading them.
Default: open every design with sourced revenue plus certified headcount - both come from records the program already holds, so they cost a query. Add the GRR gate at the top tier as soon as retention exists per partner book.
Deleted, not demoted: raw self-reported pipeline and joint-business-plan contribution. They are the documented gaming vector, and left on the menu at low priority they reappear as a criterion in the first draft. Vendor-accepted deal registrations survive - as a leading indicator inside sourced revenue, never as a criterion of their own.
This order starves competencies: the highest ranking power on the list and the heaviest to run, so efficiency never picks it. Promote it anyway when the top tier's job is delivery quality rather than volume, or when partners already dispute their placement - an audited competency is the one criterion a partner cannot argue with.
## Points models
- Blend criteria into a weighted points pathway (the Alexander Group's third mechanic) when any single metric misranks partners.
- Set per-category minimums, not just a total. Microsoft's Partner Capability Score requires 70/100 with points in every category, so skilling alone - worth 40 of the 100 - cannot carry a designation.
- Publish the point formula; partners optimize what they can compute. HubSpot's ladder (Gold 325 → Platinum 925 → Diamond 3,100 → Elite 9,000 points, earned per $100 MRR across sourced/assisted/managed motions) is the most concretely documented production example.
- Weight motions unequally: sourced revenue carries more points than assisted or managed in that same production system, because origination is the scarcer behavior.
## Measurement windows
- Default to a rolling trailing-12-month or trailing-4-quarter window - rolling windows are the recommended guard against "tier tourism", where one big quarter buys a year of status.
- Match window length to the sales cycle: enterprise-cycle partners need multi-year evidence windows; transactional partners can be judged on 12 months.
- State the recalculation moment explicitly. One program recalculates monthly on a fixed day; most review quarterly or annually. The window and the recalculation moment are separate decisions.
## Gameability - the dispute test
Criteria double as the program's defense when a partner contests a demotion. Maureen Little, VP of Technology Partnerships at Okta: "They have to be things you cannot dispute."
- Reject logo counts for the same reason self-reported pipeline is already off the menu: both are the vanity metric behind the documented pay-to-play failures.
- Derive thresholds from evidence, not aspiration. Cody Jones of Zapier: "Go work with your most successful partners. Figure out what they do... Create those as the requirements for ascending tiers."
- Run every candidate criterion through one question: can the partner move this number without creating real value? If yes, drop or verify it.
## Criteria for non-transacting partner types
Jay McBain's core critique: most partners entering ecosystems today - tech/ISV, referral, advisory - never resell, so a revenue ladder reads them as "bad partners". Two ways to fix that, and they are not equally cheap:
- efficiency: `fitted criteria on the existing ladder > a separate track per motion`
- value (contribution the structure can actually recognize): `separate track > fitted criteria`
- effort (heaviest first): `separate track > fitted criteria`. Fitted criteria are a threshold table for one partner type, roughly a week's work inside a structure that already exists. A separate track is a second structure with its own benefits, cadence, governance and comms - a quarter at least, and permanent afterwards.
- Default to fitted criteria. Move to a separate track when non-transacting partners pass roughly a quarter of the base, or when the benefits they want (co-marketing, directory placement, integration support) barely overlap with what the transacting ladder pays out - at that point one ladder is two programs sharing a table.
- **ISV / technology partners**: integration depth and maturity, count of joint customers, marketplace listing presence - the criteria one data-platform vendor uses for its product-partner track.
- **Referral / advisory partners**: accepted-introduction volume and influenced pipeline, both verified in the vendor's CRM, never self-reported.
- **Track split**: build / sell / service is the documented pattern; level partners within their track rather than against each other.
references/worked-examples.md›
# Worked Examples and the B2C Contrast
Real vendor structures decomposed against this skill's design variables, one fully worked structure, and the B2C affiliate/creator/loyalty contrast.
Reliability warning: tier-by-tier discounts and some qualification counts below are vendor marketing claims or third-party write-ups; exact schedules sit behind partner portals. Verify against the vendor's current page before quoting - several of these programs changed shape more than once in 2022-2026.
## Vendor structures decomposed (2023-2026)
| Vendor | Mechanic | Tiers | Signature criteria | Cadence | Design lesson |
| --------------------------- | ------------------------------ | ------------------------------------------------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------ |
| HubSpot | Points pathway | Gold → Platinum → Diamond → Elite (above an untiered entry) | 325 / 925 / 3,100 / 9,000 points per $100 MRR (sourced weighted); Diamond >=75% GRR, Elite >=80% and invite-only (sources disagree on the exact GRR gates - one reports 80%/85%; treat the shape, not the number, as the lesson); ~33 Elite of ~5,500-6,000 tiered | Monthly recalculation (15th) | Retention-gate the top; keep the apex genuinely scarce |
| Microsoft | Capability score, not a ladder | 6 solution-area designations | Partner Capability Score 70/100 across Performance, Skilling, Customer Success; skilling capped at 40 so no single pillar carries it; annual requalification | Annual, 13-month validity | Per-category minimums beat a single total |
| AWS (Services path) | Volume + capability ladder | Select → Advanced → Premier | Select: 4 accredited staff + 3 launched opportunities >=$1,500 MRR; Advanced: 8 accredited + 6 technical certified + 20 opportunities >=$10,000 MRR; Premier: 20 + 25 + 50 opportunities >=$50,000 MRR + 3 competencies (counts partly third-party, unconfirmed on AWS pages) | Annual, $2,500/yr fee per tier | Pair revenue thresholds with certified-headcount gates |
| Salesforce (FY27, Mar 2026) | Competency scoring | Collapsed 4 tiers to Select → Summit; ~170 badges cut to 28 competencies | Per-competency: certifications + completed projects + CSAT | Phased transition through 2026 | "Specialization is the new currency of the agentic era" - Nick Johnston, SVP, Global Consulting Partners & Partner Sales, Salesforce (via trade press) |
| Cisco 360 (Jan 2026) | Points index per portfolio | Cisco Partner → Cisco Preferred Partner | Preferred = 7.5/10 on the Partner Value Index across Foundational, Capabilities, Performance, Engagement | Phased multi-quarter rollout | Two tiers can suffice when an index does the ranking; $60M of an $80M training investment went to Preferred (vendor claim) |
| Shopify | Dual scorecard | Registered → Select → Plus → Premier → Platinum | Commercial performance + Verified Skills; Premier = 4 Plus/Enterprise wins trailing 2 years, Platinum = 6 (third-party figures, unconfirmed) | Quarterly, no stated grace - badge removed at next update | The no-grace end of the spectrum; harsh but unambiguous |
Cross-vendor pattern: the 2022-2026 redesigns (Microsoft, Salesforce, Cisco) all moved away from revenue-only metal ladders toward capability, competency, or index scoring - the McBain/Forrester critique playing out in production.
## A fully worked structure
Fictional mid-size B2B SaaS vendor: 160 partners - 95 resellers/MSPs, 40 agencies (both transacting), 25 ISV referral partners (non-transacting). Pain: flat 20% discount for everyone, no ladder, top performers asking what more they get. Numbers below use the sourced ranges from this skill's criteria and benefits references, which workflow steps 5 and 7 load.
It takes the starved mechanic on purpose: partners here transact across sourced and assisted motions and hold certifications, so no single metric ranks them in an order the channel team would defend - the stated condition that promotes a points pathway over the default engagement mechanic. It also splits the ISV partners into their own track, since their benefits barely overlap with the transacting ladder's.
```
TIER STRUCTURE - example vendor, transacting track (135 partners)
Mechanic : points pathway - 1 pt / $100 sourced MRR, 0.5 pt / $100 assisted,
+25 pts per certified individual; trailing-4-quarter rolling window
Tier count : 3 earned + unranked Registered entry rung
Registered : signed agreement only; portal + training access; no discount ladder
Silver : 150 pts; 2 certified staff | 15% discount, standard support
Backtest: 78 partners (58%) | cost ~ covered by cohort revenue
Gold : 500 pts; 4 certified staff; >=70% GRR on managed book
| 20% discount, deal-reg +10 margin pts (90-day protection -
110-day average cycle, so 82%, clearing the 75% rule),
defined 8-business-hour SLA, MDF pool access
Backtest: 42 partners (31%) | bundle cost < cohort contribution
Platinum : 1,500 pts; 8 certified staff; >=80% GRR; vendor-run CSAT gate
| 25% discount, deal-reg +15 pts, dedicated PAM (1:12),
70% of the 4%-of-channel-revenue MDF pool, 2% back-end rebate
Backtest: 15 partners (11%) | largest bundle, largest contribution
ISV track : separate criteria - integration maturity, joint customers,
marketplace listing; benefits are co-marketing + directory placement
Cadence : quarterly recalculation, rolling window, one-cycle (90-day) grace,
appeals to channel chief, decision dates published
Migration : best-status-in-trailing-year grandfathering for 2 quarters,
advisory-council preview 1 quarter before announcement
Pass check : top tier 11% of base (>=10% ✓, not crowded ✓); every step adds
discount + deal-reg + service (✓ visible differential); each
bundle modelled under cohort revenue (✓); no self-reported
criterion (✓ - pipeline counts only as accepted registrations)
```
Adapt the numbers, never copy them: the discounts, point weights, and MDF split come from practitioner ranges, not audited benchmarks, and the right values depend on the user's margin structure.
## The B2C contrast
| Dimension | B2B channel | Affiliate / creator | Consumer loyalty |
| ------------- | ----------------------------------- | ------------------------------------------ | ---------------------------------------------------- |
| Currency | Revenue + certifications + CSAT/GRR | Sales or GMV on a rolling window | Annual qualifying spend / nights / miles |
| Typical count | 3 | 3-5 | 4-5 |
| Reset | Rolling or annual, with grace | Rolling, near-real-time | Hard annual status clock; status valid ~12-15 months |
| Benefits | Margin, deal protection, MDF, PAM | Higher commission %, early access, bonuses | Upgrades, lounge access, multipliers |
| Human touch | High - PAM, QBRs | Low - self-serve | Fully automated |
Sourced B2C data points (each single-source - directional only):
- Three-tier affiliate commission ladders average roughly 10% / 14% / 19%.
- A DTC skincare brand (ClearStem, via its platform's case write-up) runs 10% / 15% / 20% at $2,500 and $5,000 revenue milestones.
- Social-commerce creator tiers commonly start at 5-10% commission, reaching 20-25%+ past roughly $2,500 GMV.
- Creator ladders (Seeding → Affiliate → Ambassador) qualify on audience size, engagement rate, and conversion history - signals with no B2B analogue.
The loop is identical everywhere - qualify → status → perks → requalify or demote - and the peer-reviewed demotion findings generalize across both worlds. The operational split is testability: A/B test an affiliate or loyalty ladder on a slice of the base. Never A/B test a B2B channel tier - it is negotiated and relationship-bound, so model it, pilot it with a cohort, and socialize it through the advisory council instead.
SKILL.md›
---
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 count (default 3; collapse to 2 below roughly 50 partners) - see [references/distribution-and-cadence.md](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.
5. 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](references/tier-criteria.md).
6. 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.
7. 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](references/tier-benefits.md).
8. Design promotion, demotion, review cadence, measurement window, grace period, grandfathering, and appeals path.
9. Plan migration and socialization: partner advisory council preview, notice period, migration comms, published decision dates.
10. Brainstorm and validate per the next section: candidate structures first, then the spec section by section.
11. Check the pass threshold; iterate criteria, benefits, or tier count until every check holds.
12. Stop at the approval gate - finalize nothing without the user's explicit approval of the full spec.
13. 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
Run the design the way channel teams actually run it - a compressed 90-day design sprint, not a single answer:
- Ask one question per message throughout; never batch questions.
- Assemble the data channel professionals bring to the table: partner P&L, sourced-revenue distribution, cost-to-serve, PSAT/NPS, portal-engagement signals. Model with what exists; name what is missing.
- Map the RACI: channel chief accountable, partner ops runs the model, partner marketing owns migration comms, finance validates margin, legal amends agreements, CRO defends the program.
- Segment the base first (partner type x size x economic potential); overlay the Forrester 3x3 grid internally to sanity-check where key partners would land.
- Present 2-3 candidate tier structures built from the ranked mechanics in workflow step 4: lead with the one that ranking recommends for this base, then say what would have to be true for each alternative to beat it.
- Once the user picks a direction, present the spec one section at a time - criteria, then benefits, then cadence, then migration - and validate each before writing the next.
- Recommend socializing the near-final structure through a partner advisory council before any public announcement; a tier change is negotiated and relationship-bound, not shipped.
- Gate finalization on explicit user approval of the assembled spec.
## The Tier Structure Spec
Deliver the engagement as this artifact - a decision record the user hands to partner ops, finance, and legal:
```
TIER STRUCTURE - <program>, <date>
Mechanic : volume | engagement | points pathway, with the point formula if points
Tier count : N, and why not N-1 or N+1
Per tier (repeat for each, bottom to top):
Name : partner-facing, repeatable (never "Tier 2")
Qualification : criteria + thresholds + measurement window + data source
Maintenance : what keeps the tier at each review checkpoint
Benefits : bundle, each benefit with its modelled unit cost
Modelled count : partners qualifying today (from the backtest) + % of base
Cost-to-serve : modelled annual bundle cost at that headcount
Revenue : modelled contribution of that cohort
Program level:
Review cadence : recalculation moment + rolling vs fixed window
Grace period : length before a demotion takes effect
Appeals : path + named decision owner + published decision dates
Grandfathering : who keeps status through migration, until when
Migration plan : notice period, advisory-council preview, comms milestones
Validation : pilot cohort or model checks before full launch
KPIs : from the KPI section, with the first review date
```
Rules about the spec itself:
- Attach a measurement window and data source to every threshold - a criterion nobody can compute demotes nobody.
- Carry a reason on every line ("top tier requires 80% gross revenue retention - gates co-sell on retention quality"); a bare number is not reviewable.
- Reject any criterion a partner can self-report or game; use only data the program itself records and can defend in a dispute.
- Treat backtested counts as mandatory: a structure never run against the real partner base is a guess, not a design.
## Pass threshold
Ship nothing until all four hold; iterate the design until they do:
1. **Reachable, not crowded.** The top tier is attainable by roughly >=10% of partners (PRM-vendor heuristic, not an empirical benchmark). If far more qualify, thresholds lag the base - escalate them.
2. **Visible economic differential at every adjacent step.** A ~2% discount bump plus a nicer badge is the documented failure: partners rationally decline to climb.
3. **Every tier self-funding.** Each tier's modelled benefit-bundle cost sits below that tier's modelled revenue contribution.
4. **Nothing gameable.** No criterion is self-reported or manipulable - logo counts and self-reported pipeline are the documented gaming vectors.
## Diagnosing an existing tier structure
When the user arrives with a running structure instead of a blank page, find their symptom in the table - rows are keyed by symptom, not by priority.
When several symptoms are present at once, fix in this order, ranked by efficiency, not severity:
`criteria thresholds > benefit differentiation > cadence, grace and comms > benefit allocation to the middle > tier count`
- Escalating a threshold is a spreadsheet change against data the program already holds, and it lands at the next review.
- Collapsing the tier count is a migration, a comms plan, and an agreement amendment, so it pays last, even when the bloat is what the user came in complaining about.
A crowded top tier and an unexplainable ladder are usually the same disease, and the threshold fix cures both.
The tier count is what that order starves - the highest-value fix on the list, ranked last on effort alone, so a ratio defers it every cycle while thresholds get re-escalated on a ladder nobody could explain in the first place. Promote it when adjacent tiers stop differing on both criteria and benefits, or when a migration is already happening for another reason and the count can ride along at no extra comms cost. Strike any row the program's constraints rule out and say it is struck - signed agreements that fix the current benefit bundle remove the differentiation row this cycle - rather than leaving it at the bottom, where it returns as work nobody scoped.
| Symptom | Check first | Design variable at fault |
| --------------------------------------------------- | -------------------------------------------------------------------------- | ------------------------------------------------------- |
| Tiers nobody can explain (5+, overlapping criteria) | Whether adjacent tiers differ on both criteria and benefits | Tier count - collapse |
| Top tier crowded (compression) | When thresholds were last raised vs base growth | Criteria thresholds - escalate |
| Nobody advances; partners stall at entry | Threshold curve: too easy at bottom, too hard at top; cliffs between steps | Threshold spacing |
| Partners ignore the ladder, won't invest | Economic differential per step: discount, deal-reg uplift, rebate | Benefit differentiation |
| Benefits allocated but unused (MDF unclaimed) | Claim friction and partner marketing bandwidth | Benefit design, not criteria |
| Tier metrics look great, results don't | Which criteria are self-reported (pipeline, logos) | Criteria gameability |
| Long tail dormant | Investment share reaching mid and low tiers | Benefit allocation - fix the middle before adding tiers |
| Deal fights between partners or with direct sales | Consistency of deal-registration enforcement | Benefit enforcement, not structure |
| Churn spikes after review dates | Demotion surprise: notice, grace period, appeals | Cadence, grace, and comms |
## KPIs
Judge the tier structure itself, not individual partners (individual scorecards belong to `mbfinotti/partnerships-skills@partner-performance`):
- Tier distribution shape across successive review periods - drift toward compression or an empty middle.
- Share of partners advancing per review period.
- Revenue per tier vs cost-to-serve per tier.
- Benefit utilization rate, especially MDF claim rate: 40-60% commonly goes unclaimed (recurring industry figure sourced).
- Partner satisfaction (PSAT/NPS) by tier.
- Post-demotion churn vs baseline partner churn.
## B2B vs B2C
Identical in both worlds: the power-law concentration, the threshold-gated qualify → status → perks → requalify loop, the tier-count rule above (3 by default, collapsing to 2 below roughly 50 partners), and the failure modes above.
Different - design for the difference:
- **Currency of progression**: B2B channel = revenue + certifications + CSAT/retention; affiliate/creator = sales or GMV on a rolling window; consumer loyalty = annual qualifying spend, nights, or miles.
- **Reset cadence**: B2B = rolling or annual with grace; affiliate = rolling; consumer loyalty = a hard annual status clock.
- **Human touch**: B2B = PAM coverage and QBRs; B2C = self-serve automation end to end.
- **Testability**: an affiliate or consumer ladder can be A/B tested across a large base; a B2B tier change is negotiated, relationship-bound, and socialized through a partner advisory council - model and pilot it instead.
See [references/worked-examples.md](references/worked-examples.md) for the full contrast with real vendor examples.
## Invocation Examples
- "Everyone gets a flat 20% discount and our top partners are asking what more they get. Design the tier ladder - 160 partners."
- "Our top tier is overcrowded and demotion has never been enforced. Fix the criteria and plan the migration."
- "We have 25 non-transacting ISV partners who cannot qualify for any tier. Give them criteria that fit."
## Reference
- See [references/tier-criteria.md](references/tier-criteria.md) for the criteria menu, points-model weighting, measurement windows, gameability checks, and criteria for non-transacting partner types.
- See [references/tier-benefits.md](references/tier-benefits.md) for the benefit menu with real costs, bundle pricing, and a negative example of a non-differentiated ladder.
- See [references/distribution-and-cadence.md](references/distribution-and-cadence.md) for tier count, backtesting, target distribution, cadence, promotion/demotion, grace, grandfathering, appeals, and tier-inflation control.
- See [references/worked-examples.md](references/worked-examples.md) for real 2023-2026 vendor structures decomposed, one fully worked tier structure, and the B2C contrast.
- See `mbfinotti/partnerships-skills@partner-channel-program` to design a whole partner program from scratch - this skill only refines the tier layer inside one.
- See `mbfinotti/partnerships-skills@partner-performance` for individual partner scorecards, QBR structure, and underperformance triggers.
- See `mbfinotti/partnerships-skills@affiliate-commission-structure` for commission payout tiers aimed at professional affiliates - a different discipline from channel tiering.