referral-incentive-design について
顧客紹介プログラムの報酬設計を、ヒアリングを通じて支援するマーケティングスキルです。報酬対象、種類、金額、支払い条件、段階設定を検討し、テスト可能な仕様書を作成します。
主な機能
- 01ヒアリングに基づく設計プロセス
- 02報酬対象と種類の評価
- 03ユニットエコノミクスに基づく金額設定
- 04支払い条件と段階設定
- 05テスト可能な報酬仕様書の作成
- 06既存の紹介プログラムの診断
活用シーン
- 01新しい顧客紹介プログラムの設計
- 02報酬額と支払い条件の見直し
- 03参加率や転換率が低い原因の診断
- 04紹介コストと顧客獲得経済性の評価
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/ / github.com/ mbfinotti/ partnerships-skills --skill referral-incentive-designインストール後、Claude Code で/referral-incentive-designを入力して読み込まれたか確認します。
同梱ファイル
SKILL.md と一緒にインストールされる参考資料やスクリプト。
evals/evals.jsonreferences/examples.mdreward-types.mdsidedness-and-triggers.mdsizing-and-tiers.md詳細
紹介インセンティブの設計
顧客紹介プログラムの報酬構造を設計します。この分野に定番の名称が付いたフレームワークはありません。紹介は AARRR のような測定ファネルの一要素であり、設計手法ではありません。存在するのは、それぞれに独自のエビデンスがある4つの決定変数です。各変数が次の変数に影響するため、以下の順に検討します。
- 報酬の対象 - 紹介者、友人、または両方に報酬を与える(Reward-Me/Reward-You/Reward-Both の分類。Ryu & Feick、『Journal of Marketing』2007年)。
- 報酬の種類 - 現金、アカウントクレジット、割引、製品価値、ステータス、または寄付。
- 報酬額 - 粗利益、LTV、CAC を基準とし、非単調な反応に基づいて下限を設定します(報酬が少なすぎると、報酬がない場合より成果が悪くなります)。
- 報酬の発生条件と段階構造 - 報酬が発生するタイミングと、累計紹介数に応じて報酬を増やすかどうか。
インタビュー
何かを提案する前に質問してください。1回のメッセージにつき質問は1つにし、可能な場合は選択式の回答を提示します。ユーザーがすでに回答している質問は省略してください。
- 事業は B2B ですか、それとも B2C ですか?サブスクリプション型ですか、それとも買い切り型ですか?セルフサービス型ですか、それとも営業主導型ですか?
- 粗利益、平均 LTV(または初年度の売上)、ブレンド CAC/有料 CAC、エントリープランの価格はいくらですか?
- 顧客はすでに自発的に製品を勧めていますか?新規顧客のうち、おおよそ何割がその経路で獲得されていますか?
- 紹介者が再購入する可能性はありますか(アカウントクレジットに価値がある)、それともありませんか(現金相当の報酬しか価値がない)?
- B2B の場合、紹介者になりそうなのは購入者ですか、それとも会社が費用を負担する従業員ですか?
- いつまでに成果を出す必要がありますか?四半期末など厳格な期限がある場合、最初の購入を条件とする一律報酬という迅速な選択肢が有力になり、結果が出るまで数か月かかる段階制や継続利用を条件とする発生条件は除外されます。
- 1回限りの顧客獲得を目指しますか、それとも効果が積み重なる資産を目指しますか?効果の積み重ねを目指す場合、現物報酬やステータス報酬、段階制、継続利用を条件とする発生条件が有力です。1回限りの獲得を目指す場合は、友人側への一律オファーが有力です。
- 運用の上限はどの程度ですか?誰がこれを構築・管理しますか、その人に何時間使えますか。また、公開した報酬を後から撤回できますか?運用余力が少ない場合、グッズ、懸賞、段階的な報酬支払いは選択肢から外れます。専任担当者がいれば、段階制も再び検討対象になります。
ワークフロー
-
上記のインタビューを実施し、設計に必要なすべての回答を集めます。
-
設計前に除外条件を確認します。紹介プログラムは、すでに存在する口コミを獲得につなげるものであり、口コミを生み出すものではありません。自発的な紹介の兆候がない場合、または意味のある報酬を支払うには LTV が低すぎる場合は、率直に「まだ時期尚早」と伝えて終了します。質問の対象が外部アフィリエイトやチャネルパートナーではなく、最終顧客からの紹介であることを確認します(経済性も必要なツールも異なります。B2B プログラムは ACV の増加に伴って、前者から後者へ移行する傾向があります)。
-
references/sidedness-and-triggers.md を参照して、報酬の対象を決めます。効率の順序は 友人のみ > 両者 > 紹介者のみ です。3つの方法で手間は同じなので、価値に関するエビデンスに基づいて判断します。実地実験では、受け手のみへの報酬が、費用が2倍かかる両者への報酬と同等の成果を上げました。まず友人のみの報酬から始めます。革新的な製品、またはブランド力やつながりが弱い場合は両者への報酬に切り替えます。紹介プロセスに本当に大きな手間がかかる場合に限り、紹介者のみへの報酬に切り替えます。
-
references/reward-types.md を参照して、各対象に応じた報酬の種類を選びます。まず、効率の順序 製品価値の現物報酬 > アカウントクレジット == 無料期間 > 割引 > ステータス > 現金 > グッズ > 寄付 > 懸賞 を基準にします。そのうえで、この順序を覆す条件を適用します。
- 紹介者が再購入しない場合、または製品が金銭に近い性質を持つ場合は、現金相当の報酬を選びます。
- 紹介が公の場で行われ、アイデンティティに結びついた行為である場合は、現金よりステータスを優先します。
- 寄付は、選択肢として提示する場合に限ります。
B2B の場合は、本人への報酬と会社のアカウントクレジットのどちらにするかというプリンシパル・エージェントの分岐を、明示的に判断します。
-
references/sizing-and-tiers.mdを使って報酬額を決めます。粗利益の上限を算出し、最も手間のかからない基準(CAC に対する割合 > LTV に対する割合 > 回収期間の規律)から始めて、その範囲内で目標額を選びます。下限額を確認し(反応は単調ではありません。意味のある額を支払うか、まったく支払わないかです)、Rule of 100 に沿って金額を示します($100 未満なら割合、$100 以上なら絶対額)。
-
支払いのトリガーは、検証済みの価値イベントに設定し、単なるサインアップには設定しません。効率の順序は、初回購入 > 条件を満たしたアクティベーション > 受注成立/初回請求書 > 継続利用のしきい値 > 段階的な支払いです。営業主導の B2B では受注成立を優先し、返金や解約のリスクが大きい場合は継続利用のしきい値を優先します。保留期間は返金リスクと営業サイクルの長さに合わせます。
-
references/sizing-and-tiers.mdの段階設定のルールに照らして、段階制にするかを決めます。効率の順序は、定額 > しきい値ラダー > 段階式です。ラダーの構築コストに見合うのは、件数が多く、紹介者が繰り返し紹介する可能性があり、推奨活動が一部の紹介者に集中している場合に限られます。最初の段階は簡単に達成できるようにし、最上位の段階には必ず上限を設けます。この分野で最もよく記録されている失敗は、上限のないラダーです。
-
4つの決定事項を一つずつ提示し、検討した選択肢、トレードオフ、推奨案を説明して、それぞれについてユーザーの確認を得ます。異論があれば、次に進む前に修正します。
-
4つすべてについて明示的な承認を得た後、次のセクションにあるテスト可能な仕様として全体をまとめます。ユーザーの状況に合う事例があれば、references/examples.mdの対応する具体例を根拠にします。
-
ハーネスに永続メモリがある場合は、承認された仕様の主要な決定事項と経済性を記憶します。後の診断では、再度聞き取りをせず、これらを出発点にします。
上記の順序はすべて、労力(構築時間、事務処理、履行、調整、公開後に選択を変更する難しさ)あたりの価値を基準にしています。報酬額で順位を付けてはいけません。報酬のコストは別の軸であり、この2つの軸が食い違うことは十分にあるため、順位を一つにまとめると、最も安価な選択肢と最も効果的な選択肢が異なるケースが見えなくなります。
それぞれの順序は既定値であり、絶対的なルールではありません。状況や、実行を担う人によって変わります。選択肢を提示する前に、ユーザーについてすでに把握している情報に基づいて順位を付け直してください。
- 限界費用がほぼゼロの製品では、現物報酬を最優先にします。
- 財務チームが現金での支払いを認めない場合は、現金を順位から下げるのではなく、選択肢から外します。
- 既存の報酬プラットフォームがある場合は、ラダーやノベルティグッズを下位に置く原因となる労力差はなくなります。
どの事実によってどの選択肢の順位が変わったのかを明確に伝え、ユーザーが項目の順序ではなく、判断の根拠について意見を述べられるようにします。
報酬構造の仕様
すべてのエンゲージメントで、次の成果物を作成します。ユーザーがプロダクト、財務、テスト計画の担当者に渡せる意思決定記録です。
REWARD STRUCTURE - <product>, <date>
Sidedness : both | friend-only | referrer-only, split, disclosure choice
Reward (friend) : type, amount, framing ("first month free", not "$49 off")
Reward (referrer): type, amount, framing
Payout trigger : verified event per side + holding period + pending-state display
Tiers : ladder breakpoints + top-tier cap, or "flat - revisit when <condition>"
Caps : per-referrer/year, total-earned, program budget ceiling
Economics : gross-profit ceiling, projected cost per referred customer vs current CAC
Validation : test arms, % of base exposed, duration, decision metric, incrementality check
KPIs : participation rate, share-to-signup conversion, cost per incremental referred customer vs CAC
仕様そのものには、次の3つのルールがあります。
- すべての行に理由を付けます。「紹介者クレジットは2回目の請求時に付与します。返金期間を過ぎているためです」はレビュー可能ですが、金額だけでは不十分です。
- **検証計画は必須です。**どちらの参加者に報酬を与えるべきかについては、実務家の間でも現場調査でも意見が分かれています。そのため、両者/友人のみ/紹介者のみ(対象者の5〜10%で実施)の各テスト群と、インクリメンタリティの確認方法を明記します。インクリメンタリティの確認では、一部の対象者を除外します。獲得数が横ばいのまま CAC が上昇した場合、もともと流入していた顧客にプログラムが報酬を支払っていることを示します。
- **仕様には合格基準を設けます。**紹介によって増加した顧客1人あたりの予測コストは、現在のブレンデッド CAC を下回り、かつ粗利益の上限内に収まる必要があります。両方の条件を満たすまで、金額、種類、またはトリガーを調整します。条件を満たす構造がなければ、ローンチしないことを推奨します。
既存プログラムの診断
ユーザーが白紙の状態ではなく、稼働中のプログラムを持ち込んだ場合(「10ドル分のクレジットを提供しているのに、誰も使わない」など)は、効率のよい順に改善策を進めます。つまり、労力あたりに修復できるプログラムの範囲が最も大きい順です。最も安価な修正から始める順とは異なります。
効率:依頼の見せ方を変える > 友人側に配分を寄せる > 最低額を超えるよう報酬額を上げる > 上位層に上限を設けてトリガーを変更する > 報酬の種類を切り替える > 増分効果を測る対照群を設定する
| 症状 | 最初に確認すること | 労力 | 問題のある変数 |
|---|---|---|---|
| 紹介する顧客がほとんどいない | 依頼のタイミングと手間。報酬額よりも、依頼の配置のほうが参加率を大きく左右します | 1時間。プロンプトの位置を変え、文言を変更します | なし。報酬に手を加える前に、依頼の方法を改善します |
| 紹介は発生するが、友人がコンバージョンしない | 友人側のオファーの魅力度。友人側のほうがハードルの高い役割を担っています | 1時間。すでに使っている予算の配分を変えます | 配分/分割 |
| 報酬の追加後に参加率が低下した | モチベーションの最低ラインを下回るわずかな金額により、親切な行為が報酬の見合わない仕事になりました | 設定変更に1時間。恒久的な予算増額と比べて、負担は小さい | 金額 |
| 紹介力の高いユーザーが段階型の報酬を使い果たす | 最上位層への上限、または登録時に発動するトリガーが設定されていません | 1〜2日。ただし、公開済みの段階型報酬に上限を設けるのは、ここで最も定着させにくい変更です | 段階/トリガー |
| B2Bの紹介者が報酬を断る | 企業の贈答ポリシーとの衝突 | 四半期。財務、調達、法務のすべてが関わります | 種類:2トラック方式(企業クレジット+任意の個人向けトークン)に切り替え |
| 紹介数は健全だが、CACが上昇している | 増分効果。オーガニックな口コミで獲得できた顧客にも報酬を支払っていないか確認します | 四半期。対照群を設計し、測定結果が出るまで1サイクル全体を待ちます | 経済性:対照群を設定してから、オーガニックなリーチが低いセグメントに報酬を絞ります |
この順序では、増分効果を測る対照群の設定は後回しになります。効率の面では最後、真実を確かめる面では最初です。プログラム全体が、もともと獲得できていた顧客を買っていると明らかにできる確認方法は、これしかありません。紹介数が健全に見える一方でCACが上昇している場合は、すぐに優先順位を上げてください。安価な修正では説明できない症状はこれだけです。ほかの項目も、ユーザーの制約に照らして順位を付け直してください。たとえば、今四半期にUIをリリースできないチームは依頼の見せ方を変えられないため、友人側への配分変更が最優先になります。
B2B と B2C
B2B と B2C のどちらでも、以下は同じです。
- 4 つの意思決定とその順序。
- 粗利益の上限。
- 単調に増加しない下限。
- Rule of 100 の考え方。
- 検証済みの価値イベントをトリガーとする支払い。
- インクリメンタリティの割引。
どちらの場合も、これらを独自に作り直さないでください。
あえて明示すべき非対称性は、根拠となるエビデンスです。このスキルが依拠するフィールド実験や学術的な知見は、圧倒的に消費者側のものです。ここに記載されている数値はすべて、B2C で測定されたものであり、B2B については推定値として扱い、B2B プログラムについて助言する際にはその旨を伝えてください。
| 寸法 | B2C | B2B |
|---|---|---|
| 誰が報酬を受け取るか | 顧客。支払いを行う人でもあります | 多くの場合、支払いを行わない従業員です。ステップ 4 でプリンシパルとエージェントのどちらを優先するか、明示的に決定してください |
| 報酬の形態 | アカウントクレジット、または個人への現金相当額 | 原則として会社のアカウントクレジット。個人への報酬は、インセンティブにする前に贈答品ポリシーや調達上の問題として検討する必要があります |
| 支払いのトリガー | 初回の有料請求、またはアクティベーションのマイルストーン | それより後の段階です。サイクルが長く、返金リスクも大きいため、成約、または継続利用の基準を満たした時点とします |
| スケーリングの上限 | 規模を拡大しても維持されます | 実際にあります。ACV が増えるにつれて、顧客紹介プログラムはアフィリエイトプログラムやパートナープログラムへ移行します。この構造を限界以上に引き延ばすのではなく、移行の兆候に注意してください |
| 開示への配慮 | 中程度 | より高い配慮が必要です。紹介者が自分のネットワークにベンダーを推奨する場合、雇用主が監視する可能性もある、重要な利害関係が生じます |
呼び出し例
- 「月額 49 ドルの B2B SaaS 向けに、友人紹介の報酬を設計してください。利益率 80%、平均利用期間 14 か月、有料 CAC は 220 ドルです。」
- 「紹介者と被紹介者の両方に 10 ドルのクレジットを付与していますが、誰も利用しません。4 つの変数のうち、どれに問題があるか診断してください。」
- 「紹介報酬を段階制にすべきでしょうか。顧客の約 8%が紹介し、そのうち少数は繰り返し紹介しています。」
参考資料
- 専門のアフィリエイトやパートナーを対象としたコミッション設計については、
mbfinotti/partnerships-skills@affiliate-commission-structureを参照してください。 - 上限を適用するための対策(頻度制限、クールダウン、急増の検出、検証ゲート、上限を確実に適用するための公開文言)については、
mbfinotti/partnerships-skills@referral-abuse-guardrailsを参照してください。このスキルは上限値を設定し、そちらのスキルはその上限を確実に機能させます。