ABMでターゲットアカウントを絞り、DMUの各メンバーに役割別のコンテンツを届けても、いざ営業に渡すタイミングがずれて商談化を逃してしまう、という方は多いのではないでしょうか。ABMの営業ハンドオフは、ICPスコアリングでターゲットアカウントを特定し、DMUマッピングで誰に届けるかを定め、役割別にコンテンツを配信した、その先の工程にあたります。BtoBの買い手は、購買プロセスの前半を匿名のまま進めることが多く、ベンダーのサイトを複数回訪れてから接触してきます。この水面下の動きを捉えて適切なタイミングで営業が動けるかが、商談化を大きく左右します。結論から言うと、ハンドオフがずれる原因は、渡すタイミングを担当者の感覚に委ねていることにあります。本記事では、この設計の考え方をAgentic CRMの枠組みにもとづいて整理します。
そこで本記事では、営業ハンドオフの基準を、静的なスコアから購買シグナルを取り込んだ動的なスコアへと転換し、それをAgentic CRMがどのように自律化するのかを、スコアの設計や実装ステップまで含めて解説します。なお、ツールの提供条件は変わるため、本記事は2026年9月時点の情報にもとづいています。DMUとは、BtoBの購買でひとつの意思決定に関わる複数の担当者の集まりのことです。
なぜ遅れる？ABMのハンドオフが逃す3つの原因
本記事では、クラウド型のERPを提供する中堅BtoB SaaS企業（従業員約300名・MAとCRMを導入済み・ABMでターゲットアカウント営業を実施中）が、営業ハンドオフの設計に取り組んだケースを例に、解説を進めます。ターゲットも届け方も整えたのに、なぜ渡すタイミングだけがずれるのでしょうか。そこでここでは、ABMの営業ハンドオフがタイミングを逃す3つの原因を整理します。
営業ハンドオフがタイミングを逃すのは、渡す定量基準がなく、スコアがリード単位で検討温度が見えず、閾値を超えてから連絡するまでのラグで競合に取られるからです。
原因①「いつ渡すか」の定量基準がなく担当者の感覚でハンドオフしている
1つ目の原因は、「いつ渡すか」の定量的な基準がなく、担当者の感覚でハンドオフしていることです。なぜ問題かというと、感覚に頼るとタイミングが安定しないからです。早すぎれば商談にならず、遅すぎれば競合に先を越されます。
先ほどのバイヤーの匿名訪問のように、購買の検討は水面下で進みます。定量的な基準がなければ、その検討がどこまで進んだのかを判断できません。渡すか渡さないかが人によって変わり、ハンドオフの質がばらつきます。
たとえば、このERP企業では、営業へ渡す判断がマーケティング担当者ごとにまちまちで、ある担当者は早めに、別の担当者は慎重に渡していました。基準がないことが、ハンドオフのタイミングのばらつきを生んでいたのです。
このように、渡す定量基準がなく感覚に頼っていることが、最初の原因になります。
原因②スコアがリード単位で計算されていてDMU全体の検討温度が見えない
2つ目の原因は、スコアがリード単位で計算されていて、DMU全体の検討温度が見えないことです。なぜなら、ABMでは一人だけでなく購買委員会全体で意思決定が進むのに、個々のリードのスコアだけでは、アカウントとしての検討の高まりを捉えられないからです。
担当者一人のスコアが高くても、決裁に関わる他のメンバーが動いていなければ、商談はまだ遠いかもしれません。逆に、複数のメンバーが同時に動き始めていれば、アカウント全体の検討温度は高まっています。リード単位のスコアは、この全体像を映せません。相手ごとに扱いを変える設計の考え方は個別化の記事でも扱っています。
たとえば、このERP企業では、ある担当者のスコアだけを見て営業に渡したことがありました。決裁者がまだ関与しておらず、商談は動きませんでした。アカウント全体の温度を見られていなかったのです。
このように、リード単位のスコアでDMU全体の検討温度が見えないことが、2つ目の原因になります。
原因③スコアが閾値を超えてから営業に連絡するまでのラグで検討を競合に取られる
3つ目の原因は、スコアが閾値を超えてから営業に連絡するまでのラグで、検討を競合に取られることです。なぜなら、検討が高まった瞬間は競合も狙っており、連絡までの数日の遅れが、そのまま機会損失につながるからです。
スコアが基準に達しても、それを人が確認し、担当を割り振り、連絡するまでには時間がかかります。その間に、競合が先に接触して候補として定着してしまうのです。検討がピークに達したタイミングを逃すと、挽回は難しくなります。
たとえば、このERP企業では、アカウントのスコアが基準に達していたにもかかわらず、営業への連絡が数日遅れ、その間に競合の商談が進んでいたことがありました。連絡までのラグが、商談機会を奪っていたのです。
このように、閾値超過から連絡までのラグで競合に取られることが、3つ目の原因になります。
静的で足りる？エンゲージメントスコアを動かす仕組み
3つの原因の根にあるのは、ハンドオフの基準となるスコアがアカウントの実態を映せていないという一点。ここを解決するのが、スコアを静的から動的へと変えるAgentic CRMです。Agentic CRMとは、AIエージェントがCRM上で自律的に判断・行動する仕組みのことです。そこでここでは、静的スコアを動的スコアに変える3つの仕組みを解説します。
Agentic CRMは、購買シグナルを取り込む動的スコアへの転換・DMU単位での集約・閾値を超えた瞬間の自律アラートという3つの仕組みで、ハンドオフのタイミングを捉えます。
下の表で、静的スコアと動的スコアの違いを整理します。
| 観点 | 静的スコア（従来） | 動的スコア（Agentic CRM） |
|---|---|---|
| 評価の対象 | 業種・企業規模・訪問回数など固定的な属性 | 購買シグナルをリアルタイムに反映する |
| 集計の単位 | リード単位 | DMUを含むアカウント単位 |
| 更新のタイミング | 定期・手動 | 行動が起きるたびに自動 |
| ハンドオフ | 担当者の感覚 | 閾値超過で自律アラート |
仕組み①業種・訪問回数の静的スコアから購買シグナルをリアルタイム統合した動的スコアへ転換する
1つ目の仕組みは、業種や訪問回数といった静的なスコアから、購買シグナルをリアルタイムに統合した動的なスコアへ転換することです。なぜこの転換が要るかというと、固定的な属性だけでは、そのアカウントが今どれだけ検討を深めているかを捉えられないからです。
業種や企業規模、訪問回数は、時間が経っても大きくは変わりません。一方、価格ページを見た、ROI試算書をダウンロードしたといった購買シグナルは、検討の高まりを直接示します。この動きをスコアに取り込むことで、今まさに検討が進んでいるアカウントが浮かび上がります。
たとえば、このERP企業では、これまで業種と訪問回数だけで付けていたスコアに、価格ページの閲覧や資料請求といった購買シグナルを加えました。固定的だったスコアが、検討の高まりに応じて動くようになったのです。
このように、購買シグナルを取り込んだ動的スコアへの転換が、最初の仕組みになります。
仕組み②DMUメンバー全員の行動データをアカウント単位に集約してスコアを算出する
2つ目の仕組みは、DMUメンバー全員の行動データを、アカウント単位に集約してスコアを算出することです。なぜなら、ABMの意思決定はアカウント全体で進むため、個々のメンバーよりも、アカウントとしての検討温度を測る必要があるからです。
使用者、起案者、承認者といったDMUの各メンバーの行動を、一つのアカウントのスコアとしてまとめます。誰か一人だけでなく、複数のメンバーが同時に動いているかどうかが、アカウント全体の温度として見えるようになります。
たとえば、このERP企業では、これまで担当者ごとにばらばらだったスコアを、アカウント単位で集約するようにしました。決裁者と現場担当が同時に動き始めたアカウントを、検討が高まったものとして捉えられるようになったのです。
このように、DMU全員の行動をアカウント単位に集約することが、2つ目の仕組みになります。
仕組み③スコアが閾値を超えた瞬間にAIが担当営業へ自律アラートを送信する
3つ目の仕組みは、スコアが閾値を超えた瞬間に、AIが担当営業へ自律的にアラートを送信することです。なぜ効くかというと、人が確認して連絡する工程を挟まず、検知がそのまま通知につながることで、閾値超過から連絡までのラグをなくせるからです。
アカウントのスコアが基準に達した時点で、AIが担当営業へ即座に通知します。人の手を介さないため、検討がピークに達した瞬間を逃しません。判断を機械へ移す考え方の全体像はエージェンティックAIの記事で扱っています。短縮の幅は運用の形で変わるため、自社の導入前の初動までの時間を先に測っておいてください。
たとえば、このERP企業では、アカウントのスコアが閾値を超えた瞬間に、担当営業へ自動で通知が届くようにしました。数日遅れていた初動が、検知と同時に動き出すようになったのです。
このように、閾値を超えた瞬間の自律アラートが、3つ目の仕組みになります。
ABMエンゲージメントスコアの設計方法
動的スコアの仕組みがわかっても、その中身をどう設計するかが問われます。スコアの精度を決めるのは、閾値・ウェイト・ポイントの設計です。そこでここでは、ABMエンゲージメントスコアの設計方法を、3つの観点から解説します。
スコア設計の核は、過去の商談化案件から閾値を逆算し、DMUの役割別にウェイトを変え、購買シグナルの種類別にポイントを設定することです。
設計①過去の商談化案件からエンゲージメントパターンを逆算して閾値を決める
1つ目は、過去に商談化した案件のエンゲージメントパターンを逆算して、閾値を決めることです。なぜこの逆算が有効かというと、実際に商談へ進んだアカウントが、その直前にどれだけのスコアに達していたかを見れば、渡すべき水準を根拠をもって定められるからです。
過去の商談化案件が、ハンドオフの直前にどんな行動を積み重ねていたかを分析します。その水準を閾値の出発点にします。初期値は、最高スコアの60〜70%あたりから始め、運用しながら3か月ほどかけて調整するのが現実的です。高すぎれば渡す機会を逃し、低すぎれば早すぎるハンドオフが増えます。指標を実績から決める手順はKPI設計の記事でも扱っています。
たとえば、このERP企業では、過去に受注に至ったアカウントのスコア推移を分析し、商談化の直前に達していた水準の60%を初期の閾値に置きました。その後の結果を見ながら、3か月かけて閾値を調整したのです。
このように、過去の商談化案件から閾値を逆算することが、最初の設計になります。
設計②DMUの役割別にスコアのウェイトを設定する
2つ目は、DMUの役割別に、スコアのウェイトを設定することです。なぜ役割で重みを変えるかというと、同じ行動でも、それが誰の動きかによって、商談化への意味合いが大きく変わるからです。
決裁権を持つ承認者が価格ページを見る動きは、現場の起案者が同じページを見るよりも、購買が近づいたシグナルになります。役割ごとにウェイトを設定し、たとえば承認者の閲覧には起案者の2倍のポイントを付与する、といった重みづけをします。役割の重みが、アカウントの温度をより正確に映します。買い手の側で検討がどう進むかは購買体験の記事で扱っています。
たとえば、このERP企業では、承認者の行動に高いウェイトを置き、決裁層が動いたアカウントのスコアが大きく上がるよう設計しました。誰が動いたかが、スコアに反映されるようになったのです。
このように、DMUの役割別にスコアのウェイトを設定することが、2つ目の設計になります。
設計③購買シグナルの種類別にポイントを設定する
3つ目は、購買シグナルの種類別に、ポイントを設定することです。なぜ種類で分けるかというと、行動によって購買意欲の強さが異なり、すべてを同じ点数で扱うと、検討の深さを見誤るからです。
概要資料の閲覧と、価格ページの複数回の閲覧やROI試算書のダウンロードでは、示す関心の深さが違います。購買に近いシグナルほど高いポイントを設定します。価格ページの閲覧、ROI試算書のダウンロード、デモページの複数回の閲覧といった、決裁に近い行動を重く見積もります。
たとえば、このERP企業では、価格ページやROI試算書への接触に高いポイントを置き、デモページを繰り返し見たアカウントのスコアが伸びるよう設計しました。行動の重みが、スコアに織り込まれたのです。
このように、購買シグナルの種類別にポイントを設定することが、3つ目の設計になります。
場面3選｜ABMの営業ハンドオフが自律化するとき
スコアを設計したら、それをもとに営業ハンドオフをどう自律化するのかが見えてきます。Agentic CRMは、スコアの変化を捉えて営業とマーケティングをつなぎます。そこでここでは、営業ハンドオフを自律化する場面を、3つ紹介します。
Agentic CRMは、閾値超過の自律通知・DMU接触履歴の自動サマリー・未フォロー時の自律エスカレーションという3つの場面で、ハンドオフを自律化します。
場面①アカウントスコアが閾値を超えた瞬間にAIが担当営業にSlack・メールで自律通知する
1つ目の場面は、アカウントのスコアが閾値を超えた瞬間に、AIが担当営業へSlackやメールでリアルタイムにアラートを自律通知することです。なぜ効くかというと、検討がピークに達した瞬間に営業が動ければ、競合より先に接触できるからです。
スコアが基準を超えたら、AIが担当営業の使うチャネルへ即座に通知します。営業は、どのアカウントが今動くべき相手かを、自分でリストを確認しなくても把握できます。閾値超過から連絡までのラグが、なくなります。
たとえば、このERP企業では、あるターゲットアカウントのスコアが閾値を超えた瞬間に、担当営業のSlackへ自動で通知が届くようにしました。以前は数日遅れていた初動が、その日のうちに動き出すようになったのです。
このように、閾値超過の瞬間の自律通知が、最初の場面になります。
場面②通知と同時にAIがDMUの接触履歴・閲覧コンテンツ・スコア推移を自動サマリーして送る
2つ目の場面は、通知と同時に、AIがDMUの接触履歴・閲覧コンテンツ・スコア推移を自動でサマリーして送ることです。なぜ役立つかというと、営業が通知を受けてから状況を調べ直していては、その分の時間が初動の遅れになるからです。
誰が、どのコンテンツを見て、スコアがどう推移したのか。AIがこの情報をまとめ、通知にあわせて送ります。営業は、アカウントの検討状況を把握したうえで、すぐに的確なアプローチに入れます。準備の手間なく、最初の接触の質を高められます。
たとえば、このERP企業では、通知と同時に、そのアカウントのDMUの誰がどの資料を見たかというサマリーが営業へ届くようにしました。営業は状況を調べ直すことなく、相手に合わせた提案から接触を始められるようになったのです。
このように、接触履歴とスコア推移の自動サマリーが、2つ目の場面になります。
場面③営業がフォローしないまま一定期間経過したらAIがマネージャーへ自律エスカレーションする
3つ目の場面は、営業がフォローしないまま一定期間が経過したら、AIがマネージャーへ自律的にエスカレーションすることです。なぜ必要かというと、せっかくの通知も、営業が動かなければハンドオフは完了せず、機会損失につながるからです。
通知を受けた営業が、多忙などの理由でフォローできないこともあります。一定の期間フォローがなければ、AIがマネージャーへ知らせ、対応を促します。通知が放置されて商談機会が消える事態を防げます。動かないまま時間が過ぎる案件の拾い方はパイプラインの停滞の記事でも扱っています。
たとえば、このERP企業では、通知から一定期間フォローのないアカウントを、AIがマネージャーへ自動で知らせるようにしました。対応の抜けが、仕組みとして拾われるようになったのです。
このように、未フォロー時の自律エスカレーションが、3つ目の場面になります。以上が、Agentic CRMがABMの営業ハンドオフを自律化する3つの場面でした。
ABMの営業連携のSLA設計手順
自律化の場面を見てきましたが、営業とマーケティングが安定して連携するには、両者の約束事を設計しておく必要があります。それが、営業とマーケの合意であるSLAです。そこでここでは、ABMの営業連携にAgentic CRMを取り入れたSLAの設計方法を、3つの観点から解説します。
SLAの設計は、ハンドオフ条件をスコア閾値とDMUへの到達本数で定義し、フォロー期限をCRMのルールで強制し、結果をスコアに戻すループを組むことです。
SLA①マーケから営業へのハンドオフ条件を「スコア閾値＋DMUへの到達本数」で定義する
1つ目は、マーケティングから営業へのハンドオフ条件を、「スコア閾値＋DMUへの到達本数」で定義することです。なぜ2つの条件を組み合わせるかというと、スコアの高さだけでは、アカウント全体で検討が広がっているかまでは判断できないからです。
スコアが閾値を超えていることに加えて、DMUのうち何人のメンバーに接触できているかを条件に加えます。たとえば「スコアが閾値以上、かつDMUの3名以上に到達」といった形で、渡す条件を明文化します。温度と広がりの両方を満たしたアカウントだけを、営業へ渡します。ツール設定ではなく業務設計から入ってほしい場合は、この条件を先に決めているかを支援先に確かめてください。部門をまたぐ約束事の設計はRevOpsの記事で扱っています。
たとえば、このERP企業では、スコアの閾値に加えて、DMUの複数メンバーへの到達をハンドオフの条件に加えました。一人だけが動いているアカウントを早く渡しすぎることが、なくなったのです。
このように、スコア閾値とDMU到達本数でハンドオフ条件を定義することが、最初のSLA設計になります。
SLA②営業フォローまでの期限をCRMのフロールールで強制する
2つ目は、営業がフォローするまでの期限を、CRMのフロールールで強制することです。なぜ強制まで組むかというと、期限を口頭の約束にとどめると、多忙のなかで守られず、ハンドオフが形だけになるからです。
渡したアカウントに、いつまでにフォローするかの期限を設定し、その期限をCRMの自動ルールで管理します。期限が近づけばリマインドし、過ぎればエスカレーションする、という流れを仕組みにします。約束が仕組みとして守られるようになります。
たとえば、このERP企業では、ハンドオフから一定時間以内のフォローを、CRMのルールで管理するようにしました。フォロー期限が、担当者の意識任せから仕組みによる管理へと変わったのです。
このように、フォロー期限をCRMのルールで強制することが、2つ目のSLA設計になります。
SLA③営業フォロー結果をCRMに記録してスコアを補正するフィードバックループを設計する
3つ目は、営業のフォロー結果をCRMに記録し、その結果をスコアの補正に返すフィードバックループを設計することです。なぜループを組むかというと、渡したアカウントが実際に商談化したかどうかを、次のスコアリングの精度向上につなげられるからです。
営業がフォローした結果、商談になったのか、まだ早かったのかをCRMに記録します。その結果を分析し、閾値やウェイトの調整に反映します。渡した判断の当たり外れが、次の基準づくりに活かされます。この繰り返しが、スコアの精度を継続的に高めます。
たとえば、このERP企業では、営業のフォロー結果を記録し、早すぎたハンドオフが多かったシグナルのポイントを見直しました。結果がスコア設計に戻ることで、判断の精度が上がっていったのです。
このように、フォロー結果をスコアに返すフィードバックループの設計が、3つ目のSLA設計になります。
ABMの営業連携にAgentic CRMが機能する企業の条件
SLAまで設計できると、Agentic CRMによる営業連携が機能する企業の条件が見えてきます。まずは、機能する企業の特徴を整理しましょう。そこでここでは、機能する企業の特徴を、3つ挙げます。
機能するのは、DMUマッピングとコンテンツ配信が完成してエンゲージメントデータが蓄積され、営業とマーケが共通の評価軸を持ち、過去の商談データで閾値を逆算できる企業です。
特徴①ターゲットアカウントのDMUマッピングとコンテンツ配信が完成してエンゲージメントデータがCRMに蓄積されている
1つ目の特徴は、ターゲットアカウントのDMUマッピングとコンテンツ配信が完成し、エンゲージメントデータがCRMに蓄積されていることです。なぜなら、営業ハンドオフのスコアは、DMUの各メンバーの行動データの上に成り立つからです。
誰がDMUのどの役割かが定まり、その各メンバーへコンテンツを配信できていて初めて、行動データが集まります。そのデータがCRMに蓄積されている企業は、動的スコアリングの前提がすでに整っています。
たとえば、このERP企業も、DMUマッピングと役割別の配信を済ませ、行動データがCRMに蓄積されていました。前段が整っていたからこそ、ハンドオフのスコアリングに進めたのです。
このように、エンゲージメントデータが蓄積されていることが、機能する最初の特徴になります。
特徴②営業とマーケが共通のターゲットリストと評価軸を持っている
2つ目の特徴は、営業とマーケティングが、共通のターゲットリストと評価軸を持っていることです。なぜなら、ハンドオフのSLAは、両者が同じ基準でアカウントを見ていることを前提にするからです。
マーケが有望と考えるアカウントと、営業が追いたいアカウントがずれていては、渡しても受け取ってもらえません。共通のターゲットリストと、何をもって渡すかの評価軸をそろえている企業は、SLAを機能させられます。両者の目線が合っていることが前提になります。
たとえば、このERP企業では、営業とマーケが同じターゲットリストを共有し、ハンドオフの基準も一緒に決めていました。両者の評価軸がそろっていたことが、連携の前提になったのです。
このように、営業とマーケが共通の評価軸を持っていることが、2つ目の特徴になります。
特徴③過去の商談データが十分にあって閾値を逆算できる状態にある
3つ目の特徴は、過去の商談データが十分にあり、閾値を逆算できる状態にあることです。なぜなら、スコアの閾値は、過去に商談化した案件のパターンから逆算して初めて、根拠のある水準になるからです。
過去の受注や商談化の記録が一定量あれば、商談の直前にどんなスコアに達していたかを分析できます。このデータがある企業は、感覚に頼らず、データに基づいて閾値を置けます。逆に、商談データが乏しければ、逆算の材料が足りません。
たとえば、このERP企業では、これまでの商談化案件の記録が十分にあり、そこからハンドオフの水準を逆算できました。過去のデータが、閾値設計の根拠になったのです。
このように、過去の商談データで閾値を逆算できることが、3つ目の特徴になります。
ABMの営業連携を急がなくてよい企業の特徴
一方で、今の段階では急ぐべきでない企業もあります。前提が整わないまま進めても、スコアも連携も機能しません。そこでここでは、急ぐべきでない企業の特徴を、3つ挙げます。
エンゲージメントデータが蓄積されていない、営業とマーケが別々の目標を持っている、ターゲットが少なくデータ量が足りない企業は、まず前提を整えることが先になります。
特徴①エンゲージメントデータが蓄積されておらずスコアリングの精度が出ない
1つ目の特徴は、エンゲージメントデータが蓄積されておらず、スコアリングの精度が出ないことです。なぜ急ぐべきでないかというと、動的スコアはDMUの行動データを材料にするため、そのデータがなければスコア自体が成り立たないからです。
DMUマッピングやコンテンツ配信がまだ整っておらず、各メンバーの行動が記録されていなければ、スコアリングの材料が足りません。まずは前段のマッピングと配信を整え、行動データを蓄積することが先になります。
たとえば、行動データがほとんど蓄積されていない企業では、スコアを設計しても精度が出ません。この段階では、ハンドオフの自律化より、データの蓄積が優先です。
このように、エンゲージメントデータが蓄積されていないことが、急ぐべきでない最初の特徴になります。
特徴②営業とマーケが別々の目標を持っていてSLAを設計できる関係にない
2つ目の特徴は、営業とマーケティングが別々の目標を持っていて、SLAを設計できる関係にないことです。なぜなら、SLAは両者が同じ成果を目指す約束であり、目標が食い違っていては合意が成り立たないからです。
マーケがリード数を、営業が受注額を、それぞれ別に追っていると、ハンドオフの基準で折り合えません。まずは共通の目標をそろえ、連携できる関係を築くことが先になります。関係が整わないうちに仕組みだけ入れても、機能しません。
たとえば、営業とマーケが対立しがちで目標も別々の企業では、SLAの合意にたどり着けません。この段階では、両部門の目標のすり合わせが優先です。定着まで伴走してほしい場合は、目標のすり合わせから入れる相手かどうかを見ます。
このように、SLAを設計できる関係にないことが、2つ目の特徴になります。
特徴③ターゲットアカウントが少なくAIの判断基準を作れるデータ量がない
3つ目の特徴は、ターゲットアカウントが少なく、AIの判断基準を作れるデータ量がないことです。なぜなら、閾値やウェイトの設計は、一定量のアカウントと商談データがあって初めて、精度を持つからです。
対象のアカウントや過去の商談が少なければ、AIが基準を逆算する材料が足りません。スコアの閾値も安定せず、判断の精度が出ません。まずはターゲットの母数と商談データを積み上げることが先になります。
たとえば、ターゲットアカウントがごく少数の企業では、AIが判断基準を作るためのデータが不足します。データ量が積み上がるまでは、無理に進めても効果は限られます。
このように、判断基準を作れるデータ量がないことが、3つ目の特徴になります。
どこから始める？営業ハンドオフ自律化の5ステップ
機能する条件を満たしているなら、いよいよ実装です。ABMの営業ハンドオフの自律化は、CRMのフィールド設計から、閾値の算出、通知フローの構築、フィードバックループまで、順を追って構築します。そこでここでは、実装する5つのステップを解説します。
実装は、スコアとシグナルと期限のフィールド追加・閾値の算出・ポイントとウェイトの設定・通知フローの構築・フィードバックループの設計という5ステップで進みます。
ステップ①CRMのアカウントオブジェクトにDMUスコア・購買シグナル・フォロー期限フィールドを追加する
1つ目のステップは、CRMのアカウントオブジェクトに、DMUスコア・購買シグナル・フォロー期限のフィールドを追加することです。なぜ最初かというと、AIが判断の根拠にするこれらのデータを、記録する箱をまず用意する必要があるからです。
具体的には、アカウントに、数値型の「DMUエンゲージメントスコア」、直近の購買シグナルを記録する選択リスト型の「購買シグナル種別」、日付型の「フォロー期限」、そしてハンドオフの進捗を管理する選択リスト型の「ハンドオフステータス」（未通知・通知済・フォロー済・エスカレーション済）を設けます。あわせて、コンタクト単位のスコアをアカウントへ合算するロールアップの仕組みを用意し、DMU全体のスコアがアカウントに集約されるようにします。
たとえば、このERP企業では、アカウントにこれらのフィールドを設け、DMUメンバーのスコアがアカウントへ自動で集約される形を整えました。AIが参照するデータの入れ物を、最初に用意したのです。小さく始めたい場合は、この4つのフィールドを足すところまでを最初の範囲にします。
このように、アカウントへのスコア・シグナル・期限のフィールド追加が、最初のステップになります。
ステップ②過去の商談化案件のエンゲージメントパターンをAIで分析してスコア閾値を算出する
2つ目のステップは、過去の商談化案件のエンゲージメントパターンをAIで分析し、スコアの閾値を算出することです。なぜ分析から入るかというと、閾値は感覚で決めず、実際に商談化した案件のデータから逆算して初めて、根拠を持つからです。
具体的には、過去に受注や商談化に至ったアカウントが、ハンドオフの直前にどのスコアに達していたかの分布をAIで分析します。その分布から、商談化アカウントが共通して超えていた水準を見つけ、最高スコアの60〜70%あたりを初期の閾値に置きます。この初期値を、運用しながら3か月ほどかけて調整します。
たとえば、このERP企業では、過去の商談化アカウントのスコア分布を分析し、その多くが超えていた水準を初期閾値に設定しました。データに基づく閾値を、出発点に置けたのです。
このように、過去のデータからスコア閾値を算出することが、2つ目のステップになります。
ステップ③購買シグナル別ポイントとDMU役割別ウェイトをAIスコアリングルールに設定する
3つ目のステップは、購買シグナル別のポイントと、DMUの役割別のウェイトを、AIのスコアリングルールに設定することです。なぜこの設定が肝かというと、スコアの中身が、このポイントとウェイトの組み合わせで決まるからです。
具体的には、シグナルの種類ごとにポイントを定めます。たとえば、価格ページの閲覧やROI試算書のダウンロードには高いポイントを、概要資料の閲覧には低いポイントを割り当てます。あわせて、役割別のウェイトを設定し、承認者の行動には起案者の2倍を掛ける、といった重みづけをします。アカウントのスコアは、各メンバーの「シグナルのポイント×役割のウェイト」を合算して算出する形にします。
たとえば、このERP企業では、価格ページやROI試算書に高いポイントを、承認者の行動に高いウェイトを設定しました。決裁層が購買に近い行動を取ると、スコアが大きく上がる形になったのです。
このように、シグナル別ポイントと役割別ウェイトの設定が、3つ目のステップになります。
ステップ④スコア閾値到達をトリガーにした担当営業への自動通知フローをCRMで実装する
4つ目のステップは、スコアの閾値到達をトリガーにした、担当営業への自動通知フローをCRMで実装することです。なぜフローまで組むかというと、閾値の判定を、実際に営業へ届く通知へつなげて初めて、ハンドオフが自律的に動くからです。
具体的には、アカウントのスコアが閾値に達したことをトリガーに、CRMのフロー機能で、担当営業へSlackやメールで通知します。あわせて、DMUの接触履歴やスコア推移のサマリーを生成して添え、フォロー期限を自動でセットします。期限を過ぎてもフォローがなければ、マネージャーへエスカレーションする分岐も組み込みます。
たとえば、このERP企業では、閾値の到達から未フォロー時のエスカレーションまでを一連のフローとして実装しました。通知・サマリーの添付・期限の設定が、その途中に並びます。ハンドオフが、人手を介さず動くようになったのです。
このように、閾値到達をトリガーにした通知フローの実装が、4つ目のステップになります。
ステップ⑤営業フォロー結果をCRMに記録してスコア精度を継続改善するフィードバックループを設計する
5つ目のステップは、営業のフォロー結果をCRMに記録し、スコアの精度を継続的に改善するフィードバックループを設計することです。なぜ最後に組むかというと、渡した判断の結果を次の基準づくりに返して初めて、スコアの精度が上がり続けるからです。
具体的には、フォローの結果が商談化したのか、早すぎたのかを記録するフィールドを設け、その結果を定期的に分析します。早すぎたハンドオフが多いシグナルはポイントを下げ、商談化に強く効いたシグナルはポイントを上げる、といった調整を繰り返します。この見直しのサイクルを運用に組み込みます。
たとえば、このERP企業では、フォロー結果を毎月振り返り、閾値やポイントを調整する運用にしました。渡した判断の結果が、次のスコア設計に反映される形ができたのです。自社で構築するので設計レビュー・アドバイザリーだけ頼みたい場合も、このループの組み方は外部の目を入れる価値があります。
このように、フォロー結果を返すフィードバックループの設計が、5つ目のステップになります。以上が、Agentic CRMでABMの営業ハンドオフを自律化する5つのステップでした。
ABMの営業連携で追うフェーズ別KPI
実装できたら、次はその成果をどう測るかです。成果は、導入の段階によって見るべき指標が変わります。そこでここでは、フェーズ別のKPIを3段階で整理します。
KPIは、導入期は閾値到達から営業フォローまでのリードタイム、活用期はハンドオフ後の商談化率、成果期はターゲットアカウントの受注率と平均案件単価で測ります。
フェーズ①導入期：スコア閾値到達から営業フォローまでのリードタイムで測る
導入期は、スコア閾値の到達から、営業がフォローするまでのリードタイムで測ります。なぜなら、この段階で確かめるべきは、ハンドオフのラグが実際に縮まっているかだからです。
閾値を超えてから営業が接触するまでの時間を見ます。この時間が短くなっていれば、自律通知の仕組みが機能している証拠になります。数日かかっていた初動が、どこまで縮まったかを追います。リードタイムの短縮は、ハンドオフの自律化が最初に表れる成果でもあります。
たとえば、このERP企業では、閾値到達からフォローまでのリードタイムを追い、導入前と比べて短縮したかを確認しました。ハンドオフの速さを、リードタイムで測ったのです。
このように、導入期はフォローまでのリードタイムで測ります。
フェーズ②活用期：ハンドオフ後の商談化率をABM非対象アカウントと比較して測る
活用期は、ハンドオフ後の商談化率を、ABMの非対象アカウントと比較して測ります。なぜ比較するかというと、動的スコアによるハンドオフの効果を、対象と非対象の差として捉えられるからです。
ハンドオフしたアカウントが、どれだけ商談化したかを見ます。ABMの非対象アカウントと比べて商談化率が高ければ、スコアリングとハンドオフの設計が効いていると判断できます。比べる相手を決めずに前年との比較だけで見ると、市況の影響と切り分けられません。
たとえば、このERP企業では、ハンドオフしたアカウントの商談化率を、非対象と比較して追いました。設計の効果を、比較のなかで確かめたのです。
このように、活用期はハンドオフ後の商談化率で測ります。
フェーズ③成果期：ターゲットアカウントの受注率と平均案件単価で測る
成果期は、ターゲットアカウントの受注率と、平均案件単価で測ります。なぜこの2つかというと、ABMの狙いは、狙ったアカウントを受注につなげ、かつ大きな取引へ広げることだからです。
ターゲットアカウントの受注率と、受注した案件の平均単価を見ます。適切なタイミングでのハンドオフが積み重なれば、受注率が上がり、関係を深めた分だけ案件単価も高まります。771名のマーケターに尋ねた調査では、ABMプログラムの推定平均ROIは137%と報告されています（Outcomes Rocket「State of Account-Based Marketing 2025」・2026年4月公開）。自己申告にもとづく推定値のため、自社の水準は実額で確かめてください。
※参考記事はこちら
たとえば、このERP企業では、実装から半年で、ターゲットアカウントの受注率が約18%から約27%へ高まり、平均案件単価も約2割上がりました。「渡すタイミングのばらつきをなくし、狙ったアカウントを確実に受注につなげたい」という当初の狙いが、数字となって表れたのです。フェーズ別のKPIを体系的に設計したい場合は、BtoBマーケティングのKPI設計の記事で扱っています。
このように、成果期はターゲットアカウントの受注率と平均案件単価で測ります。
Agentic CRMを使ったABMの営業連携自動化の費用感
成果の測り方まで押さえたら、費用の全体像も確認しておきましょう。費用は、大きく3つの要素に分かれます。そこでここでは、費用感を3つの観点から整理します。
費用は、CRMのAIスコアリング機能のライセンス・スコアリング設計とフロー構築の外部支援・SLAモニタリングの継続運用という3つの要素で考えます。
費用①CRMのAIスコアリング機能のライセンス費用の目安
1つ目は、CRMのAIスコアリング機能のライセンス費用です。これは、契約するエディションや利用規模によって変わります。なぜなら、AIによるスコアリングを利用できるエディションや、必要なユーザー数によって、前提となる契約が変わるからです。
すでにCRMを使っている企業であれば、既存の契約に、AIスコアリング機能を利用するための費用を見込む形になります。まず自社の契約がその機能に対応しているかを確認し、そのうえで見積もりを取ります。
たとえば、このERP企業では、契約中のCRMでAIスコアリングが使えるかを確認し、必要なライセンスを追加する前提で費用を見積もりました。既存の契約を起点に試算したのです。
このように、ライセンス費用は自社の契約状況をもとに見積もります。
費用②スコアリング設計・フロー構築にかかる外部支援費用の目安
2つ目は、スコアリング設計とフロー構築にかかる外部支援の費用です。これは、閾値の算出やポイント設計、通知フローの実装のどこを外部に任せるかで変わります。なぜなら、実装の範囲と自社の体制によって、必要な工数が変わるからです。
過去データの分析や閾値の逆算、フローの構築を自社で担えれば、外部支援は限られた範囲で済みます。スコアリングルールの設計やフィードバックループの構築といった専門性の高い部分だけを支援に任せる、という切り分けも有効です。
たとえば、このERP企業では、閾値の算出とフロー構築の部分に絞って外部支援を受け、運用は自社で担いました。支援の範囲を絞ることで、費用を抑えたのです。
ソリューション営業に特化した支援がほしい場合は、商談の進み方を踏まえて範囲を切れる相手かどうかを見ます。当社のAgentic CRM設計支援では無料相談も受け付けています。詳しくはAgentic CRM設計支援をご覧ください。
このように、設計・構築の費用は任せる範囲を絞ることで調整できます。
費用③SLAモニタリングの継続運用コストの目安
3つ目は、SLAのモニタリングにかかる継続運用のコストです。これは、フォロー状況やスコアの精度を、どの頻度で誰が確認するかによって変わります。なぜ継続的にかかるかというと、SLAは設計しただけでは終わらず、守られているかを監視し続ける必要があるからです。
ハンドオフが基準どおりに動いているか、フォロー期限が守られているか、スコアの精度が保たれているかを、定期的に確認する作業には人の工数がかかります。自社のマーケティングや営業推進の担当が担うのか、外部に委託するのかで、費用の形が変わります。運用にかかるコストも、あらかじめ見込んでおく必要があります。
たとえば、このERP企業では、SLAのモニタリングを自社の営業推進の担当が担う体制にし、継続的な運用コストを人の工数として見込みました。運用の負担を、あらかじめ計画に織り込んだのです。
このように、SLAモニタリングの運用コストは体制に応じて見込みます。
【一問一答】ABMにAgentic CRMを活用した営業連携でよくある質問
最後に、ABMにAgentic CRMを活用した営業連携について、検索されやすい疑問に簡潔にお答えします。導入検討で気になる点から順に整理します。
エンゲージメントスコアの閾値は過去の商談化案件から逆算し、フィードバックループを回しながら精度を高めるのが基本です。
質問①エンゲージメントスコアの閾値はどう決めるか
過去に商談化した案件が、ハンドオフの直前にどのスコアに達していたかを逆算して決めます。感覚で置かず、実際に商談へ進んだアカウントの水準を根拠にします。初期値は最高スコアの60〜70%あたりから始め、運用しながら3か月ほどかけて調整するのが現実的です。
質問②過去の商談データが少ない場合の閾値設定はどうするか
逆算の材料が乏しい場合は、まず暫定の閾値を低めに置いて早めにハンドオフし、その結果をこまめに記録してデータを集めるのが現実的です。このERP企業も、商談化の直前に達していた水準の60%を初期の閾値に置いています。フィードバックループを回しながら、蓄積された結果をもとに閾値を上げていきます。データがそろうまでは、精度より学習を優先する進め方が向いています。
質問③SLAを設けても営業が動かない場合どう対処するか
まず、フォロー期限をCRMのルールで管理し、期限を過ぎたらマネージャーへ自動でエスカレーションする仕組みを組みます。このERP企業では、実装から半年でターゲットアカウントの受注率が約18%から約27%へ動いており、仕組みと合意の両方がそろってからの変化でした。そのうえで、根本的には営業とマーケティングが共通の目標を持ち、ハンドオフの基準に合意していることが欠かせません。仕組みと合意の両面から、動かない状態を防ぎます。
質問④スコアリングの精度が上がるまでどのくらいかかるか
フィードバックループを回しながら、3か月程度を目安に調整していくのが現実的です。ハンドオフの結果を記録し、早すぎたシグナルや効いたシグナルを見直すたびに、スコアの精度は上がっていきます。一度で完成させるより、運用のなかで継続的に高めていくものと捉えるのが確実です。
質問⑤ABMの営業連携でCRM以外に必要なツールはあるか
行動データを取得するMA（マーケティングオートメーション）が前提になります。DMUの各メンバーの閲覧や反応をMAで捉え、それをCRMに統合してスコアリングします。このERP企業も、この組み合わせで平均案件単価が約2割上がりました。あわせて、営業へ通知するためのSlackやメールといったチャネルもCRMと連携させます。必要に応じて、外部の検討行動を捉えるインテントデータを組み合わせる場合もあります。
ABMの営業ハンドオフはAgentic CRMがエンゲージメントスコアを監視して閾値を超えた瞬間に自律アラートを送ることで機能する
ABMの営業ハンドオフは、Agentic CRMがエンゲージメントスコアを監視し、閾値を超えた瞬間に自律アラートを送ることで機能します。本記事では、ハンドオフがタイミングを逃す原因を整理し、スコアを静的から動的へ転換する仕組みから、スコアの設計、SLA、実装の5ステップ、KPIまで、一続きで整理してきました。
ABMでは、ターゲットを絞り、DMUに役割別のコンテンツを届けても、渡すタイミングがずれれば商談化を逃します。Agentic CRMは、DMU全員の行動をアカウント単位のスコアに集約し、購買シグナルを取り込んで動的に更新し、閾値を超えた瞬間に営業へ通知します。今回例に挙げたERP企業も、渡すタイミングのばらつきをなくしたことで、実装から半年でターゲットアカウントの受注率を約18%から約27%へ高め、平均案件単価も約2割高めました。
ABMの営業連携で成果を出す鍵は、渡すタイミングを担当者の感覚から、データに基づく動的なスコアへと移すことにあります。過去の商談から閾値を逆算し、DMUの役割で重みを変え、閾値超過を自律アラートにつなげる。この設計を整えれば、検討がピークに達した瞬間を逃さず、狙ったアカウントを確実に商談へつなげられるようになるでしょう。