フェーズを移行する前に、営業チームで取り決めた確認事項を営業担当がAIエージェントでセルフチェックする

著者：本田正憲 合同会社クロスコム 代表／Salesforce認定コンサルタント

「先方の反応も良かったし、もう次のフェーズに上げても大丈夫なはず」。商談のフェーズを変更するとき、営業担当なら一度はこう考えたことはありませんか？

多くの営業組織では、導入予定時期・決裁者・予算・顧客の課題とその背景・購買の関与者のように、フェーズごとに顧客に確認しておくべき事項を、営業チームや営業責任者と取り決めています。

しかし、取り決めた事項をすべて確認できているかは、営業担当が自分の商談メモを読み返して判断するしかありません。営業担当は、自分で書いた商談メモを分かっているつもりで読んでしまい（しかも、商談の感触が良いほど楽観的な見立てになり、、、）、聞き漏らしに気づけません。営業組織が必須項目でフェーズの変更を止める仕組みを入れても、営業担当は項目に何か入力すれば先に進めてしまうので、案件レビューで営業責任者に指摘されて初めて確認漏れに気づく営業担当も少なくないでしょう。

そこで本ユースケースでは、営業担当が商談オブジェクトのフェーズを変更する前に、AgentforceのAIエージェントを使って、取り決めた確認事項を確認できているかを客観的にセルフチェックする方法をご紹介します。

※本記事の画面や数値は、SalesforceのSandboxに用意した架空の商談データのものです。

ユースケース：AIエージェントが取り決めた確認事項と照合して不足情報を提示して、営業担当が次回商談で確認することを決める

このユースケースでは、以下の流れで進んでいきます。

1. 営業担当：商談のフェーズを移行する前に、商談レコード画面からエージェントに「この商談を見積提示に進める前に、確認が足りないところを教えて」と依頼する。
2. エージェント：事前に営業チーム内で取り決めた確認事項と商談レコードを照合し、確認した確認事項の件数と、レコード項目が空になっている「入力漏れ」、商談メモ（レコード項目「説明」）に文章は記載しているが確認事項が書かれていない「内容の不足」を、不足している確認事項ごとの次回商談での質問案とセットで提示する。
3. 営業担当：エージェントの回答を読み、商談レコード画面の関連リスト「商談確認結果」から確認画面を開き、不足している確認事項ごとに「確認する」か「該当なし」を選んで保存する。

Salesforceの裏側では、エージェントが依頼の文から確認タイミング（フェーズを進める前・次の商談の前・失注でクローズする前）と移行先のフェーズを読み取り、Apexのアクションを呼びます。そしてApexは、確認事項の中からその商談のフェーズと種別に当てはまるものを選び、項目が空かどうかと決裁者が登録されているかを確認します。プロンプトテンプレートは、商談メモと失注理由の詳細を読み、確認事項が書かれているかを根拠にあたる文章とセットで判定します。

そしてApexは、元の文章が商談メモに本当に書かれているかを確かめてから件数を数え、不足している確認事項を「商談確認結果」に保存して、回答の文を組み立てます。エージェントには、Apexが組み立てた文を書き直さずに表示するよう指示しています。

デモ動画：営業担当がフェーズを移行する前に確認事項をエージェントへ分析させて、不足情報と次回商談での質問案を受け取る

本ユースケース用に作ったエージェントの動きを、約96秒にまとめました。動画では次の3つの場面をご覧いただけます。

1. 商談レコードで、導入予定時期・予算の金額・決裁者は入力されているが、商談メモには顧客の課題と今のやり方しか書かれていないことを確認する
2. 見積提示に進める前の確認をエージェントに依頼して、内容の不足2件と質問案、書かれている確認事項とその元の文章を受け取る
3. 関連リスト「商談確認結果」から確認画面を開き、不足している確認事項ごとに次の商談で確認するかを選んで保存する

想定シーン：営業担当が、フェーズ移行の前と次回商談の前にエージェントへ確認を依頼する

本ユースケースでは、商談を担当する営業担当が使用することを想定しており、営業責任者が営業チームと取り決めた確認事項をもとに、以下の通り使うシーンとそれぞれエージェントに依頼する内容を設定しています。

営業担当にとって本ユースケースが有効なのは、「このフェーズに進む前に、取り決めた確認事項で顧客に聞き漏らしていることは無いか？」を確かめたいときです。商談を失注でクローズする前には、エージェントが、次の案件や分析に使うために失注理由に書くべき事項（失注の決め手、選ばれた先、顧客の課題がその後どうなったか）が書けているかを確認し、足りない事項と確認の質問案をセットで提示するので、営業担当は足りない事項を失注理由の詳細に書き足してから、失注でクローズできます。

課題：フェーズを移行する前に、取り決めた確認事項を確認できているかを客観的に確かめられない

営業担当が困っているのは、取り決めた確認事項を顧客へ確認しきれないままフェーズを移行し（失注でクローズすることも、フェーズの移行の1つです）、案件レビューや失注の後になって聞き漏らしに気づくことです。その原因は、大きく3つあると当社は考えています。

原因①フェーズを移行する理由が担当者の主観になっている

営業担当は、先方の反応や商談の雰囲気から、感覚でフェーズを上げるかどうかを決めることもあるのではないでしょうか。営業チーム内で取り決めた確認事項と商談メモを1つずつ照合するより、感触で判断する方が商談メモを見直す手間を省けるうえに、商談の感触が良いほど営業担当の見立てが楽観的になるからです。

そのため、同じ状況の商談でも、営業担当によってフェーズの上げ方が変わりますし、営業責任者は商談のフェーズを見ても、取り決めた確認事項がどこまで確認できているかを同じ解釈で理解することができません。

原因②レコード項目の詳細まで移行条件をシステムが分析できていない

Salesforceの必須項目や入力規則のシステム機能は、項目に値が入っているかどうかを確認します。しかし、商談メモのようなロングテキスト項目に、顧客の課題やその背景、購買の関与者が書かれているかまではシステム機能では分析しません。

そのため、営業担当が商談メモに1行だけ書いたり、レコード項目に何か値を入れたりしても、システムのチェックは通ってしまいます。

原因③フェーズ移行前に条件をチェックする仕組みがない

多くの営業組織では、営業担当がフェーズを変更する前に、営業チーム内で取り決めた確認事項を記載しているか確かめる手順がありません。確認事項を押さえているかは、営業担当がフェーズを変更した後に営業責任者が案件レビューで確認するのが一般的です。

しかし、営業責任者はすべての商談を見る時間は現実的にありません。そのため、営業責任者が確認漏れに気づくのは案件レビューや失注の後になり、そのときには営業担当が顧客に聞き直せないでしょう。

つまり、顧客へ確認事項を聞き漏らしてしまうのは、営業担当の注意が足りないからではなく、フェーズの移行基準が取り決めた確認事項に基づいておらず、ロングテキスト項目の内容を照合する手段も、移行の前に確かめる場面も無いからということです。

実装内容：AIエージェントが確認事項を照合して、不足している確認事項の情報を提示する

そこでAIエージェントは、営業担当が自分の商談レコードと商談メモを、営業チーム内で取り決めた確認事項と1つずつ照合する作業を代わりに行います。不足している確認事項と次回商談での質問案をセットで提示するので、営業担当は、フェーズを移行する前に確認できていない事項に自分で気づけるようになります。

具体的には、次の実装内容に基づいてAIエージェントを業務に組み込みます。

実装①取り決めた確認事項を、エージェントが照合できる形で設定する

営業責任者は、営業チームと取り決めた確認事項を、Salesforceの「商談確認基準」に1件ずつ設定します。そして、どのフェーズへ移行する前に確認するか、どの種別の商談に当てはまるか、何が書かれていれば確認済みとするか（判定の基準）と、確認事項が不足しているときに顧客へヒアリングする質問のひな形までを設定します。

たとえば、営業責任者は「施策提案に進める前に、導入予定時期と決裁者が入力され、商談メモに顧客の課題とその背景、購買の関与者が書かれていること」「新規の商談（種別が New Business の商談）では、顧客がその業務を今どの方法で行っているかが書かれていること」のように、何が入力・記載されていれば確認済みとするかを文章にして、確認事項を設定します。

そうすることで、営業担当は商談の感触ではなく営業チームで取り決めた確認事項にもとづいて、商談のフェーズを移行してよいかを判断できるようになります。

実装②エージェントが、レコード項目に加えて商談メモの中身も確認事項と照合して読み取る

つぎにApexは、確認事項で決めた項目が空かどうかと、商談の取引先責任者の役割に決裁者が登録されているかを確認し、空なら「入力漏れ」とします。この確認にはAIを使わないので、同じ商談レコードなら毎回同じ結果になります。

プロンプトテンプレートでは、商談メモと失注理由の詳細を読み、確認事項ごとに「書かれている」「書かれていない」「当てはまらない」のどれかを判定し、書かれている場合はその文章を抽出します。Apexは、抽出した文章が商談メモに本当に書かれているかを確認し、無ければ「内容の不足」として扱いますが、商談メモが空のときは、ApexはAIに読ませずに商談メモの「入力漏れ」として扱います（また、ユースケース「商談時の打合せメモを読み取り、商談レコードの項目値を自動で入力する」で作った商談項目の入力候補にだけ書かれている事項は、エージェントが商談メモへの転記を促します）。

そうすることで、営業担当はレコード項目に値が入っていても商談メモに書けていない確認事項、つまりシステムではチェックできなかった不足情報に気づけるようになります。

実装③フェーズを移行する前に、次回商談で確認することを選んで残す

営業担当がフェーズを移行する前にエージェントへ依頼すると、エージェントは不足している確認事項ごとに次回の商談で顧客にヒアリングする質問案をセットで提示してくれます。Apexは、発見した不足情報と、当てはまらないとした確認事項を「商談確認結果」として商談レコードに保存し、商談レコード画面の関連リスト「商談確認結果」に表示します。そして営業担当は、関連リストから確認画面を開き、不足情報の行ごとに「確認する」（次の商談で顧客に確認する）か「該当なし」（この商談には当てはまらない）を選んで保存します。

失注で商談レコードをクローズする前の確認では、エージェントは「失注理由の詳細」に不足している確認事項を提示し、営業担当は不足情報を書き足してから失注でクローズします。実際に確認画面で次回の商談で確認する事項を選ぶのは、フェーズを進める前と次の商談の前の確認だけです。

本ユースケースでは、不足している確認事項があってもフェーズの変更は止めません。項目の入力を必須にしてフェーズの変更を止めると、営業担当は何か値を入れて先に進めてしまううえに（原因②）、AIの読み取りにも誤りがあるためです。フェーズを移行するかを最後に決めるのは、これまでどおり営業担当です。

そうすることで、営業担当は、フェーズを変更する直前に確認できていない事項と次の商談で聞くことを決めてから移行できるようになります。

次の表は、エージェントの判定の基準と、回答での扱いを示しています。

エージェントが一度に確認するのは、営業担当が開いている商談レコード1件だけで、Apexは文章で確認する確認事項をまとめて1回でAIに渡します。確認事項を足す・変えるときは、営業責任者が「商談確認基準」のレコードを画面で編集するだけで、エージェントやApexを変える必要はありません。また、営業担当が商談メモを書き足した後に同じ依頼をすると、エージェントは書き足した後の内容で確認し直します。

活用データ：商談レコードの項目と商談メモ、取り決めた確認事項

今回のユースケースでエージェントが読むのは、商談レコードの項目と商談メモ・失注理由の詳細、商談の取引先責任者の役割、確認事項を設定した商談確認基準と、UC02 で作った商談項目の入力候補だけです。データごとの活用用途は以下の表にて示した通りです。

ここでは、活動履歴やメールは読みません。本ユースケースは、営業チーム内で取り決めた確認事項が商談レコードに書かれているかを確かめるためのものだからです。なお、導入予定時期・導入予定時期の確度・予算の金額・失注理由の詳細の項目は標準の商談に無いため、Sandboxの商談に新しく作りました。

人とAIの役割：照合作業はAIエージェントとプログラム、確認事項と次回商談で聞くことは人が決める

本ユースケースでは、人とAIの役割を次のように分けます。

つまり、エージェントが担うのは、営業チーム内で取り決めた確認事項と照合して、不足している確認事項と質問案をセットで提示するまでで、確認事項を決めるのも、次回商談で何を確認してからフェーズを移行するかを決めるのも人ということです。

業務変化：商談の感触で移行していたフェーズを、取り決めた確認事項と照合してから移行できるようになる

ここまでご紹介してきたユースケースを実装することで、営業担当がフェーズを移行するときの作業はどう変わるのでしょうか。

業務フローのBefore/After

本ユースケースで構築したエージェントの導入前と導入後で大きく変わることとしては、営業担当がフェーズを移行する判断の拠り所が「商談の感触」ではなく「営業チーム内で取り決めた確認事項と照合した結果」になることです。

営業担当が得られること

フェーズを移行する前のセルフチェックによって、営業担当は次の4つを得られます。

1. フェーズを移行する前に、取り決めた確認事項のうち確認できていないものが分かる
2. 不足している確認事項ごとに質問案をセットで提示されるので、次の商談で何を聞けばよいかがすぐに分かる
3. 商談メモに書いたつもりの事項でも書けていなければ不足している確認事項として提示されるので、自分の思い込みに気づける
4. 案件レビューで、営業責任者と同じ確認事項を前提に商談の状況を話せる

特に3つ目は、セルフチェックの意味そのものではないでしょうか。営業担当が自分の商談メモを読み返すと書いたつもりの事項を見落としますが、エージェントは取り決めた確認事項と照合して、レコードに書かれていない事項をそのまま提示するためです。

エージェント導入前に確かめたいこと

ただし、どの会社でもすぐに同じ結果が得られるわけではありません。本ユースケースは、確認事項を営業チームで取り決めていることと、営業担当が商談で聞いた内容を商談メモに書くことを前提にしています。自社で導入する際は、次の3点を確かめてください。

• 確認事項を、何が書かれていれば確認済みとするかまで言葉で取り決めているか？
  • 「課題の背景が書かれている」の判断が営業責任者の間でそろっていない場合は、AIでも判定が分かれる可能性があります。
  • 確認事項は、フェーズと種別ごとに判定基準と質問のひな形まで設定する必要があります。
• 営業担当が、商談で聞いた内容を商談メモに書いているか？
  • エージェントは、商談レコードのレコード項目「説明」と失注理由の詳細と、UC02で作った「商談項目の入力候補」だけを読みます。営業担当が活動履歴やメールにだけ書いている場合、エージェントは確認事項の不足として判断してその旨を提示します。
  • 商談メモが空の商談の場合、エージェントは商談メモの「入力漏れ」を提示することになります。
• AIの読み取りの誤りを前提に、最後は営業担当が判断する運用にできるか？
  • エージェントが客観的なのは、営業チーム内で取り決めた確認事項と照合するからです。しかし、AIの読み取りには誤りがあり、たとえばAIは「現場監督の時間が多く取られている」という課題の文章を、課題の背景が書かれていると読み取ることがあります。元の文章が商談メモにあるため、Apexでも誤りの確認ができません。
  • Apexが回答の文章を組み立てても、エージェントが表示するときに言い回しが変わることがあります。不足している確認事項の中身と営業担当の選択は商談確認結果に保存されるので、営業責任者は関連リスト「商談確認結果」を見る運用にしてください。
  • AgentforceのEinstein Trust Layerは、AIに渡す文の中のURLを別の文字に置き換えます（データマスキング）。そのため、エージェントは確認画面へのリンクを回答に書かず、営業担当は関連リスト「商談確認結果」から確認画面を開きます。

自社の商談データで試したい方へ

いかがだったでしょうか。クロスコムでは、Agentforceを使って、営業チームで取り決めた確認事項を営業担当が日々の商談でセルフチェックできる仕組みづくりをご支援しています。

たとえば今回の本ユースケースのように、以下の内容からご支援できます。

• 既存の商談メモに、取り決めた確認事項がどれだけ書かれているかの診断
• フェーズ・種別ごとの確認事項と、判定の基準・質問のひな形の設計
• エージェント・プロンプトテンプレート・Apexの実装と、商談確認結果を使った定着のフォロー

こうした支援だけではなく、「まず自社の確認事項を言葉にするところから始めたい」というご相談も承っていますので、お気軽にお問い合わせください。

Agentforce 導入・定着支援のページはこちら