Sells upは、リードナーチャリングを「メールを送る活動」ではなく、リードの状態を見て、次に誰が何をするかを決める仕組みとして設計します。配点、HOTとみなす線、段階を下げるまでの期間は、決まった数値を当てはめるのではなく、その会社の受注と失注の行動の差を分析して決めます。
MAを入れても、配信の数が増えるだけで商談につながらないことはよくあります。原因の多くは、配信の手間ではなく、リードの状態を見て次の行動を決める基準がないことにあります。
本記事では、スタートアップからプライム上場企業まで100社以上のBtoBマーケティングを支援してきたSells upが、ナーチャリングをどう考え、配点や期間をどう決めているかを、ある支援先で分析から決めた数値を例に解説します。記事に出てくる数値はすべて一例で、一般的な基準ではありません。自社の受注と失注のデータで、配点・閾値・期間を決めてください。ナーチャリングの意味や手法の一般的な整理は、リードナーチャリングの意味と手法で扱っています。
Sells upがナーチャリングを見直すときに最初に見ること
支援の最初に見るのは、配信の数や開封率ではなく、次の4つの状態が起きていないかです。4つとも、リードの状態を見て次の行動を決める仕組みがないことから起きています。
スコアリングが営業に使われていない
点数を設定しても、営業がその点数を見ずにリストの上から順に電話している状態です。点数が何を表し、何点で誰が何をするのかを決めていないため、営業にとって使う理由がありません。弊社が実施したBtoB企業480名の調査では、MAを導入している企業のうちリードスコアリングを運用していると回答した割合は29.1%でした。MAが商談・売上に貢献できている企業(n=42)では40.5%、十分に活用できていない企業(n=92)では23.9%です。この差は関連を示すもので、スコアリングを入れれば成果が出るという因果を示すものではありません。
出典:弊社「MA活用実態調査(第0回)」。調査主体:株式会社Sells up/調査ツール:Surveroid(2026年9月、n=480、導入者 n=134)。詳細は調査レポートをご覧ください。
MAが入ったまま動いていない
MAを導入したものの、フォームとメール配信だけで止まっている状態です。シナリオを組む前に、どのリードをどの状態とみなすかを決めていないため、何を自動化すればよいかも見えません。
メルマガの配信が目的になっている
毎月の配信を続けることが目標になり、配信した後に誰の状態がどう変わったかを見ていない状態です。リストを件数で一括して扱い、分析しても配信の設定は変わらないと考えてしまうと、配信を続けるだけになります。この状態から抜け出す手順は、ナーチャリングがメール配信だけになる原因と抜け出す手順で解説しています。
リストの上から順に電話している
インサイドセールスが、獲得日の新しい順や社名の順に連絡している状態です。連絡の順番を決める材料がないため、関心が高まっている相手とそうでない相手が同じ扱いになります。設計しても成果が出ないときの原因の切り分けは、ナーチャリングが機能しない原因と対処法で扱っています。
ナーチャリングを4つの層で設計する
Sells upでは、ナーチャリングを4つの層に分けて設計します。上の層で決めた内容を、下の層の判断基準にします。
| 層 | 決めること | 決めていないと起きること |
|---|---|---|
| L1 どこから始めるか | ゼロから設計するか、いまの仕組みを作り直すか、インサイドセールスとの連携を強めるか | いまの状態に合わない施策から手をつける |
| L2 シナリオ | リードの状態(COLD・WARM・HOT)と段階の移し方 | 全員に同じメールが届く |
| L3 段階ごとのコンテンツ | 段階ごとに何を届けるか | 検討の前半にいる相手に申し込みを促し、反応が下がる |
| L4 KPI | 月次・四半期・年間で何を見るか | 開封率だけを見て、商談への影響が分からない |
L1 どこから始めるか|いまの状態で入り口を選ぶ
始め方は、いまの状態によって3つに分かれます。
1つ目は、ゼロから設計する場合です。MAがまだない、または入れたばかりで、リードの状態の定義もない状態です。段階と引き渡しの条件を先に決めてから、シナリオを1本だけ作ります。
2つ目は、いまの仕組みを作り直す場合です。点数やシナリオはあるのに使われていない状態です。点数の付け方と段階の定義を、受注と失注のデータを見ながら見直します。
3つ目は、インサイドセールスとの連携を強める場合です。引き渡しまではできているのに、その先で止まっている状態です。引き渡しの条件と連絡の期限、結果をマーケティングへ戻すルールを決め直します。
少人数のチームで、管理できる範囲に絞って始める考え方は、少人数のチームでナーチャリングを回す考え方で扱っています。
L2 シナリオ|COLD→WARM→HOTと段階の移り方
シナリオは、メールの順番ではなく、リードの状態と段階がどう移るかを設計するものです。状態はCOLD・WARM・HOTの3つ、段階は後で説明する6つで見ます。状態が上がったら届ける内容を変え、HOTになったらインサイドセールスへ渡します。どこからをHOTとみなすかは、次の章で説明するように自社のデータを見て決めます。配信の順番や分岐の条件まで細かく作る手順は、リードナーチャリングのシナリオ設計の手順で扱っています。
SmartHR様では、単発の一斉配信はすぐにできたものの、それだけでは数が足りなくなり、年明けから「アクション情報をベースにしたトリガーメール」の配信を始めました。相手の行動をきっかけに届ける仕組みに移ったことで、状態に合わせた配信ができるようになっています。行動をきっかけにしたメールの作り方は、トリガーメールの種類と設定の手順で解説しています。

L3 段階ごとのコンテンツ
コンテンツは、段階ごとに相手が持っている問いに答えるものを用意します。情報を集めている段階には課題の整理、比較している段階には事例や進め方、導入を決める段階には費用や導入の手順を届けます。段階ごとの種類と作り方は、検討段階別のナーチャリングコンテンツの作り方で解説しています。
L4 KPI|月次・四半期・年間の3つの周期で見る
KPIは、見る周期ごとに分けます。月次では配信と反応、四半期では段階の移り方と商談、年間では受注と売上を見ます。月次の数字だけで判断すると、ナーチャリングの成果が出るまでの期間を待てず、施策を早く止めてしまいます。
| 周期 | 見る指標の例 | 判断すること |
|---|---|---|
| 月次 | 配信数、クリック率、段階ごとのリード数、HOTになった数 | 配信の内容とタイミングを変えるか |
| 四半期 | 段階が上がった割合、MQL数、MQLから商談になった割合 | 段階の定義と点数を見直すか |
| 年間(KGI) | ナーチャリングを経た受注数と受注金額 | 予算と体制を続けるか、変えるか |
KPIは件数と率を組み合わせて見ます。月次はHOTになった数に加えて、HOTになった割合(HOTになった数÷対象のリード数)を見ます。四半期はMQLの数に加えて、MQLから商談になった割合(商談になった数÷MQLの数)を見ます。年間の受注は、同じ時期に獲得したリードごとに比べると、過去の配信の効果と新しい施策の効果が混ざりにくくなります。
指標の選び方と改善の回し方はナーチャリングの成果の測り方、KGIからの割り戻し方はMAのKPI設計とKPIツリーで扱っています。
配点・閾値・期間は、受注と失注の行動の差から決める
Sells upでは、業界で使われている配点表や他社の数値を、そのまま当てはめることはしません。受注した人と失注した人がどんな行動をしていたかを比べ、差が出た行動に点数を付け、差が出た期間をもとに時間の扱いを決めます。ここからは、ある支援先(小規模事業者向けのクラウドサービス)で、この方法で設計したときの例を紹介します。
分析に入る前に、リードごとに、獲得した日と経路、閲覧したページ、フォームの送信、メールの開封・クリック、商談になった日、受注・失注の結果を1つの単位で並べます。MAとSFAでIDが分かれている場合は、同じ人として追える項目を先にそろえます。行動だけでは商談につながったかが分からないため、営業側の結果までつなげます。この支援先では、氏名とメールアドレスはデータを取り出す段階で除き、個人を特定できない形で分析しました。
受注した人と失注した人で、見たページと進み方を比べる
この支援先では、ページ閲覧の記録をもとに、受注した人(約1,300人)と失注した人(約1,100人)の行動を比べました。活動していた期間の中央値は、受注した人が301日、失注した人が5日でした。閲覧したページ数の中央値は、受注した人が30、失注した人が9です。
受注した人が多く見ていたのは、問い合わせのページ(閲覧した人の割合の差は38ポイント)、製品の対応範囲を説明するページ(同35ポイント)、申し込み・トライアルのページ、FAQや困ったときのページでした。一方、失注した人の57%は、資料ダウンロードのページだけを見て離れていました。
資料をダウンロードした後に離れたかどうかでは、受注と失注の差は出ませんでした。差が出たのは、ダウンロードの後にどのページへ進んだかです。資料のダウンロードそのものより、その後の行動に点数を付けるべきだと分かりました。
差が出た行動から加点表を作る
比べた結果をもとに、次の加点表を作りました。資料ダウンロードのページを見ただけでは加点していません。
| 行動 | 点数(この支援先の例) |
|---|---|
| 申し込み・トライアルのページの閲覧 | +30 |
| 問い合わせのページの閲覧 | +25 |
| 製品の対応範囲を説明するページの閲覧 | +20 |
| FAQのページの閲覧 | +15 |
| お知らせのページの閲覧 | +8 |
| 製品のページの閲覧 | +5 |
| そのほかのページの閲覧 | +3 |
| 資料ダウンロードのページだけの閲覧 | 0 |
| 申し込み・トライアルのフォームの送信 | +40 |
| 問い合わせのフォームの送信 | +30 |
| 資料ダウンロードのフォームの送信 | +5 |
加点表の各行には、受注と失注の差という根拠があります。別の会社が同じ表を使っても、受注につながる行動が違えば意味がありません。分析する前に仮の点数を置くことはありますが、その点数は分析の結果で置き換えます。
時間の扱いも分析で決める
時間の扱いも、同じデータで決めました。初めて訪れてから7日以内に申し込み・問い合わせのページを見た人の受注率は71.8%、見なかった人は47.6%で、比べた行動の中で受注との差がいちばん大きいものでした。受注した人が申し込みのページにたどり着くまでの日数の中央値は、7.6日でした。
そこで、獲得から7日間は全員に共通のメールを送り、7日目にトライアルの申し込みへの導線を置いて、その後にリードの状態ごとの配信へ分けました。
また、受注した人は、初めて訪れてから91日以降もページを見続けていました。短い期間で点数を0に戻すと、検討を続けている人の点数まで消えてしまうため、この支援先では点数を短い期間で戻さない設計にしました。どれだけ動きがなければ点数や段階を下げるかは商材によって大きく違うため、一律の日数では決めません。
量だけでHOTにしない|行動の質と量の二層で判定する
この支援先では、次の2つの条件をどちらも満たす人をHOTとしました。
1つ目は、行動の量です。点数が80点以上であることを条件にしました。
2つ目は、行動の質です。申し込み・サポート系のページにたどり着いたか、申し込みのフォームを送信したことを条件にしました。
点数だけで判定すると、閲覧を重ねただけの人もHOTになります。行動の質も条件に加えると、連絡したときに話が進む相手に絞りやすくなります。WARMは40〜79点、COLDは39点以下としました。直近・頻度・行動の質(RFE)で約1.2万人の状態を分けると、HOTは0.66%、中間の層は63%、COLDは36%でした。HOTに当たる人はごく一部なので、それ以外の人には状態に合わせた配信を続けます。
CLUE様では、3日連続でサービスページを訪問しているユーザーを検知し、インサイドセールスへ自動で連携する仕組みを作りました。点数の合計だけでなく、直近の行動の続き方を条件にした例です。ただし、閲覧が増えたことだけで購買意欲が高いとは言い切れません。行動データはあくまで連絡する順番を決める材料で、相手の状況は会話で確かめます。行動データの読み方と読み違いについては、行動データからリードの温度感を読む方法で扱っています。
休眠した層の扱いも分析で決める
同じ分析で、しばらく動きがなかった後に戻ってくる「休眠傾向」の層のCV率が3.42%で、ほかの層より高いことが分かりました。一定の期間がたつと、また検討が始まる商材だったためです。
そこで、181日間動きがなく、かつ過去に点数が高かった人に、2か月に1通、もう一度検討するきっかけになる内容を送る配信を作りました。HOTになったものの話が進まなかった人も、点数を0に戻さず、休眠したらこの配信から再開します。休眠したリードの掘り起こし方は、休眠顧客の掘り起こし方法で解説しています。
リードの状態を直近・頻度・行動の質で見る
Sells upでは、リードの状態を、直近(Recency)、頻度(Frequency)、行動の質(Engagement)の3つで見ます。頭文字をとってRFEと呼んでいます。1回の行動の重さだけでなく、最近動いたか、何度も来ているかも合わせて見るためです。
3つで見る理由
点数を足していくだけでは、半年前に資料を何度もダウンロードした人と、今週になって料金ページを何度も見ている人が、同じ点数に見えることがあります。直近と頻度を分けて見ると、いま関心が高まっている相手を見つけやすくなります。行動の質は、閲覧したページや申し込みの内容によって重みを変えます。
重みと状態の閾値の一例
3つの重みも分析で決めます。複数の支援先の6か月分のデータをもとにロジスティック回帰で求めた例では、行動の質を0.45、直近を0.385、頻度を0.165とし、3つをそれぞれ0〜1にそろえたうえで重みをかけて足し、0〜1のRFEスコアにしています。
| 状態 | RFEスコア(一例) | この状態のときにすること |
|---|---|---|
| COLD | 0〜0.2未満 | 課題の整理に役立つ情報を、間隔をあけて届ける |
| WARM | 0.2〜0.75未満 | 事例や進め方など、比較に役立つ情報を届ける |
| HOT | 0.75以上、かつ直近7日以内に質の高い行動がある | インサイドセールスが連絡する |
これらの数値は、Sells upが支援先のデータから求めた一例であり、一般的な基準ではありません。先ほどの支援先のように、点数の合計80点と40点を境目にする設計もあります。どちらも、その会社の受注と失注のデータから導いた値です。自社のデータで重みと閾値を計算し直してください。ロジスティック回帰で計算する手順は、ロジスティック回帰で受注確度を計算する手順で解説しています。
MAでできない計算は、意図を保ったまま実装を置き換える
設計した計算を、MAでそのまま行えるとは限りません。そのときは設計を崩さず、意図を保ったまま実装の方法を置き換えます。先ほどの支援先(Salesforce・Account Engagement)では、次のように置き換えました。
1つ目は、直近の扱いです。Account Engagementのスコアは点数を足すか引くかで動き、経過日数に応じて点数に掛け算をすることはできません。そこで、最後の行動からの経過日数をいくつかの区分に分け、区分が変わるたびに点数を足し引きする形にしました。累計では、新規が+10、標準が0、やや冷えた状態が−10、長く動きがない状態が−20、休眠が−35です。
2つ目は、頻度の扱いです。頻度を表す項目は別に持たず、閲覧やメールの開封・クリックのたびに点数が足されることで、点数に反映させました。
3つ目は、点数を持つ場所です。閲覧のたびに積み上げる点数は、Account Engagement標準の「スコア」項目にまとめました。HOTかどうかの判定には、経過日数の区分、申し込み・サポート系のページへの到達、申し込みのフォームの送信、HOTのフラグ、過去に点数が高かったかどうか、の5つの項目を別に作って使っています。
実装の方法が変わっても、直近の行動を重く見ること、量だけでHOTにしないことという意図は変わりません。Account Engagementでの初期設定の点数や、グレードとの組み合わせ方は、スコアとグレードの設定手順で扱っています。
6つの段階と、動きがないときに段階を下げるルール
状態(COLD・WARM・HOT)が「いまどれだけ動いているか」を見るものだとすると、段階は「検討がどこまで進んでいるか」を見るものです。Sells upでは、段階を6つに分けています。
| 段階 | 相手の状態 | 主な担当 |
|---|---|---|
| New | 獲得した直後で、まだ行動の記録が少ない | マーケティング |
| TOFU | 課題について情報を集めている | マーケティング |
| MOFU | 解決の方法や会社を比べている | マーケティング |
| BOFU/MQL | 導入の判断に近い行動があり、MQLの条件を満たしている | マーケティングからインサイドセールスへ |
| SQL/商談中 | 営業が商談として扱っている | 営業 |
| 受注・失注・休眠 | 結果が出た、または長く動きがない | 営業・マーケティング |
段階を上げるのは緩く、下げるのは早くする
段階は、検討が進んだと見られる行動が1回あれば、1段階上げます。条件を厳しくしすぎると、関心が高まっている相手を見落としやすくなるためです。
一方で、動きがなくなった相手は段階を下げます。下げるまでの期間は、段階ごとに次の行動までの日数を自社のデータで分析して決めます。分析を始める前は、14日間動きがなければ1段階下げる、と仮に置くこともあります。ただ、これは推定の初期値です。先ほどの支援先のように、受注する人が長い期間ページを見続ける商材では、短い期間で下げると検討を続けている人を取りこぼします。下げるルールがないと、過去に一度動いただけの相手がいつまでも同じ段階に残り、段階ごとの人数が実際より多く見えてしまいます。
分析の前に置く仮の点数と、時間がたったときの減点
MQLとSQLの判定には、行動ごとの点数を足した行動スコアを使います。受注と失注のデータがまだ十分にない段階では、仮の点数を置いて始めます。Sells upが分析前に置くことがある点数の例は次のとおりです。先ほどの支援先の加点表とは値が違います。仮の点数は、分析結果で置き換える前提です。
| 行動 | 点数(分析前の仮の例) |
|---|---|
| 料金ページ・サービスページの閲覧 | +15 |
| 資料のダウンロード | +20 |
| 事例ページの閲覧 | +10 |
| メールのクリック | +5 |
| メールの開封 | +2 |
| フォームの送信 | +25 |
| 問い合わせ | +50(点数にかかわらず、すぐにインサイドセールスへ渡す) |
時間がたった行動の点数は下げます。仮の例では、180日間動きがなければ行動スコアから30点を引きます。古い行動の点数が残り続けると、いま関心がない相手が上位に並んでしまうためです。時間の経過に合わせて点数を下げる考え方は、HubSpotのリードスコアリングにも「スコアの減衰」として用意されています(出典:HubSpot Knowledge Base「Overview of the lead scoring tool」)。どの期間で何点下げるかも、受注した人の閲覧がいつまで続くかを見て決めます。
仮の点数で始めた場合は、運用を始めて3か月たった時点で、自社の受注と失注のデータで点数を計算し直します。点数の付け方と見直しの手順は、MAでのリードスコアリングの設計手順で解説しています。
ブリューアス様では、社内で運用していたころ、ステップメールの効果を見て通数や内容、送る間隔を直そうとしても「やりたくてもできてなかった」と担当者は振り返っています。いまはデータを見ながら改善を続けています。点数や段階の初期値は、こうしてデータを見て直していく前提で置くものです。

MQLとSQLの定義|営業に渡す線を決める
段階のうち、マーケティングから営業へ渡す線になるのがMQLとSQLです。Sells upで使うことがある条件の一例は、次のとおりです。
| 区分 | 条件(一例) |
|---|---|
| MQL | 属性スコア20点以上、かつ行動スコア40点以上 |
| SQL | デモの依頼、または行動スコア70点以上で、直近7日以内に導入判断に近い行動(BOFU)がある |
属性スコアは、行動の量とは別に、連絡したい企業かどうかを見るための点数です。業種、従業員規模、地域、役職、使っているシステム、自社のサービスとの合い方などを候補にし、対象外にしたい条件は減点します。行動スコアが高くても属性が合わない相手は、すぐに営業へ渡さず、別の配信に回します。先ほどの支援先のように、流入した時点で役職が分からず、属性で判定しにくい場合は、属性の点数を使わない判断もあります。
属性と行動の両方に下限を置くのは、狙っていない企業が行動を重ねただけでMQLになることや、狙っている企業でも動きがない段階で営業に渡ってしまうことを防ぐためです。ここで挙げた点数も一般的な基準ではないため、営業とすり合わせたうえで、商談になった割合を見ながら直します。
営業へ渡す基準と手順は営業へ引き継ぐ基準と手順、会話で確かめる項目はBANT条件の聞き方、スコアリングとナーチャリングの連携の実装はリードナーチャリングとスコアリングの連携で扱っています。
HOTの通知から追客・除外までを1つの流れにする
点数とHOTの線を決めても、営業がHOTに気づかなかったり、連絡した後の動きが固まっていなかったりすると、マーケティングと営業の間で引き渡しが途切れます。先ほどの支援先では、通知・メール・電話・除外までを1つの流れとして設計しました。この支援先は小規模事業者向けには商談の場を設けず、メールと電話で受注まで進める方針でした。
HOTになったら配信を止めて、担当者に知らせる
HOTと判定されると同時に、SalesforceにToDo「HOTリード通知」を自動で作り、リードの所有者に割り当てて担当者に知らせます。Account Engagementの画面上の通知は見落とされやすいため、補助として使いました。すべての配信で、HOTになった時点でメールを止め、電話に切り替えます。メールの送信者は担当者の個人名にしました。
始めたばかりのころは、件数を確保するためにHOTの全件に電話し、通知が多すぎるようなら基準を上げることにしました。
状態ごとに配信を分ける
配信は、Engagement Studioで4つのプログラム・合わせて15通を組みました。
| 配信 | 対象 | 頻度と内容 |
|---|---|---|
| 獲得の直後 | 獲得したすべての人 | 7日間で5通。製品の対応範囲・事例・FAQ・トライアルへ案内し、7日目にトライアル申し込みへの導線を置く |
| WARM | WARMの人 | 週1通・5通。事例、使い方、デモ動画、トライアルの順 |
| COLD | COLDの人 | 月1通。コラムや新機能など、売り込まない内容(配信を止められると、その後の接点がなくなるため) |
| 掘り起こし | 181日間動きがなく、過去に点数が高かった人 | 2か月に1通。もう一度検討するきっかけになる内容 |
連絡の回数と、外す相手を決める
追客のルールは、HOTの通知が来た当日から翌営業日までに1回目、7日以内に2回目の電話をかけ、3回目はかけずに再びHOTになるのを待つ形にしました。1回目の電話は、相手が見ていたページに合わせて話の切り出し方を7通り用意しました。電話の結果は活動記録の件名に結果のコードを付け、標準のレポートで集計します。
配信と通知から外す相手も決めます。この支援先では、商談が成立した人・進行中の人、配信停止・送信除外・ハードバウンスの人、利用中の顧客、リードのフェーズが「対応する」の人を外しました。取引先とリードが紐づかず自動で外れない人は、メールアドレス単位の除外リストに個別に加えています。仕組みを公開するときは、それまでのスコアをリセットし、公開した時点から数え始めました。
「やっているのに成果が出ない」状態から抜け出すために
施策を続けているのに商談が増えない、リードの質が上がらない。こうした課題の多くは、戦略と施策のつながりが設計されていないことが原因です。Sells upは現状の分析と改善の優先順位整理から支援します。
相談してみる →作った後の不具合は、エラーが出ないまま止まる
スコアリングとナーチャリングの仕組みは、作ったあとに動かなくなっても、エラーが表示されないことがよくあります。先ほどの支援先でも、公開後に次のような不具合が見つかりました。
不具合の例
1つ目は、重複したリードをSalesforceで削除したことで、Account Engagementが削除済みのリードを指したまま同期が止まり、HOTになってもToDoが作られなかったことです。再同期で解消し、重複は削除せず、取引の開始(変換)でまとめるルールに変えました。
2つ目は、経過日数の区分ごとに点数を足し引きするルールです。毎日あらためて条件を判定する設定で、条件が日付だけだったため、7日間、毎日10点が足され続けていました。さらに、区分ごとに決まった点数を足していたため、区分が変わるたびに減点が重なっていました。直前の区分を条件にして、差の分だけ足し引きする形に直しています。
3つ目は、MAの標準の採点ルールと、自作の加点が重なっていたことです。Account Engagementには、フォームの送信に50点を付けるなど標準の採点ルールがあり、自作の加点と足し合わされて、資料のダウンロードだけで約60点になっていました。標準のルールを見直すことを決め、最終的な点数はまだ決まっていません。
このほか、申し込みや見積もりのフォームがAccount EngagementではなくHubSpotのフォームで、Account Engagement側では送信を数えられないことも分かりました。補う方法は検討している途中です。短い期間にHOTを出たり入ったりする人にToDoが続けて作られないよう、通知をし直すまでの間隔も見直しています。
週1回、数字を見て気づける運用にする
こうした不具合は、毎週同じ数字を見ていれば早めに気づけます。HOTになった人数、作られたToDoの数、段階ごとの人数などを週1回見て、前の週と大きく違えば原因を調べます。
点数やHOTの線を見直すときは、HOTになった人数だけでなく、営業が電話した結果も合わせて見ます。結果のコードで集計すると、点数が高いのに話が進まない行動や、点数は低いのに商談につながる行動が見えてきます。配点、HOTの条件、外す相手のどれを変えたかを記録し、変える前と後で商談になった割合を比べます。
設定を変えるときの手順も決めておきます。
1つ目は、変える前にルールを止めることです。
2つ目は、元のルールをコピーしてから変えることです。
3つ目は、対象になる件数を先に見ておくことです。
4つ目は、一度に変えるのは1つだけにすることです。
5つ目は、何をいつ変えたかを記録することです。
仕組みを引き継ぐときは、設定の仕様書や操作の説明書、ルールの一覧とあわせて、この手順も渡します。
この設計を急がなくてよい場合
次のような場合は、ここで説明した設計をすべて整える前に、もう少し手前のことから始めます。
1つ目は、リードの数が少なく、担当者が一件ずつ状況を把握できる場合です。点数や段階を作る手間に見合う効果が出にくいため、問い合わせや資料ダウンロードがあったらすぐに連絡する、といったルールだけを先に決めます。
2つ目は、受注の件数が少なく、受注と失注の差を比べる材料がない場合です。受注が数件しかない段階で統計的な重みを出そうとすると、偶然の傾向を基準にしてしまいます。この段階では仮の点数で始め、データがたまってから分析して決め直します。
3つ目は、1社の中の複数の担当者の動きをまとめて見る必要がある場合です。高額な商材のように購買に多くの人が関わる場合、1人ごとの点数だけでは検討の進み具合を捉えきれません。Forresterも、リード単位ではなく購買グループと商談を中心に見る考え方を示しています(出典:Forrester「Put The Forrester B2B Revenue Waterfall Into Practice」)。この場合は、1人ごとの点数を会社単位でまとめて見る仕組みもあわせて考えます。
まとめ
Sells upでは、ナーチャリングを、リードの状態を見ながら次に誰が何をするかを決める仕組みとして設計します。どこから始めるかの判断、シナリオ、段階ごとのコンテンツ、KPIの4つの層に分け、上の層で決めたことを下の層の判断基準にします。
配点、HOTの線、段階や点数を下げるまでの期間は、決まった数値を当てはめず、受注した人と失注した人の行動の差から決めます。ある支援先では、受注した人が多く見ていたページに高い点数を付け、資料ダウンロードのページだけでは加点せず、7日以内に申し込みのページを見た人を重く見て、点数を短い期間では戻さない設計にしました。HOTは行動の量だけでなく、行動の質も条件にして判定します。
仕組みは、HOTの通知、電話、配信を外す相手までをつないで初めて動きます。作ったあとの不具合は、エラーが出ないまま止まっていることが多いため、週1回、数字を見て気づける運用にします。獲得と育成の境目をどう引くかは、リードジェネレーションとリードナーチャリングの違いで扱っています。
よくある質問
RFEとは何ですか?
Sells upがリードの状態を見るときに使う3つの観点で、直近(Recency)、頻度(Frequency)、行動の質(Engagement)の頭文字です。顧客分析で使われるRFM分析と近い考え方を、BtoBのリードの行動に当てはめたもので、3つの観点に重みをかけて0〜1のスコアにします。重みは、受注と失注のデータから求めます。
RFEスコアと行動スコアは何が違いますか?
RFEスコアは、いまどれだけ動いているかを0〜1で表し、COLD・WARM・HOTの状態の判定に使います。行動スコアは、行動ごとの点数を足したもので、MQLとSQLの判定に使います。役割が違うので、Sells upは両方を持たせて使い分けます。MAで掛け算ができない場合は、経過日数の区分ごとに点数を足し引きして、直近の重みを点数に反映させることもあります。
重みや点数は、そのまま使ってもよいですか?
おすすめしません。商材や検討期間によって、受注につながる行動は変わります。本記事の支援先の例でも、資料ダウンロードのページだけの閲覧は0点にしており、分析前の仮の点数とは大きく違います。受注と失注のデータがあるなら、行動の差を比べてから点数を決めてください。データが足りない場合は仮の点数で始め、3か月を目安に計算し直します。
段階や点数を下げるまでの期間は、どう決めればよいですか?
受注した人が、次の行動までどれくらいの間隔をあけているか、いつまで閲覧を続けているかを自社のデータで見て決めます。分析の前は14日間動きがなければ1段階下げる、と仮に置くことがありますが、受注した人が長く閲覧を続ける商材では、短い期間で下げると検討を続けている人を取りこぼします。
段階はいくつに分けるのがよいですか?
Sells upは、New、TOFU、MOFU、BOFU/MQL、SQL/商談中、受注・失注・休眠の6つに分けています。段階の数より、各段階に入る条件と出る条件、担当する人、次にすることがはっきりしているかのほうが大切です。
スコアリングを入れる前に、何を決めればよいですか?
営業と一緒に、どんなリードなら連絡する価値があるかを先に決めます。MQLの条件、渡した後に連絡する期限、結果をマーケティングへ戻す方法が曖昧なままだと、点数を作っても営業に使われません。HOTになったときの通知の方法と、配信や通知から外す相手も、この段階で決めておきます。
