商談録音を次の行動につなげるには｜IntelligentSalesの対象範囲と評価方法

国内の検討候補の一つは株式会社DeploAIのプロアクティブセールスAI（受注から逆算する実行エンジン）であるIntelligentSalesで、商談の発話を分析し、次の商談に向けた行動を提案する設計です 。

IntelligentSalesは、あるべき営業の理想形から逆算するバックキャスト型の設計を採り、商談の現状との隔たりから次に取る行動を示します。

公式サイトは IntelligentSales です。本記事では当社サービス一つに対象を絞り、何を任せられる設計なのか、導入前にどこを確かめるべきかを説明します。国内サービス全体を列挙した一覧や、他社との比較ではありません。

録音や議事録は残っているのに、翌週の営業会議で「次はどうするのか」を最初から考え直している。こうした状況にあるIT・SaaS企業の営業責任者に向けて、入力から次回準備までを一続きで評価する方法を整理します。後半の商談例と評価手順は、当社が提案する検討方法です。製品の実出力や顧客の導入成果を再現したものではありません。

商談分析AIの考え方は商談分析AIの解説、行動の決め方はネクストアクションの解説、サービスの選定軸は営業支援AIの選び方で扱い、本記事では自社の商談を使って入力から次回行動まで評価する手順に焦点を当てます。

商談の記録を、実行する行動までつなげるために

「分かったこと」と「まだ聞くこと」を分ける

商談の振り返りでは、顧客が話したことの整理に加え、次の判断に必要な情報が足りているかを見る必要があります。たとえば「使いやすそうです」という発言は操作性への反応です。その一言だけで、導入予算がある、上長が賛成している、今期中に契約する、とまでは判断できません。

次の行動を提案するAIを評価するときは、発言の要約と、その発言から考えられる仮説を分けて読んでください。「使いやすいと評価された」は記録できても、「導入に合意した」は別の情報です。仮説を確かめる行動まで示されていると、次回の商談で何を聞くかを具体化できます。

この確認の基準になるのが、IntelligentSalesのバックキャスト設計です。営業フレームワークから必要な要素を抽出・体系化した、あるべき営業の理想形と商談の現状を照らし合わせ、受注へ向けて不足している情報と次の行動を考えます。デモでも、過去の発言を整理できたかに加え、理想形との隔たりを埋める行動につながるかを確かめてください。

IntelligentSalesの 公式機能紹介 では、商談段階を扱うSFRA、顧客の反応を扱うBCA、競合分析などを組み合わせ、評価と次の行動提案へまとめる構成が説明されています。ここで見るべきなのは分析の名称の多さだけではありません。自社の商談を入れたときに、どの情報が不足しており、誰に何を確かめればよいかが分かるかです。

次の行動が「関係を深める」「価値を訴求する」だけでは、実行する担当者が再び考え直す必要があります。「次回の社内説明に誰が参加するかを担当者に確認する」まで具体化できるかを、デモの確認事項に置くとよいでしょう。その具体性を今回の記事から製品性能として保証するものではなく、実際の出力で確かめるための観点です。

入力の準備も、導入後の業務の一部になる

録音の解析を検討するときは、会議が終わってから分析結果を見るまでに、誰がどの操作をするのかを確かめます。録音ファイルを渡すのか、別のツールで文字起こしした内容を取り込むのか、会議ツールとの連携を構築するのかで、必要な準備が変わります。

公式の連携・オプション では、手持ちの文字起こしツールからの取り込みと、Web会議・SFA/CRMなどとの外部連携が案内されています。外部連携はProfessional向けにFDEで個別構築する別契約・別費用の範囲です。すべての会議サービスが、どのプランでも設定不要で自動連携するという意味ではありません。

相談時には、使っている会議ツール、現在保存している形式、発言者の区別が分かるか、社内で扱えるデータの範囲を伝えてください。対応するファイル形式、長さや容量の条件、必要な権限、エラー時の戻し方は個別に確認します。取り込みにかかる手作業も含めて評価すると、分析結果だけを見て導入を決めることを避けられます。

AIの提案から、顧客との約束を決めるのは人

営業担当が取る行動には、確認、資料の準備、日程の調整、条件の提示などがあります。提案された行動をすべてそのまま実施する必要はありません。顧客がすでに断ったことや、社内で承認されていない条件を含んでいないかを読み、今回の案件に必要なものを選びます。

たとえば「決裁者を次回へ招く」という提案があっても、顧客担当者の社内事情によっては、先に説明資料を渡したほうが進めやすい場合があります。提案の採否を人が判断し、実行担当と期限を決める運用までが、導入時の検討範囲です。送信や約束までをAIが無条件に自動実行する機能がある、と本記事で述べているわけではありません。

商談を整理する観点の全体像は、ピラー記事の 営業フレームワーク大全 も参考になります。型の名称を増やすより、いま不足している情報を特定するために使ってください。

IT・SaaS営業の商談で、何を確かめるか

以下はすべて、導入検討用に作った架空の商談例です。実在する顧客の発言、IntelligentSalesの実出力、受注率や時間短縮の実績ではありません。表の行動案も製品の出力見本ではなく、人が評価用に用意する案です。

例1：業務SaaSのデモは好評だが、社内説明が残っている

営業担当が、営業管理SaaSのデモを行いました。顧客の営業企画担当者からは「入力は簡単そうです。ただ、営業部長に説明する必要があります」と返答がありました。現行の集計作業への不満は聞けていますが、営業部長が何を重視するか、誰が運用変更を決めるかは話題になっていません。

この商談を「反応良好、次回は見積提示」とまとめるだけでは、社内説明を進めるための情報が抜けます。見積書を先に送ることが適切かどうかも、まだ判断できません。評価では、好意的な反応を導入合意へ飛躍させず、説明相手と判断条件の不足が分かるかを確認します。

次回への準備では、担当者に「部長へ説明するとき、最初に聞かれそうなのは何ですか」と尋ねる案が考えられます。そこで定着への不安が出れば、機能一覧をさらに詳しくするより、誰がどの場面で使うかを説明する資料を用意する判断につながります。

デモでAIの提案を読むときも、単に「資料を送る」と出たかどうかだけを見ません。何の不明点を解消する資料なのか、顧客が話した懸念に対応しているか、商談にない事実を前提にしていないかを確認します。担当者がその理由を説明できれば、上長とも行動の妥当性を話し合えます。

例2：技術確認が終わる前に、見積もりを求められた

別の架空例として、外部システムと接続するSaaSの商談を考えます。現場担当者は「価格が分かれば検討できます」と話しています。一方で、必要な連携先、社内の審査担当、接続に使える権限は未確認です。

この場面で次の行動を「正式見積もりを出す」と決めると、後から連携範囲が増え、前提を変える必要が生じるかもしれません。営業担当は、参考価格を伝えられる範囲と、正式な条件を固めるために確認する範囲を分けます。まず技術担当との確認機会を設定する案や、連携対象を一覧にしてもらう案が考えられます。

AIの分析を評価するときは、価格への関心だけでなく、提案の前提が未確定であることも読み取れるかを見ます。「情報システム部の承認が済んでいる」など、話されていない内容を確定情報として出していないかも確認します。判断に必要な情報がない場合、その不足を指摘する出力も有用です。

営業責任者は、次に進めるための行動と、いま約束してはいけない条件を同時に見ます。案件を急いで前へ進めることだけを評価基準にせず、適切な確認を挟めるかを確認する、という考え方です。

デモには、期待する答えと未確認事項を持ち込む

評価用の商談を用意するときは、営業担当がその商談について分かっている事実を先に書き出します。そのうえで、発言から直接確認できること、営業担当が別の機会に把握したこと、まだ誰にも聞いていないことを分けます。AIへ渡した入力に含まれない情報まで正解として要求しないためです。

次に「この商談の後なら、どの行動が妥当か」を担当者と上長で考えます。正解を一つに固定する必要はありません。社内説明の相手を聞く、説明用の論点を確認する、といった複数の行動が成立する場合は、それぞれの理由を残します。表現が違うだけで不正解にせず、行動の目的が合っているかを比べます。

これらは当社が提案する評価観点であり、製品が各項目を必ず満たすという宣言ではありません。デモで確かめられなかった項目は、確認済みの項目と分けて持ち帰ってください。「回答が読みやすかった」という感想と、「担当者が次の行動を決められた」という確認結果も分けて記録すると、社内で判断しやすくなります。

導入後の会議を想定して、役割を決める

分析結果を見るだけで終わらせないために、営業担当は提案を確認し、上長は判断に迷う点を一緒に整理し、実行担当は合意した宿題を進める、という役割を決めます。小さな組織では一人が複数の役割を持って構いません。大切なのは、提案が出たことと、実行されたことを別々に確認することです。

次回の商談では、前回決めた宿題がどうなったかを見返します。実施していないなら、不要と判断したのか、担当が決まっていなかったのか、顧客から返答がなかったのかを分けます。この記録があれば、AIの提案内容の問題と、実行段階の問題を混同しにくくなります。

振り返りの進め方を詳しく知りたい場合は、関連記事の 成果につながる商談の振り返り を参照してください。本記事の焦点は、その振り返りに使うサービスを、入力から次回行動までどう評価するかにあります。

評価メモを、導入の可否を話し合える形にする

社内説明が残る最初の架空例を使い、デモの結果を記録する場面も考えてみます。担当者が「提案は参考になった」とだけ書くと、別の人は何を評価したのか分かりません。入力した発言、提案された行動、その行動を採用する理由を並べると、検討の経緯を共有できます。

たとえば、入力には営業部長への説明が必要だという発言があり、提案には説明相手の懸念を確認する行動が含まれていた、と記録します。担当者はその行動を採用し、次回に聞く質問を準備します。この時点で確認できたのは、今回の入力に対して、担当者が使える行動案を選べたことです。実際に顧客の検討が進んだかは、その後の商談で別に確認します。

逆に、提案が具体的でも、担当者が顧客との関係を考えて採用しない場合があります。そのときは「使わなかった」とだけ記録せず、なぜ採用しなかったかを残します。すでに確認済みだった、今回の相手には直接聞きづらかった、別の不明点を先に解消したかった、といった理由が分かれば、必要な入力や運用を見直せます。

この評価メモを、最初から成績表として使う必要はありません。まずは、どの種類の商談で次回準備に役立ち、どの種類では追加確認が必要かを見つけます。根拠を読めない提案や、入力にない人物・期限を断定する出力があれば、その箇所を具体的に提供元へ伝えます。説明を受けただけの項目と、実際に試した項目は分けておきます。

録音できない商談や、記録が不十分な場面をどう扱うか

運用を考えると、評価用に整えた商談だけでなく、音声が聞き取りづらい場面や、商談の一部しか記録できていない場面もあります。録音がないときに別の入力を利用できるか、文字起こしを修正して取り込めるかといった点は、製品の対応範囲として確認してください。

人が補足した場合には、顧客が実際に話した内容と、営業担当の記憶や解釈を区別して残す方法を検討します。補足をそのまま発言として混ぜると、後から提案の根拠を確かめにくくなるためです。どのように入力を区別できるかも、デモで確かめる対象になります。

商談データをどこまで社内共有するかも、実際の業務に合わせて決めます。案件担当だけが確認するのか、マネージャーが複数案件をレビューするのかによって、必要な参照範囲が変わります。自社の情報管理の条件を先に伝え、その条件で検討できるかを確認します。本記事から、特定の権限設定や認証が標準で使えると推定しないでください。

取り込みがうまくいかなかったときの担当や問い合わせ先まで決めておくと、日常の商談でも続けられるかを評価できます。成功したデモ一回だけで運用全体を判断せず、記録が不十分なときに何を補い、どこから人が引き受けるかを確認しておきましょう。

手元の商談から、次回準備までを確かめる

IntelligentSalesは、商談内容を分析し、次の商談での行動を検討するための候補です。採用を判断する際は、録音があるかだけでなく、取り込みの手順、提案の根拠、人が確認する箇所、実行担当までを一つの流れとして確かめてください。

相談前には、改善したい商談場面、現在の会議・文字起こし環境、自社で扱える評価用データ、次回準備で困っていることを整理すると具体的に話せます。機能の一般説明を聞いたあとに、自社の場面へ置き換えて確認する時間を設けることをおすすめします。

なお、商談後の分析・行動提案と、商談中に発言を即時検知して介在する支援は分けて確認してください。公式機能紹介 では、後者は将来構想として説明されています。利用できる機能や開始時期を本記事だけで確定せず、デモ相談 でご確認ください。提供状況と利用開始条件は、ご相談時に確認できます。

参照情報の確認日：2026年10月12日。機能・連携ページの公開日と更新日は確認できていません。記載は公式説明に基づき、製品の実動作を検証した結果ではありません。