リファーラルのKPIは「紹介件数」では足りない。紹介→商談化→成約の歩留まりで詰まりを見つける考え方

紹介営業に取り組んでいて、紹介件数はなんとなく分かる。でも、その紹介が商談になっていないのか、商談になっても決まらないのかが分からない。そんな経営者や本部担当者に向けた記事です。結論から言うと、リファーラルのKPIは件数ではなく「紹介→商談化→成約」の段階ごとの歩留まりと、紹介者別の流れに分けて見ると、どこで詰まっているかが見えてきます。代表がLINEで一件ずつ追わなくても打ち手を決めやすくなる、というのが今の自分の考えです。

紹介件数は分かるのに「どこで止まっているか」が分からない

紹介が何件来たかは把握できても、商談にならないのか、決まらないのかが見えなければ、改善は感覚頼みになります。そして結局、代表がLINEで一件ずつ確認することになります。

「最近紹介どう？」に即答できない状態

「最近紹介どう？」と聞かれて「何件か来てるよ」とは言えます。でも「そのうち何件が商談になって、どこで止まっているか」はすぐに答えられない。この状態だと、紹介が増えているのか減っているのかすら曖昧です。

状況を知る手段がLINEの遡りしかない

紹介者とのやりとり、営業担当との連絡、お客様との日程調整が、それぞれ別のLINEに散らばっています。状況を知るには遡って読むしかありません。

自分も今まさに紹介案件の情報ハブになっている

これは自分自身の話です。今、大量のLINEグループの確認に時間を取られていて、紹介案件の情報も自分のところに集まっています。この構造についてはLINEグループの巡回で1日が終わる状態から抜け出す情報集約の考え方でも書きました。

なぜ紹介件数だけをKPIにしてしまうのか

紹介件数は数えやすく、成果に見えやすいからです。ただ、件数は入口の量でしかありません。紹介の価値が決まる商談化や成約の情報は抜け落ちます。

件数は「頑張った感」が出やすい指標

件数が増えれば動いている感じがします。ただ、その紹介が商談にならず流れていても、件数の数字には表れません。

紹介の途中経過が記録されていない

「紹介された」はLINEに残っても、「商談になった」「見送りになった」はどこにも書かれていないことが多いです。

紹介者・営業担当・代表で情報が分散している

紹介者は紹介した事実を、営業担当は商談の中身を、代表は全体の雰囲気を知っています。でも、全員がつながった一本の流れを見ている人はいません。

よくある対策：紹介料や御礼を見直す前に確認したいこと

紹介が成果につながらないと、紹介料や頼み方を変えたくなります。でも詰まりが商談化や成約の段階にあるなら、入口を増やす施策は効きにくいと考えています。

入口を増やす施策と、途中の詰まりを解く施策は別物

紹介料や頼み方の工夫は「入口」に効く施策です。お金より安心感が大事だという話は紹介料を上げても紹介が増えない理由で書きました。ただ、それも詰まりが入口にある場合の話です。

詰まりの場所が分からないまま施策を重ねるとどうなるか

商談で落ちているのに紹介を増やすと、決まらない商談が増えるだけです。アポは増えても成果は変わらず、代表の時間だけが減っていきます。

紹介者に数字を求める前に、自社側の段階を見る

「もっと紹介してください」とお願いする前に、もらった紹介を自社がどう扱えているかを見るほうが先だと思っています。

リファーラルKPIは「段階」と「紹介者」の2軸で分ける

紹介→商談化→成約の各段階で何件残ったかという歩留まりと、紹介者ごとの流れを分けて見ると、詰まりの場所が特定しやすくなります。

段階の定義：紹介・商談化・成約をどこで区切るか

ここを曖昧にすると数字が意味を持ちません。たとえば次のように区切ります。

段階ごとの歩留まりの見方

「紹介→商談化」と「商談化→成約」は別々に見ます。紹介商談化率が低いのか、成約率が低いのかで論点がまったく変わるからです。

紹介者別の流れを見る意味

全体の歩留まりが平均的でも、特定の紹介者の案件だけ商談にならない、ということがあり得ます。全体の数字だけでは、この偏りは見えません。

件数が少ないうちは率より「止まっている案件」を見る

件数が少ないうちは、率が1件で大きく動きます。最初は率にこだわるより、「同じ段階に長く留まっている案件」を拾うほうが実用的だと考えています。

詰まっている段階によって打ち手は変わる

紹介→商談化で落ちる：紹介時のコンテキストと温度感

「とりあえず会ってみて」で渡された紹介は、商談になりにくいです。何を期待して紹介されたのかを揃える話は、紹介営業のコンテキスト設計で詳しく書いています。

商談化→成約で落ちる：商談側の設計の問題

この場合、紹介者ではなく自社の商談側を見直します。前提合わせが足りていないケースは商談で失注する本当の理由はコンテキスト不足が参考になると思います。

紹介者によって流れが違う：紹介者・代理店・加盟店の扱い分け

たまに紹介してくれる人と、看板を背負う代理店や加盟店とでは、期待値も必要な支援も違います。同じKPIで並べないほうがいい、というのが今の考えです（代理店と紹介の違い）。

数字を見ても「代表が全部判断する」状態は変わらない？

ここは正直、自分も迷っています。数字が見えても、判断がすべて代表に戻ってくるなら構造は変わりません。だから「数字を見る」と同時に「止まった案件を誰が動かすか」まで決める必要があると考えています。

代表がLINEで追わなくても見えるようにする記録の最小単位

全件を細かく入力させると続きません。紹介者・紹介日・現在の段階・ボールを持っている人くらいに絞り、止まっている案件だけが浮かび上がる形を目指しています。

記録する項目は絞る

項目を増やすほど入力されなくなります。この失敗構造は使われないシステムの特徴で整理しました。

段階が更新されない案件を「異常値」として拾う

全件を見るのではなく、段階が動いていない案件だけを拾う。全自動を目指さず異常値だけを抽出する仕組み化と同じ発想です。

スプレッドシートで始めるか、システムに載せるか

まずはスプレッドシートで項目と段階の定義を試し、固まったらシステムに載せる順番が無理がないと考えています。

ECパートナーズで今検討・試行していること

大量のLINEグループの確認に時間を取られている状態を変えるため、進捗管理システムを開発しながら、紹介案件の段階と紹介者を一画面で見られる形を検討しています。

情報確認の構造そのものを変えたいと考えている理由

仕事量を頑張って捌くのではなく、情報確認の構造そのものを変える必要があると考えています。自分がハブでいる限り、紹介が増えるほど自分が詰まります。

重要な案件だけを管理画面で確認するという理想

理想は、重要な案件だけを管理画面で確認できる状態です。ボール保持者を1人に特定する考え方は進捗管理の仕組み化にまとめています。

まだ決めきれていること・迷っていること

段階をどこで区切るか、紹介者と代理店・加盟店を同じ画面に並べるか分けるか。このあたりはまだ検討中です。

あなたの会社の紹介は、どの段階で止まっていそうですか？

まずは感覚でかまいません。次の質問に答えてみてください。

• 直近の紹介案件を思い出したとき、「紹介」「商談化」「成約」のどこに並びますか？
• 紹介者ごとに「その後どうなったか」を、LINEを見ずに答えられますか？
• その情報を一番知っているのは誰ですか？ それが代表だけなら、そこが最初の詰まりかもしれません。

今日からできること：紹介案件を3つの段階に並べてみる

システムを作る前に、手元でできることから始めてみてください。

1. 直近の紹介案件を書き出す：思い出せる範囲で、紹介者名と相手先を一覧にする。
2. 紹介・商談化・成約のどこにいるかを付ける：見送りになった案件も消さずに残す。
3. 紹介者別に並べ替えて偏りを見る：特定の紹介者だけ商談化していない、などがないかを見る。
4. 止まっている案件の次の担当者を決める：ボールを持つ人を1人書き込む。代表以外で決められるものは代表以外にする。

並べてみると、「紹介が足りない」のではなく「途中で止まっている」だけだった、と気づくかもしれません。自分もまさに今、そこを見える形にしようとしているところです。