partner-tiering

パートナーのティア分け

既存のB2Bパートナープログラムにおいて、パートナーの各ティアを区別する基準と特典を定めます。唯一の標準的なティア設計手法は存在しないため、その旨を率直に伝え、存在するかのように作り上げないでください。実際にこの分野で提供されているのは、次の内容です。

• Forresterの3ティア標準：主要なITパートナープログラムの98％がティア分けを採用しており、平均で「グッド、ベター、ベスト」と名付けた3つのティアを設けています（生の調査データではなく、アナリストによる見解です）。
• The Alexander Groupの3つのティア設計方式：取引量、エンゲージメント、またはエンゲージメント経路（複数の側面でポイントを積み上げる方式）です。これは設計者が最初に行う構造上の選択です。
• Forresterのチャネルパートナーセグメンテーションマトリックス（Stephanie Sissler、2023年2月）：現在の実績と将来性を軸にした3×3のグリッドです。公開されるティア階層に重ねて使う内部評価であり、決してその代替ではありません。
• Jay McBainの批評（フレームワークではなく、実務家の見解としての帰属）：売上は遅行指標であり、取引を行わないパートナー（テック／ISV、紹介、アドバイザリー）は、構造上、売上ベースの階層に適合しません。

インタビュー

何かを設計する前に、メッセージごとに質問を1つずつ尋ねてください。複数選択肢を提示してください。ユーザーがすでに回答した項目は飛ばしてください。

• パートナーは何社いて、どの種類ですか？ リセラー、MSP、代理店、ISV／テック、紹介パートナーのうち、実際に取引を行うのはどの種類ですか？
• 現在のティアとその基準、現在の分布（各ティアに何社いるか）はどうなっていますか？
• 具体的な課題は何ですか？ 最上位ティアが混み合っている、昇格するパートナーがいない、特典が活用されていない、ロングテールが放置されている、チャネル間の競合がある、などでしょうか？
• パートナー経由の売上はどの程度集中していますか？ 上位10～20％のパートナーが占める割合は、おおよそどれくらいですか？
• 現在、各ティアのサービス提供にかかるコストはどれくらいですか？ マージンの譲歩、案件登録の上乗せ、MDF、PAMの人員数はどうなっていますか？
• 現在の見直し頻度はどれくらいですか？ また、ティア降格は実際に適用されていますか？
• 平均的な販売サイクルの長さはどれくらいですか？（ティア特典として提供する案件登録の保護期間は、その販売サイクルの75％以上に設定します。そのため、この数値を確認せずに既定の範囲から期間を選ぶと、販売サイクルに必要な期間の半分しか確保できない場合があります。）
• 新しい仕組みをいつまでに開始する必要があり、ティアの変動にその成果が表れる必要があるのはいつまでですか？
• 今回は特定の課題への一度限りの対処ですか。それとも、今後の各サイクルで継続的に評価し直す仕組みを構築しますか？
• 労力の上限はどれくらいですか？ パートナー運営にかけられる時間、利用できるデータ作業の量、そして降格を実際に適用するための政治的な影響力はどれくらいありますか？
• B2Bチャネルのみが対象ですか？ それとも、B2C向けのアフィリエイト、クリエイター、ロイヤルティのティアも運営していますか？
• 変更できないものは何ですか？ 締結済みのパートナー契約、会計年度のカレンダー、報酬プランなどでしょうか？
• 誰の承認が必要ですか？ チャネル責任者、CRO、財務、法務でしょうか？

ワークフロー

1. インタビューを実施します。設計の前提となる現状の事実をすべて収集します。

2. 範囲を確認します。既存プログラムのティア層を見直します。プログラムをゼロから構築する場合や、個々のパートナーのパフォーマンスを改善する場合は、「Reference」セクションにある関連スキルの対象です。

3. ベースラインを作成します。現在の各ティアのパートナー数、売上への貢献度、サービス提供コストを把握します。べき乗則を想定してください。パートナーの10～20％がチャネル売上の70～80％を生み出すというのが、よく引用されるパターンです（PRMベンダーの経験則であり、実証データセットではありません）。

4. ティア数を決めます（デフォルトは3。パートナー数が概ね50未満なら2に減らします）。references/distribution-and-cadence.mdを参照してください。次に、実際に選択を行うこの箇所で方式を選びます。

   • ボリューム：売上のしきい値のみを使います。運用コストはほぼゼロです。CRMにすでに数値があるためです。ただし、順位付けの精度は最も低くなります。売上は遅行指標であり、取引のないパートナーは全員、ここでゼロ点になるためです。
   • エンゲージメント：売上に認定資格、コンピテンシー、または継続率を加えます。立ち上げに数週間かかりますが、その後の各サイクルのコストはほぼゼロです。パートナーが異議を申し立てても覆せない基準と、再販業者以外も昇格できる段階が得られます。
   • ポイント方式：複数の活動を異なる重みで評価する、公開された計算式を使います。継続的な作業が必要です。各サイクルでパートナーに説明する計算式、カテゴリごとの最低基準、再計算が伴います。最も精緻な順位付けが可能であり、単一の指標では正しく順位付けできないパートナー群を並べ替えられる唯一の方式です。
   • 効率（比率が高い順）：エンゲージメント > ボリューム > ポイント方式
   • 価値（得られる順位付けの能力）：ポイント方式 > エンゲージメント > ボリューム
   • 労力（大きい順）：ポイント方式 > エンゲージメント > ボリューム
   • コストを独立した項目にはしません。方式にかかるコストは運用作業だけなので、コストの順序は労力の順序と同じです。
   • デフォルトではエンゲージメントを選びます。パートナーが複数の活動（案件の創出、支援、管理）を通じて取引する場合は、ポイント方式に切り替えます。単一の指標では、チャネルチームが納得できる順序に順位付けできません。
   • この順序では、ポイント方式が不利になります。価値も労力も最大であるため、どの比較でも選ばれません。プログラムですでに降格への異議申し立てが相次いでいる場合や、ティアの割り当てが各サイクルで個別に議論されている場合は、それでもポイント方式を優先します。
   • パートナー群の中で取引を行わないパートナーが相当な割合を占める場合は、ボリューム方式を候補から完全に外します。ボリューム方式ではそうしたパートナーをまったく順位付けできません。候補に残すと、ISVや紹介パートナーを不良パートナーとして扱う仕組みに戻ってしまいます。
   • インタビューの回答を基に、順位付けをやり直します。
     • 1四半期以内に期限がある場合は、ボリューム方式を優先し、今回の選定からポイント方式を外します。
     • 長期的な効果を求める方針がある場合は、ポイント方式を優先します。
     • パートナー運用の工数が確保されていない状態で、労力に上限がある場合は、ポイント方式を外します。
   • 次に、取引を行わないパートナーのタイプに適した基準を設けるか、別のトラックを用意します。

5. 特典に着手する前に、資格要件と維持基準を定義します。基準によってパートナーの所属先が決まるため、先に特典を設計すると、モデル化されていないパートナー群に約束してしまうことになります。references/tier-criteria.mdを参照してください。

6. 提案する基準を既存のパートナー群に当てはめてバックテストします。

   • バックテストの結果として得られた分布を、以下の合格しきい値と照らし合わせます。
   • しきい値を調整して再実行します。

   このステップで、次のステップの価格設定に使うモデル上のティア別人数が得られます。バックテスト前に算出した特典パッケージのコストは、誰も数えていないパートナー群を対象にした推測にすぎません。

7. 各ティアの特典パッケージに価格を設定し、収支を両方向から確認します。ティアの収益が特典パッケージのコストをまかない、昇格するたびにパートナーの努力が目に見える形で報われることを確かめます。references/tier-benefits.mdを参照してください。

8. 昇格、降格、レビューの頻度、測定期間、猶予期間、既得権の保護、異議申し立ての経路を設計します。

9. 移行と周知を計画します。パートナー諮問委員会への事前説明、通知期間、移行に関するコミュニケーション、決定日の公表を含めます。

10. 次のセクションに沿ってブレインストーミングと検証を行います。まず候補となる構造を検討し、その後、仕様をセクションごとに作成します。

11. 合格基準を確認します。すべてのチェック項目を満たすまで、基準、特典、またはティア数を見直します。

12. 承認ゲートで停止します。ユーザーが仕様全体を明示的に承認するまで、何も確定しないでください。

13. ハーネスに永続メモリがある場合は、承認済みの構造、しきい値、最初のレビュー日を記憶します。ない場合は、パートナー運用チームが参照できる場所に仕様を保存するようユーザーに伝えます。

ウェブを閲覧できる場合は、名前を挙げるベンダーの構造を引用する前に確認してください。主要プログラムは2022～2026年に何度も再編されています。閲覧できない場合は、ベンダーの事例が古くなっている可能性があることを明記してください。

このスキルと参照ファイルにあるすべての順序――上記の仕組み、参照資料の基準、特典、頻度、降格方針――はデフォルトであり、絶対的なルールではありません。プログラムの状況や実行担当者に応じて変わります。

ユーザーについてすでに把握している情報に照らして、それぞれの優先順位を付け直してください。

• 認定資格の有効な登録簿があれば、エンゲージメントの仕組みの導入コストはほぼゼロになり、最有力の選択肢になります。
• 商談の動きごとのアトリビューションがデータウェアハウスにすでに組み込まれていれば、ポイント方式の継続的な運用はクエリ実行だけで済みます。
• 今年、降格を実施する政治的影響力を持たないチャネル責任者がいる場合、レビュー頻度の優先順位が変わります。

デフォルトを言い直すのではなく、ユーザーから得たどの情報がどの選択肢を動かしたのかを述べてください。

構造のブレインストーミング

チャネルチームが実際に進める方法に合わせて、単一の回答ではなく、短期集中型の90日間の設計スプリントとして進めます。

• 全体を通して、1つのメッセージにつき質問は1つだけにします。質問をまとめてはいけません。
• チャネルの専門家が持ち寄るデータを集めます。パートナーの損益、紹介元別の売上分布、サービス提供コスト、PSAT/NPS、ポータルのエンゲージメントシグナルなどです。手元にあるデータでモデル化し、不足しているデータを明示します。
• RACIを整理します。チャネル責任者が説明責任を負い、パートナー運用チームがモデルを運用し、パートナーマーケティングが移行時のコミュニケーションを担当し、財務が利益率を検証し、法務が契約を改訂し、CROがプログラムを擁護します。
• まずパートナー基盤をセグメント化します（パートナーの種類 × 規模 × 経済的ポテンシャル）。内部ではForrester 3x3グリッドを重ね合わせ、主要パートナーの位置づけが妥当かを確認します。
• ワークフローのステップ4で順位付けした仕組みをもとに、候補となるティア構造を2～3案提示します。順位付けによってこのパートナー基盤に最適と判断された案を筆頭にし、各代替案がそれを上回るにはどのような条件が必要かを説明します。
• ユーザーが方向性を選んだら、仕様を一度に1セクションずつ提示します。基準、特典、頻度、移行の順に進め、次のセクションを書く前にそれぞれを検証します。
• 公表前に、最終案に近い構造をパートナー諮問委員会に共有することを推奨します。ティアの変更は、交渉を経て関係性を踏まえて行うものであり、一方的に導入するものではありません。
• ユーザーの明示的な承認を最終確定の条件とします。

ティア構造の仕様

この成果物を、パートナー運用チーム、財務、法務に渡す意思決定記録として作成し、取り組みをまとめます。

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

仕様そのものに関するルール：

• すべてのしきい値に測定期間とデータソースを付けます。計算できない基準では、誰も降格しません。
• 各項目に根拠を記載します（「最上位ティアには売上総維持率80％が必要。リテンションの質に基づいて共同販売の対象を決める」など）。数字だけではレビューできません。
• パートナーが自己申告や操作で達成できる基準は却下します。プログラム自体が記録し、異議申し立ての場で根拠を示せるデータのみを使用します。
• バックテストで算出した件数を必須とします。実際のパートナー基盤で試していない構造は、設計ではなく推測です。

合格基準

次の4つをすべて満たすまで、何もリリースしないでください。満たすまで設計を繰り返し改善します。

1. 到達可能であり、過密ではない。 トップティアには、パートナーの約10％以上が到達可能である必要があります（PRMベンダーの経験則であり、実証的なベンチマークではありません）。該当するパートナーが大幅に多い場合、基準が現状に追いついていません。引き上げてください。
2. 隣接する各段階で、経済的な差が明確である。 約2％の割引上乗せと見栄えのよいバッジだけでは不十分で、パートナーが段階を上げることを合理的に見送るという失敗例が記録されています。
3. すべてのティアで採算が取れる。 各ティアのモデル上の特典パッケージのコストは、そのティアのモデル上の収益貢献を下回る必要があります。
4. 不正に操作できる要素がない。 自己申告や操作が可能な基準を設けてはいけません。ロゴの数と自己申告によるパイプラインは、記録されている不正操作の対象です。

既存のティア構造を診断する

白紙の状態ではなく、すでに稼働中の構造を持つユーザーには、症状を表から探してください。行は優先度ではなく、症状ごとに分けられています。

複数の症状が同時にある場合は、深刻度ではなく効率を基準に、次の順で対処してください。

基準の閾値 > 特典の差別化 > 頻度、猶予、コミュニケーション > 中位層への特典配分 > ティア数

• 閾値の引き上げは、プログラムがすでに保有しているデータに対するスプレッドシートの変更であり、次回の見直し時に反映できます。
• ティア数の削減には、移行、コミュニケーション計画、契約の修正が必要となるため、最後に取り組むのが得策です。ユーザーが最初に不満を訴えているのがティアの肥大化であっても同様です。

最上位ティアが混み合っている状態と、説明のつかないティア構成は、たいてい同じ問題であり、閾値の修正でどちらも解消できます。

この順序で後回しになるのがティア数です。リストで最も効果の高い修正でありながら、労力だけを基準にすると最下位に位置するため、比率を使うと毎サイクル先送りされ、その間に、そもそも誰にも説明できなかった基準がさらに引き上げられます。隣接するティア間で基準にも特典にも差がなくなった場合、または別の理由で移行がすでに進行中で、追加のコミュニケーションコストなしにティア数の削減を併せて実施できる場合は、優先度を上げてください。プログラムの制約で実施できない項目は、その項目を除外すると明記してください。たとえば、現行の特典内容を定めた契約が締結済みであれば、今サイクルでは差別化の項目を除外します。実施範囲が決まらないまま最下位に残しておくと、誰も計画していない作業として再び持ち上がることになります。

症状	最初に確認すること	問題のある設計変数
誰にも説明できないティア（5層以上、基準が重複）	隣接するティア間で、基準と特典の両方に差があるか	ティア数 — 削減
最上位ティアが混み合っている（圧縮）	基準の閾値を最後に引き上げた時期と、基盤となる成長率との比較	基準の閾値 — 引き上げ
昇格するパートナーがいない。パートナーは初期段階で停滞している	閾値のカーブ：下位層では簡単すぎ、上位層では難しすぎないか。段階間に急激な変化がないか	閾値の間隔
パートナーがティア構成を気にかけず、投資しようとしない	段階ごとの経済的な差：割引、ディール登録による売上増、リベート	特典の差別化
特典は割り当てられているが利用されていない（MDF 未請求）	請求の手間とパートナーのマーケティング対応力	基準ではなく特典の設計
ティアの指標は優れているのに、成果が伴わない	自己申告となっている基準（パイプライン、ロゴ）の確認	基準の操作可能性
下位層の大半が活動していない	中位層と下位層に投資が届いている割合	特典配分 — ティアを増やす前に中位層を改善
パートナー間、またはパートナーと直販チームの間でディールを巡る争いがある	ディール登録の適用が一貫しているか	構造ではなく特典の適用
見直し日後に解約が急増する	降格が突然のものになっていないか：通知、猶予期間、異議申し立て	頻度、猶予、コミュニケーション

KPI

個々のパートナーではなく、ティア構造そのものを評価します（個々のスコアカードについては mbfinotti/partnerships-skills@partner-performance を参照してください）。

• 連続するレビュー期間におけるティア分布の形状 — 圧縮または中間層の空洞化に向かっているか。
• レビュー期間ごとに昇格するパートナーの割合。
• ティアごとの収益とサービス提供コスト。
• ベネフィットの利用率、特にMDF申請率：一般に40～60％が未申請のままになるとされています（出典付きで繰り返し報告されている業界の数値）。
• ティア別のパートナー満足度（PSAT/NPS）。
• 降格後の離脱率と、基準となるパートナー離脱率との比較。

B2BとB2C

どちらの領域でも同じです：べき乗則に従った集中、しきい値を満たして資格取得 → ステータス獲得 → 特典付与 → 再資格取得へと進むサイクル、上記のティア数ルール（デフォルトは3ティア、パートナー数が約50未満なら2ティアに集約）、および上記の失敗パターンです。

異なる点 — その違いを前提に設計します。

• 昇格の基準：B2Bチャネル = 収益 + 認定資格 + CSAT／継続率、アフィリエイト／クリエイター = ローリング期間内の販売またはGMV、消費者ロイヤルティ = 年間の資格対象支出、宿泊数、またはマイル数。
• リセットの頻度：B2B = 猶予期間付きのローリング方式または年次、アフィリエイト = ローリング方式、消費者ロイヤルティ = 毎年の明確なステータス判定期間。
• 人的な対応：B2B = PAMによる支援とQBR、B2C = 最初から最後までセルフサービスによる自動化。
• テスト可能性：アフィリエイトや消費者向けのラダーは大規模な対象者を使ってA/Bテストできます。一方、B2Bのティア変更は交渉を伴い、関係性に結び付いており、パートナー諮問委員会を通じて周知されます。そのため、モデル化してからパイロットを実施してください。

実際のベンダーの例を含む詳しい比較については、references/worked-examples.md を参照してください。

呼び出し例

• 「全員に一律20％の割引を適用していますが、上位パートナーからは追加の特典について質問されています。160社のパートナー向けにティアラダーを設計してください。」
• 「最上位ティアが過密で、降格が一度も実施されたことがありません。基準を見直し、移行計画を立ててください。」
• 「取引実績のないISVパートナーが25社おり、どのティアの資格も得られません。実情に合った基準を設定してください。」

参考資料

• 基準の選択肢、ポイントモデルの重み付け、測定期間、悪用可能性のチェック、および取引実績のないパートナータイプの基準については、references/tier-criteria.md を参照してください。
• 実際のコストを含む特典の選択肢、バンドル価格、差別化されていないラダーの悪い例については、references/tier-benefits.md を参照してください。
• ティア数、バックテスト、目標分布、評価頻度、昇格／降格、猶予期間、既存資格の維持、異議申し立て、ティアのインフレ抑制については、references/distribution-and-cadence.md を参照してください。
• 2023～2026年の実際のベンダー構造の分析、ティア構造の詳細な例、およびB2Cとの比較については、references/worked-examples.md を参照してください。
• パートナープログラム全体をゼロから設計するには、mbfinotti/partnerships-skills@partner-channel-program を参照してください。このスキルは、プログラム内のティア層のみを改善します。
• 個々のパートナーのスコアカード、QBRの構成、業績不振のトリガーについては、mbfinotti/partnerships-skills@partner-performance を参照してください。
• プロフェッショナルなアフィリエイト向けのコミッション支払いティアについては、mbfinotti/partnerships-skills@affiliate-commission-structure を参照してください。これはチャネルのティア設計とは別の分野です。