Reference Customer Programs:顧客Referenceリクエストの管理

Referenceは取引を獲得する。あなたの製品をすでに使用しているピアから聞く見込み客は、営業チームが言えることよりも重みを持つ。しかしここに問題がある:適切な構造なしでは、最高の擁護者をバーンアウトさせ、保護しようとしている関係を損なう。

非常に喜んで協力してくれる5人の顧客が、何度も頼まれて最終的に応答を止めるのを見たことがある。そして、適切にマッチする方法を誰も知らないため、ほとんど使用されない50のReferenceを持つプログラムを見たことがある。両方の状況は、持っている最も価値のある資産を無駄にする。

Referenceプログラムの役割

優れたReferenceプログラムは、営業が取引を成立させるのを助ける以上のことをする。見込み客が「はい」と言うために必要なピア検証を与えながら、擁護者を保護する。

なぜReferenceが重要か

数字が物語を語る。Referenceはクローズ率を20-30%増加させ、懐疑心を他のどのデモよりも速く切り抜けることで販売サイクルを短縮する。見込み客が自分のような人—同じ業界、類似の課題—と話すと、営業チームに尋ねることさえ知らない質問への答えが得られる。

ピア検証が機能するのは、ベンダーフィルターを削除するからだ。あなたの営業担当者は「実装は簡単です」と一日中言える。しかし別のCTOが「3週間で本番稼働していました」と言う時、それは違う。それは信じられる。

Referenceはまた、製品が紙面で同様に見える時にあなたを差別化する。3つのベンダーがすべて同じ機能を主張する場合、見込み客が知っているまたは尊敬する企業からのReferenceを持つものが通常勝つ。

以前に火傷を負った本当に懐疑的な見込み客?適切なReferenceとの20分の通話が、彼らの姿勢全体を変える可能性がある。

Referenceインタラクションのタイプ

すべてのReferenceが同じように見えるわけではなく、フォーマットを理解することで、状況に応じて依頼をマッチさせるのに役立つ。

電話とビデオ通話はあなたの主力フォーマットだ。見込み客は15-30分を得て、望むことを何でも尋ねることができ、あなたの顧客は正直に経験を共有する。これらは、見込み客が真剣だが懸念が残っている販売サイクルの後半で最もうまく機能する。直接会話フォーマットは迅速に信頼を構築する。

Email Referenceは顧客のスケジュールが詰まっているか、質問が簡単な時に機能する。見込み客は質問を送信し、あなたの顧客は都合の良い時に応答する。負担は少ないが、説得力も少ない。複雑な評価ではなく、シンプルな検証ニーズにこれらを使用する。

サイト訪問はヘビー級オプションだ。高価値の見込み客が顧客の場所を訪問し、実際に製品を見て、複数のユーザーに会い、実装が実際にどのように機能するかを理解する。これらは強力だがリソース集約的だ—最大の取引のために予約する。

ピア会話は会議で、または非公式な紹介を通じて有機的に起こる。構造がないため、本物だが、追跡または管理も難しい。自然に起こる時、素晴らしい。それらを製造しようとしないでください。

エグゼクティブ接続は、ビジョン、パートナーシップ、Roadmap調整についての戦略的議論のためにC-levelの買い手とC-levelの顧客をペアリングする。これには強力な関係を持つシニア擁護者が必要で、主要な取引のためだけに保存する。

フォーマットを重要なことにマッチさせる。Emailで十分な時にサイト訪問を求めないでください。

プログラム目標

Referenceプログラムで実際に達成しようとしていることは何か?

主要な目標は、取引サイクルの重要な瞬間に信頼できる証拠点で営業をサポートすることだ。フェンスにいる時に見込み客の信頼を構築し、業界全体で多様なユースケースを紹介し、類似の機能を持つかもしれない競合他社から差別化したい。

しかし二次的な利点もある。最高の擁護者を特定し育成し、コラボレーションを通じて顧客関係を強化し、引用や成功ストーリーのようなコンテンツを生成し、パワーユーザーから製品フィードバックを集め、顧客間のコミュニティ接続を構築する。

鍵は、顧客関係を損なうことなくこれすべてを行うことだ。Referenceは両側を助けるべきだ。

Referenceプログラムの課題

管理している緊張は次のとおりだ:

営業はすべての取引にReferenceを望んでいる。彼らはそれらを迅速に望んでいる。彼らは完璧なマッチを望んでいる—同じ業界、同じサイズ、同じユースケース。そして無制限のアクセスを望んでいる。

一方、あなたの顧客はやるべき仕事を持っている。Referenceは時間とエネルギーを要する。過度に求めるとバーンアウトを得る。資格のない見込み客が時間を無駄にするような悪い体験を提供すると、擁護者を完全に失う。彼らはあなたに好意を行っているのであって、契約義務を果たしているのではない。

あなたのプログラムは、これらの圧力を仲介するために存在する。持続可能な方法で営業をサポートしながら顧客を保護する。

Referenceプールの構築

参加する意欲のある参加者なしでプログラムを実行できないし、すべての幸せな顧客が良いReferenceになるわけではない。

潜在的なReferenceの特定

明確で測定可能な結果を持つ強力な製品採用者である顧客から始める。彼らはソリューションに熱心で、経験を説明するのに十分明瞭であるべきだ。最も重要なのは、彼らが喜んでいる必要がある—一部の人々は単にReferenceをするのが好きではないし、それで問題ない。

また、ターゲット市場との調整と、チームとの強い関係も望んでいる。あなたを我慢する顧客は一度「はい」と言うかもしれないが、リピート擁護者にはならない。

あまりにも新しく意味のある経験を持たない顧客をスキップする。低いエンゲージメントまたは中立的な感情を持つ人をスキップする。価値を明確にするのに苦労する貧弱なコミュニケーターをスキップする。そして、ターゲット市場にマッチしない状況の人をスキップする、なぜならReferenceはとにかく信頼できないだろう。

すでに非公式に擁護している顧客—求められずにあなたを推薦する人—はあなたの最高の候補だ。そこから始める。

Reference募集の依頼

プログラムに顧客を招待する方法は、続くすべてのトーンを設定する。

このようなものを試してください:「[顧客]、あなたと一緒に働くのが大好きで、[特定の成果]で素晴らしい結果を得たことを知っています。時々見込み客のReferenceとして機能することにオープンですか?これが含むことです:四半期あたり最大1-2回の通話、それぞれ15-20分、類似の業界または役割の見込み客と。あなたはスケジュールと議論するトピックをコントロールし、各通話の前に準備します。見込み客があなたのような企業が私たちのソリューションをどのように成功裏に使用するかを理解するのに本当に役立ちます。これがあなたのスケジュールに合わない場合、まったくプレッシャーはありません。」

これが機能するのは、求めていることについて具体的で、時間的コミットメントについて現実的で、境界について明確で、彼らにコントロールを与えているからだ。「いいえ」と言うのを簡単にする。

明確な期待の設定

驚きを防ぐために、サインアップしているものを伝える:

  • 頻度: 「通常四半期あたり1-2回」
  • 期間: 「通話あたり約15-20分」
  • 準備: 「それぞれの前にブリーフィングします」
  • トピック: 「あなたの経験、結果、実装プロセス」
  • 共有しないこと: 「特定の価格、未リリース機能、または内部問題を避ける」
  • オプトアウト: 「機能しない任意のリクエストを辞退できます」

合意したことを要約するフォローアップEmailを送信する。後で混乱がある場合、書面による確認が役立つ。

Portfolioの多様性の構築

異なる見込み客は異なるReferenceが必要だ。ソリューションを評価しているFintech企業は、製造会社ではなく別のFintech企業と話したい。サイズも重要だ—50人のスタートアップと5,000人のEnterpriseは異なる懸念を持つ。

これらの次元全体で多様性を構築する:

  • 業界/業種(技術、医療、金融、小売など)
  • 企業規模(Enterprise、Mid-market、SMB)
  • ユースケース(製品が解決する異なる問題領域)
  • 地理(地域のニュアンスが重要な場合がある)
  • ユーザー役割(IT購入者、ビジネスユーザー、エグゼクティブ)
  • 実装タイプ(シンプル、複雑、段階的ロールアウト)

最低15-20のアクティブなReferenceを目指し、主要セグメントあたり3-5。より多くのReferenceはより良いマッチングと単一の顧客へのバーンアウトの軽減を意味する。

数学は次のとおりだ:プールに20のReferenceで年間40のReferenceを行う場合、それは顧客あたり平均2だ。管理可能だ。わずか5のReferenceで、それは顧客あたり8だ。それは疲れる。

継続的な育成

Referenceは、何かが必要な時にのみ連絡する一度の募集ではない。それは取引であって、関係ではない。

Referenceを求めていない時でも定期的にチェックインする。過去のReferenceが特定の取引を成立させるのにどのように役立ったかを共有する。許可を得て公に認識する。イベントでVIP待遇を与え、新機能への早期アクセスを提供し、日々の連絡を超えたエグゼクティブ関係を構築する。

定期的に感謝ギフトを検討する—毎回ではないが、価値を感じるのに十分な頻度。誰かが年間に3-4回のReferenceを行った時、CEOからの思慮深いギフトまたは手書きのメモが重要だ。

依頼を超えてこれらの関係に投資する。最高の擁護者は、リソースではなくパートナーのように感じるので、周りに留まる。

Referenceリクエスト管理

プロセスは混乱を防ぐ。心を失うことなくリクエストの流れを管理する方法は次のとおりだ。

営業提出プロセス

営業が完了する必要があるReferenceリクエストフォームを作成する。フォームなし、Referenceなし。これは、単に「Reference」を求めるのではなく、実際に必要なものを考えることを強制する。

フォームには以下を含める必要がある:

  • 見込み客企業名と業界
  • 取引サイズと現在のステージ
  • 見込み客の役割と肩書
  • 彼らが持っている特定の懸念または質問
  • 好ましいReferenceプロファイル(業界、サイズ、ユースケース)
  • タイムラインと緊急性
  • 取引の背景とコンテキスト

適切にマッチし、リクエストを資格認定するためにこの情報が必要だ。

リクエスト資格認定

すべてのリクエストがReferenceに値するわけではない。それらは価値がある—そのように扱う。

自問する:

  • これは資格のあるOpportunityか、初期段階のタイヤキックか?
  • 取引はどのステージにあるか?
  • 営業は最初に他のすべてを試したか?(Demo、ケーススタディ、無料トライアル、録画された顧客ストーリー)
  • Referenceは実際にこの取引を前進させるか?
  • タイミングは適切か?

販売サイクルで早すぎるリクエスト、Referenceをバーンすることを正当化するには小さすぎる、または営業が他のリソースを使い果たしていない状況を辞退する。顧客にとってタイミングが悪い時、適切なマッチがない時、またはこの見込み客がすでに複数のReferenceから聞いている時に辞退する。

低価値の依頼から Referenceを保護する。私が働いた1つの企業は、$50K未満の取引にDirector承認を要求し始めた。Referenceリクエストは60%減少したが、彼らが使用したReferenceのクローズ率は上昇した、なぜなら彼らは戦略的にのみ使用したからだ。

Referenceマッチング

適切なマッチは体験を成功または失敗させる。マッチングについて考える方法は次のとおりだ:

業界マッチングは巨大だ。金融見込み客は金融Referenceと話したい。マッチが近いほど、会話はより信頼性が高く関連性がある。

サイズマッチングは重要だ、なぜなら500人の企業は50人のスタートアップとは異なる懸念を持つからだ。見込み客のサイズの2-5倍以内に留まるようにする。

ユースケースマッチングは重要だ。見込み客が特定の問題を解決したい場合、その正確な問題を解決した顧客とマッチし、アプローチを共有できるようにする。

役割マッチングは可能な時に役立つ。CFOはCFOに関連する。IT DirectorはIT Directorに関連する。同じレベルまたはそれ以上が最もうまく機能する。

また、Referenceの可用性、関係の健全性、最近使用された時期(誰も過度に使用しない)、コミュニケーションスタイル、取引の重要性も考慮する必要がある。最大の取引のために絶対最高のReferenceを保存する。

一貫性を保つためにマッチングロジックをドキュメント化する。そうでなければ、毎回お気に入りの3つのReferenceにデフォルトになる。

顧客リクエストプロトコル

リクエストを資格認定し、適切なReferenceを特定したら、顧客に尋ねる方法は次のとおりだ:

「こんにちは[顧客]、

あなたに実行したいReferenceリクエストがあります—タイミングが良くない場合は辞退してまったく大丈夫です。

見込み客: [企業名]、[業界]、[サイズ] 彼らの役割: [肩書/役割] なぜ興味があるか: [特定のユースケースまたは問題] 彼らが理解したいこと: [主要な質問] 推定時間: 15-20分 タイミング: [提案された日付/時間]

これは[彼らの特定の興味]についてで、あなたが成功を収めたことを知っています。彼らとの簡単な通話にオープンですか?

これが機能するか、この機会を見送りたいかを教えてください。

ありがとう、 [あなたの名前]」

これは、適合を評価するために必要なすべてのコンテキストを提供し、明確な時間的コミットメントを示し、辞退を容易にし、特定の経験に関連する。曖昧にしないでください。

スケジューリングと調整

これを顧客にとって完全に無痛にする。すべての管理作業を自分で行う。

  1. 営業に「はい」と言う前に、最初に顧客の確認を得る
  2. 可用性を尋ねる:「来週どの日と時間が機能しますか?」
  3. 営業担当者を通じて見込み客と調整する
  4. 明確な議題で両方の当事者にカレンダー招待を送信
  5. 1-2日前に両側に準備Emailを送信
  6. 前日にリマインダーを送信
  7. 顧客に感謝し、見込み客とチェックするために直後にフォローアップ

あなたの顧客は、タイミングを調整したり、見込み客とEmailをやり取りしたりする必要は決してない。あなたがファシリテーターだ。

通話前の準備

明確な準備で両側を成功に導く。

顧客準備Email(1-2日前):

「[見込み客企業]とのReference通話のためのクイック準備:

: [名前、肩書、企業] いつ: [日付/時間] なぜ: 彼らは[ユースケース]のために私たちを評価しており、[特定の領域]を理解したい カバーするトピック: [機能]との経験、達成した結果、実装プロセス 避けるべきこと: 特定の価格、未リリース機能、内部課題 期間: 15-20分

正直であることを歓迎します—本物の体験は、見込み客が私たちが彼らに適しているかどうかを決定するのに役立ちます。質問があれば電話してください。

ありがとう!」

見込み客準備(営業担当者から):

「Reference通話がスケジュールされています:

Reference: [名前、肩書、企業] 背景: [彼らのユースケースと結果に関する簡単なコンテキスト] 最高のトピック: [このReferenceが話せること] 通話の詳細: [日付/時間/リンク]

質問を準備して来てください—これは彼らの経験について何でも尋ねるあなたの時間です。」

両側が何を期待するかを知って現れる。

Reference相互作用の管理

通話自体は、適切に準備していれば、思っているほど管理を必要としない。

通話中

ベストプラクティス:通話に参加しないでください。

ベンダーがいないと会話はより本物だ。あなたのReferenceはより自由に話し、見込み客はより厳しい質問をし、信頼はより速く構築される。唯一の例外は、顧客が緊張しているか、サポートを望むために特にあなたの存在を要求する場合だ。

参加する場合、当事者を簡単に紹介し、後退して聞く。直接尋ねられた場合にのみ明確化のために話に加わる。Referenceに90%話させる。あなたの仕事は、営業ピッチではなく、ファシリテーションだ。

Reference後の行動

フォローアップは重要だ。タイミングは次のとおりだ:

直後(数時間以内)、顧客に感謝を送信:

「今日[見込み客企業]と話す時間を取ってくれてありがとう。[トピック]に関するあなたの視点は非常に貴重です。あなたの経験を共有する意欲に本当に感謝しています。」

短く真摯に保つ。まだどうだったかを尋ねない—彼らにスペースを与える。

24時間以内、営業担当者を通じて見込み客とチェック:「Reference通話はどうでしたか?あなたの質問に答えましたか?」また、CRMに注記し、Referenceトラッカーを更新して量を監視する。

48時間以内、顧客からフィードバックを収集:「通話はどうでしたか?私が知っておくべきことはありますか?」これは、マッチが良かったか、彼らが準備されていたと感じたか、または何かがうまくいかなかったかを学ぶ時だ。

取引が成立したら(またはしなかったら)、Referenceに通知:「[企業]がサインしたことをお知らせしたかったです!あなたのReference通話は彼らの決定の大きな要因でした。ありがとう。」それが重要な取引の場合、ギフトまたは正式な認識を送信する。

人々は自分の時間が重要だったことを知ることを感謝する。

フィードバック収集

すべてのReferenceから学び、マッチングと準備を改善する。

顧客に尋ねる:

  • 体験はどうでしたか?
  • 見込み客はあなたの経験に適したマッチでしたか?
  • 十分に準備されていましたか?
  • 彼らはどんな質問をしていましたか?
  • 次回のために変更すべきことはありますか?

見込み客に尋ねる(営業を通じて):

  • Referenceは役立ちましたか?
  • あなたの懸念に答えましたか?
  • 何を学びましたか?
  • 改善のための提案はありますか?

このフィードバックは時間とともにプログラムを改善する。

Reference活動の追跡

バーンアウトを防ぐために量を執拗に監視する。

各Referenceについて追跡:

  • 提供された総Reference(全期間)
  • 四半期あたりのReference
  • 最後のReference日付
  • カバーした業界とユースケース
  • 成功率(成立した取引数)
  • 顧客フィードバックと感情

警告信号に注意:

  • 同じ顧客から四半期あたり2-3回以上のReference
  • 回答の熱意の低下
  • リクエストへの返信に時間がかかる
  • 以前よりも頻繁に見送ることを求める

これらの兆候を見る時、その顧客は休憩が必要だ。再度尋ねる前に少なくとも四半期休みを与える。

Referenceの保護

プログラムを殺す最速の方法は、最高の擁護者をバーンアウトさせることだ。

量の制限

厳しい境界を設定:

  • 戦略的擁護者: 四半期あたり最大4回のReference(月約1回)
  • 標準Reference: 四半期あたり最大2回のReference
  • 新しいReference: 1回から始めてどうなるか見る

リクエスト間のタイミングについて、依頼間の最小2-3週間、理想的には4-6週間を目指す。同じ人に連続した週に決して尋ねないでください。

これを厳密に追跡する。必要ならスプレッドシートまたはCRMに入れる。記憶を信頼しないでください。

量より質

すべての取引がReferenceを必要とするわけではない。それが営業が行う必要があるマインドシフトだ。

戦略的にReferenceを使用:

  • 特定のサイズしきい値を超える取引のみ
  • 真に必要な時のみ(見込み客が尋ねた、または取引が行き詰まっている)
  • 他のリソースを最初に試した後(ケーススタディ、Demo、トライアル、録画された証言)
  • 価値を最大化するための慎重なマッチングで
  • 両側のための適切な準備で

よく実行された10のReferenceは、ランダムに投げられた50を打ち負かす。量のMetricsではなく、質の体験に焦点を当てる。

リクエストを辞退する時

時々、自分のチームから擁護者を保護する必要がある。

辞退する時:

  • Referenceが最近使用された(30-45日以内)
  • Referenceが疲労信号を示している
  • 取引が尋ねることを正当化しない
  • マッチが低品質
  • あなたの顧客が現在技術的問題またはオンボーディング課題を抱えている
  • Referenceが明示的に休憩を求めた

貴重な擁護者をバーンアウトさせるよりも、限界的な取引を失う方が良い。長期的なプログラムの健全性は、どの単一の取引よりも重要だ。

擁護者への感謝

複数のレベルで真の感謝を示す。

各Reference後、個人化された感謝を送信。取引が成立した時に結果について更新。彼らが持った特定の影響を認識。

四半期ごとに、集約サマリーを送信:「この四半期のあなたの3つのReferenceは、新規ビジネスで$150Kを成立させるのに役立ちました。それは私たちにとって本当の違いを生みます。」小さなギフトまたは感謝のジェスチャーを含める—毎回ではないが、価値を感じるのに十分な頻度。エグゼクティブの感謝ノートも送信される。

年次で、トップReferenceを正式に認識。特別なイベントに招待し、意味のあるギフトを送信($100-500、量に応じて)、許可を得て公の認識を与え(ブログ投稿、賞、顧客スポットライト)、実際の影響力を持つアドバイザリーボードを作成する。

継続的に、イベントでVIPのように扱い、機能への早期アクセスを与え、製品方向の会話に含め、エグゼクティブ関係を構築し、彼らが必要とする時にそこにいる。

彼らを当然のこととして受け取らないでください。彼らはいつでもやめられる。

相互価値

最高のReference関係は双方向の道だ。感謝を言う以外に、Referenceに何を提供するか?

  • 業界の仲間との接続でネットワーキング
  • 可視性とソートリーダーシップの機会
  • 製品方向への早期インサイト
  • チームとのリーダーシップとの強化された関係
  • 問題解決が必要な時の優先サポート
  • 関連する場合のキャリアサポート(LinkedIn推薦、紹介など)

Referenceが関係から利益を得るパートナーのように感じる時、彼らはより長く留まり、より熱心に貢献する。

Referenceプログラム運用

体系的な管理は、混乱なしにスケールを可能にする。

プログラムWorkflow

標準プロセスは次のようになる必要がある:

  1. プール開発 - Referenceを継続的に募集し育成
  2. リクエスト提出 - 営業がフォーム経由で正式なリクエストを提出
  3. 資格認定 - 基準に基づいてレビューし、承認または拒否
  4. マッチング - この特定の見込み客に最適なReferenceを選択
  5. 顧客アウトリーチ - この特定のリクエストに対して喜んでいるかを尋ねる
  6. 調整 - 両当事者をスケジュールし準備
  7. 実行 - Reference通話が起こる(おそらく参加しない)
  8. フォローアップ - 顧客に感謝し、見込み客とチェックし、追跡を更新
  9. 分析 - 量を監視し必要に応じて調整

営業が何を期待するかを知るように、このプロセスを可視化する。

Referenceリクエストフォーム

フォームがキャプチャすべきことは次のとおりだ:

取引情報:

  • 見込み客企業名
  • 業界と業種
  • 企業規模(従業員と収益、わかれば)
  • 取引サイズ(ARR)
  • 予想される成立日
  • 営業担当者名

Reference要件:

  • 望ましいReference業界
  • 望ましいReference企業サイズ
  • 望ましいReference役割/肩書
  • 必要な特定のユースケースマッチ
  • 見込み客が持っている主要な質問
  • 現在の取引ステージと緊急性

正当化:

  • なぜ今Referenceが必要か?
  • どの他のリソースが使用されたか?(Demo、ケーススタディ、トライアル)
  • Referenceは何を達成するか?

この最後のセクションは、営業に戦略的に考えることを強制する。

マッチング基準マトリックス

一貫性を保つためにマッチのためのスコアリングシステムを開発する。

優れたマッチ(このReferenceを使用):

  • 業界:完全一致
  • サイズ:見込み客の2倍以内
  • ユースケース:同一の問題/ソリューション
  • 役割:同じレベルまたはそれ以上
  • 地理:同じ地域(重要な場合)
  • 可用性:高く、最近の感情が肯定的
  • 最近の使用:45日以上使用されていない

良いマッチ(受け入れ可能):

  • 業界:類似または隣接
  • サイズ:見込み客の5倍以内
  • ユースケース:関連アプリケーション
  • 役割:類似レベル
  • 地理:同じ国
  • 可用性:中程度の可用性
  • 最近の使用:30日以上使用されていない

悪いマッチ(使用しない):

  • 業界:異なる業種
  • サイズ:5倍以上の差
  • ユースケース:無関係なアプリケーション
  • 役割:大きな年功の差
  • 可用性:低いまたは最近の問題
  • 最近の使用:30日以内に使用

優れたマッチを見つけられない時、営業にプッシュバックするか、創造的な代替案を探す。

準備ガイドテンプレート

迅速にカスタマイズできるテンプレートで時間を節約する。

顧客準備テンプレート:

Reference通話準備

通話の詳細:
- 見込み客: [企業、業界、サイズ]
- 連絡先: [名前、肩書]
- 日付/時間: [いつ]
- 期間: 15-20分

コンテキスト:
[なぜ興味があるか、どのステージにいるか、どんな懸念を持っているか]

良いトピック:
- [特定の機能]での結果
- 実装経験とタイムライン
- チームが日々どのように使用するか
- あなたが見たROIまたはビジネス価値
- サポートとサービス体験

避けるべきトピック:
- 特定の価格詳細
- 未リリース機能またはRoadmapアイテム
- 内部苦情またはフラストレーション
- 競合他社の比較

正直であることを歓迎します—本物の体験は、見込み客が私たちが彼らに適しているかどうかを決定するのに役立ちます。

質問?[番号]に電話してください

各通話の「コンテキスト」と「良いトピック」セクションをカスタマイズするが、構造は一貫性を保つ。

追跡システム

次を示すDashboardを構築:

顧客ごとに:

  • 提供された総Reference(全期間)
  • この四半期のReference
  • 最後のReference日付
  • 次の適格日(頻度ルールに基づく)
  • 成功率(成立した取引)
  • 感情とフィードバックスコア

営業担当者ごとに:

  • リクエストされたReference
  • 承認率(リクエストが承認される頻度)
  • Referenceが使用された時のクローズ率
  • リクエストの質(良いマッチング、適切な正当化)

全体的なMetrics:

  • 四半期あたりの総Reference
  • 顧客あたりの平均Reference
  • Reference-to-close率
  • トップReference貢献者
  • Reference満足度スコア

持っている場合はCRM Workflowを使用するか、スプレッドシートを構築する。どこかで追跡するだけ。

Referenceプログラム成功Metrics

プログラムが機能しているかどうかを知るために重要なことを測定する。

量Metricsはキャパシティと需要について教えてくれる:

  • プール内のアクティブReference(ターゲット:15-20+)
  • 月あたりのReferenceリクエスト
  • 月あたりの提供されたReference
  • リクエスト承認率(ターゲット:60-80%)

品質Metricsは効果について教えてくれる:

  • Reference有り vs なしの取引クローズ率(20-30%高いべき)
  • Reference有り vs なしの販売サイクル長(短いべき)
  • Reference満足度スコア(ターゲット:90%+)
  • Referenceに対する見込み客満足度(ターゲット:85%+)

健全性Metricsは持続可能性について教えてくれる:

  • 顧客あたりの平均Reference(ターゲット:四半期あたり最大1-2)
  • Reference定着率(アクティブに留まっているか?)
  • Referenceリクエストを満たす時間(ターゲット:5日未満)
  • 業界とユースケース全体のReference多様性スコア

Metricsが高い量を示すが満足度の低下または顧客バーンアウトの増加を示す場合、あまりにも強く押しすぎている。スケールバックし、擁護者を保護する。

Referenceプログラムの構築

シンプルに始めて体系的にスケールする。初日にすべてを構築しようとしないでください。

フェーズ1(月1-2) - 基盤:

最も幸せで成功している顧客から10-15の潜在的なReferenceを特定。明確な期待で最初のコホートを募集。営業のためのシンプルなリクエストフォームを作成。1ページのガイドで基本プロセスをドキュメント化。スプレッドシートですべてを手動で追跡。

フェーズ2(月3-4) - 体系化:

マッチング基準とスコアリングシステムを構築。顧客準備、見込み客準備、フォローアップEmailのテンプレートを開発。適切な追跡システム(CRM Workflowまたはより良いスプレッドシート)を作成。プロセスとなぜ重要かについて営業をトレーニング。初期Metricsの測定を開始。

フェーズ3(月5-6) - 最適化:

Referenceプールを20+の擁護者に拡大。機能していることに基づいてマッチングアルゴリズムを改善。正式な感謝プログラムを実装(四半期ギフト、年次認識)。フォローアップと追跡のためのリマインダーを自動化。マッチングを改善するために成功パターンを分析。

フェーズ4(月7-12) - スケール:

健全なプールを維持するために継続的に募集。Referenceをティアに分割(戦略的、標準、専門化)。高度な分析とレポートを構築。プログラムからのベストプラクティスとケーススタディをドキュメント化。内部および外部でプログラムをマーケット。

フェーズをスキップしないでください。それぞれが前のものの上に構築される。

一般的なReferenceプログラムの間違い

これらが良いプログラムを殺すのを見てきた:

過度の使用 - 同じ3-5のReferenceをバーンアウトして応答を止めるまで繰り返し使用。 修正: 量を宗教的に追跡し、厳しい制限を設定し、リクエストを配布するためにプールを拡大。

悪いマッチング - 適合に関係なく、任意の利用可能なReferenceを任意の見込み客に投げる。 修正: マッチング基準を開発し、リクエストを適切に資格認定し、適合が悪い時にプッシュバック。

準備なし - Referenceを求めてコールドコーリングする顧客、または通話のために彼らを準備しないままにする。 修正: 標準準備テンプレートを使用し、適切なリードタイムを与え、完全なコンテキストを提供。

擁護者を無視 - 何かが必要な時にのみ連絡し、リソースとして扱う。 修正: 依頼に関係ない定期的なチェックイン、正式な感謝プログラム、関係構築。

追跡なし - 量、成功率、顧客感情について盲目に飛ぶ。 修正: 初日から追跡を実装し、月次にMetricsをレビューし、データに基づいて調整。

営業バイパス - CS調整なしで知っている顧客に直接行く営業担当者。 修正: プロセスを強制し、CS承認を要求し、例外を簡単ではなく痛みを伴うものにする。

資格認定なし - サイズ、ステージ、または適合に関係なくすべての取引にReferenceを提供。 修正: 資格認定基準を設定し、承認プロセスを構築し、CSに「いいえ」と言う権限を与える。

当然と思う - 感謝なし、認識なし、彼らが行っている好意の承認なし。 修正: プロセスに感謝を組み込み、定期的に影響を共有し、貢献を認識。

ほとんどのプログラムは、擁護者保護ではなく営業の利便性のために最適化するため失敗する。その間違いを犯さないでください。

関連リソース