紹介の追跡とは、パートナーが提出した紹介を、最初の申請から最終的な結果まで記録し、監視し、報告するプロセスです。すべての紹介が正しく紹介元に帰属し、営業パイプライン（案件の見込み）の中で追われ、紹介したパートナーへの明確な報告をもって完了することを保証する、システム、ワークフロー、データ管理の方法を含みます。追跡は、紹介プログラムを信頼でき、効果を測定できるものにする、運用の土台です。
申請から結果まで
紹介の追跡は通常、パートナーポータル（または PRM（パートナー・リレーションシップ・マネジメント） のプラットフォーム）とベンダーの CRM を連携させて運用します。追跡のプロセスは、次の段階を経ます。
- 申請の受付。 パートナーがポータルで紹介を申請すると、システムが一意の追跡 ID を発行し、その紹介を申請したパートナー、見込み顧客、申請日に紐づけます。システムに記録された日時が、「先に紹介した者」を判定する帰属ルールの基準になります。
- 重複の確認。 システムは、紹介された見込み顧客がすでにベンダーの CRM に存在するかどうかを自動で確認します。一致するものがあれば、プログラムの重複排除ポリシーに従って、手作業での確認に回すか、自動的に却下します。
- ステータスの進行。 紹介が定められた段階（提出、受理、連絡済み、適格、商談化、提案送付、受注または失注）を進むにつれて、追跡システムは各段階の移行を、日時と担当者とともに記録します。
- 帰属の維持。 紹介と、紹介を生み出したパートナーとの紐づけは、商談の担当者が替わっても、別の案件と統合されても、パイプラインの段階が変わっても、商談の全期間にわたって保たれていなければなりません。多くの追跡システムが失敗するのは、まさにこの点です。
- 結果の記録。 紹介が最終状態（受注、失注、期限切れ）に至ると、システムは売上データ、成約日、理由コードとともに結果を記録します。
- 報酬の発生。 受注した紹介について、追跡システムは報酬のワークフローを開始します。契約条件に基づいて手数料を算出し、承認と支払いの手続きに回します。
追跡がプログラムへの信頼を支える理由
紹介は簡単に行えますが、簡単に失われもします。紹介の時点で帰属を示せる記録が残っていなければ、後になってその功績を認めることは、記憶を頼りにするしかなくなります。
Unifyr が紹介を追跡する方法追跡は、正式な紹介プログラムと、口約束のような非公式な取り決めを分けるものです。追跡がなければ、ベンダーは次のような問題に直面します。
- 帰属の喪失： 申請から成約まで追跡されない紹介は、パートナーとの紐づけを失いがちです。営業担当者が紹介であることを示さずに商談を CRM に登録すると、紹介パートナーは功績を認められません。紹介パートナーの不満として最も多いのが、この問題です。
- 報酬をめぐる対立： 紹介がいつ申請され、見込み顧客にいつ連絡がつき、案件がいつ成約したかを示す監査可能な記録がなければ、報酬に関する食い違いは解決できなくなります。
- ROI を測れない： 受け取った紹介の件数、そのうち成約した件数、生み出した売上を数値で示せなければ、紹介プログラムへの投資が見合っているかを判断できません。
- パートナーの離脱： 紹介の結果を確認できないパートナーは、プログラムへの信頼を失います。提出したすべての紹介の現在の状況を、パートナーがログインして確認できる見える化こそが、紹介件数を維持するための土台です。
主な機能
| 機能 | 説明 |
|---|---|
| 一意の紹介 ID | すべての申請に、システムが生成する識別子を付与し、最初から最後まで追跡できるようにします |
| 自動の重複チェック | 提出された紹介を CRM と照合し、既存の見込み顧客を特定します |
| ステータス通知 | 定義された段階が移るたびに、紹介したパートナーへ自動で通知します |
| CRM 連携 | 紹介システムとベンダーの CRM を双方向に同期し、帰属を維持します |
| 監査証跡 | 紹介に対して行われたすべての操作を日時付きで記録し、紛争の解決に使えるようにします |
| ダッシュボード | パートナーは自分の紹介を、ベンダーはプログラム全体の指標を、リアルタイムで確認できます |
| 報酬の計算 | 案件金額と紹介契約の条件に基づいて、手数料を自動で算出します |
よくある落とし穴
- 手作業への依存： 紹介の追跡をスプレッドシートやメールのやり取りに頼ると、ミスが積み重なります。紹介の分類を誤り、帰属を失い、ステータスの更新もばらばらになります。少数のパートナーを超える規模のプログラムでは、PRM や専用の紹介管理ツールによる自動化が標準です。
- CRM との分断： 紹介の追跡システムと CRM が連携していないと、営業チームは商談が紹介から生まれたことを把握できず、帰属の喪失や報酬の漏れにつながります。紹介システムが CRM にデータを送り、CRM が商談のステータスを戻す双方向の連携で、この隙間は埋まります。
- ステータスが粗い： 「提出済み」と「終了」の二つしかないと、紹介したパートナーに役立つ情報は伝わりません。パイプラインを意味のある段階（連絡済み、適格、提案、交渉、成約）に分けると、パートナーは商談の進み具合を現実的に把握できます。
- 有効期限のルールがない： 「提出済み」のまま無期限に残る紹介は、システムを散らかし、ベンダーがまだ追っているのかが曖昧になります。有効期限（例：申請から 90 日）を決めて、古い紹介を自動で終了させると、データを整理された状態に保てます。
紹介の追跡システムの最適化
紹介の追跡を改善しようとする組織は、次の点に注力するとよいでしょう。
- システム同士を直接連携する： 紹介の追跡プラットフォームは、商談レコードに直接書き込み、ステータスの変更を読み戻すべきです。手作業での同期やバッチによる取り込みより、API による連携が望ましいとされています。
- パートナー向けのダッシュボードを用意する： すべての紹介パートナーが、ポータルにログインして自分の申請の現状を確認できるべきです。未完了の件数、各紹介の段階、支払い済みの金額が見えることが、パートナーエンゲージメントの維持に欠かせません。
- 帰属ルールを仕組みで徹底する： 営業担当者が CRM で紹介のタグを手作業で付けることに頼らないでください。手作業のタグ付けは規模が大きくなると信頼できなくなるため、帰属の項目は紹介の追跡レコードをもとに、システムが自動で設定すべきです。
- 定期的に監査する： 紹介の追跡システムと、CRM で成約した案件を突き合わせる月次の照合レポートを作成します。紹介の帰属がないまま成約した案件や、CRM では成約しているのに追跡システムでは未完了のままの紹介など、食い違いを洗い出して解消します。この地道な管理が、データの正確さとパートナーの信頼を支えます。
- 追跡の使い勝手について意見を集める： 紹介パートナーに、追跡システムが役に立っているかを尋ねましょう。紹介の状況をポータルで確認しないパートナーは、その機能の存在を知らないか、使いにくいと感じているのかもしれません。どちらの場合も、対処は可能です。