%20(%E8%83%8C%E6%99%AF%E3%81%82%E3%82%8A).png?width=130&height=39&name=%E6%9C%80%E7%B5%82Start%20Link%20(500%20x%20150%20px)%20(%E8%83%8C%E6%99%AF%E3%81%82%E3%82%8A).png "StartLink"){kind=logo}
この記事の結論
BtoB向けAIチャットボットは、製品名よりも業務との接続で選びます。回答の根拠、担当者への引き継ぎ、対応結果の記録までを一続きで試すことが選定の出発点です。
BtoB向けAIチャットボットは、製品名よりも業務との接続で選びます。回答の根拠、担当者への引き継ぎ、対応結果の記録までを一続きで試すことが選定の出発点です。
「問い合わせは減らしたいが、複雑な相談まで自動回答に任せてよいのか」
「資料を読ませても、古い情報や例外条件を誤って答えないか」
「営業やサポートが、チャットで得た情報を別の表へ転記し続けるのか」——
BtoB向けAIチャットボットとは、ナレッジや顧客情報をもとに対話形式で問い合わせへ回答し、必要に応じて担当者へ引き継ぐ仕組みです。比較するときは、回答の文章だけでなく、その根拠、回答できない場合の動き、会話後に残る記録を確認します。
AIを活用するチャットボットは、登録済みの選択肢に沿った案内に加え、自然文の質問への回答にも使われます。ただし、参照情報が不足している質問では、根拠のない回答が出る可能性があります。回答対象を定め、対象外の質問を誰が受けるかを先に決めましょう。基礎となる考え方はAIエージェントやAI経営戦略ガイドも参考になります。
この記事でわかること
問い合わせ対応や営業連携を見直す際に、質問の仕分けから製品比較、回答範囲の設計、導入後の見直しまでを順に説明します。各節の確認事項を自社の問い合わせに当てはめると、試すべき質問、担当者へ渡す条件、運用前に決める記録先を整理できます。
- 従来型とAI型の違い — 質問のばらつき、回答の根拠、情報更新の方法から、どちらを試すか判断します。
- BtoBでの活用場所 — Webサイト、テクニカルサポート、社内問い合わせ、顧客オンボーディングごとに、回答後の担当業務を整理します。
- 製品の選定基準 — 同じ問い合わせを使い、ナレッジの参照、有人対応、CRMへの記録、結果の確認方法を比較します。
- 導入と運用の進め方 — 対象を絞って回答と引き継ぎを試し、何を直せば次の業務へ広げられるかを見極めます。
BtoBの問い合わせ対応を業務フローから見直す
チャットボットを配置する前に、問い合わせを受けてから対応が終わるまでの流れを確認します。会話が終了しても担当者の確認や別の記録先への転記が残るなら、その工程も選定対象です。
実際の問い合わせを、次の三つに分けます。
- 公開資料の案内で終わる
- 顧客固有の条件を確認する
- 調査を継続する
質問文だけで分類せず、誰が回答を確定したか、何をもって対応を終えたかまで確認します。分類に迷う質問は自動回答の対象に加える前に、受付後の担当と確認事項を決めます。そのうえで、チャットボットが回答する地点と人へ渡す地点を業務フロー上に置きます。
同じ「利用できますか」という質問でも、次の二つでは終了条件が異なります。
- 公開資料に記載された一般的な利用条件を尋ねる場合 ── 資料に沿った案内を試せます。
- 顧客の契約への適用を尋ねる場合 ── 契約内容を確認する担当者へ渡します。
質問の表現が似ていても、回答を確定するために必要な情報で扱いを分けます。
問い合わせから次の対応までをつなぐ
Webサイト上の質問には、情報収集、製品仕様の確認、導入相談など異なる意図が含まれます。質問ごとに「利用者が何を得れば終了か」「終了しなければ誰が受けるか」を定めます。
- 公開済みの資料で答えられる質問 ── 該当箇所を案内し、利用者が解決できたか確認します。
- 利用条件が顧客ごとに異なる相談 ── AIは判断を確定せず、担当者が必要な条件を確認できるようにします。
- 不具合の調査が必要な質問 ── 受付後の担当と対応状況を追える記録先を決めます。
- 利用者が「解決していない」と示したとき ── 同じ案内を繰り返さず、次の受付先へ進めるかも試します。
HubSpotを利用する場合は、訪問者や顧客との会話をコンタクトの情報として扱い、相談が商談に進むなら取引、契約後の問い合わせならチケットなど、業務に合う記録先を決めます。
コンタクトから取引、顧客対応、請求までのどこで情報を引き継ぐかを先に描けば、チャットボットを全体フローの一部として配置できます。試す際は、会話後の担当者が必要な条件と経緯を確認できるかまで追います。
記録先を決める基準は、次に対応する担当者が状態を更新できることです。
表計算での管理から記録を一元化する
チャットの内容を担当者が表計算ファイルへ写し、さらにCRMへ入力する運用では、同じ問い合わせの状態を複数の場所で確認することになります。現在の記録先を並べ、どの記録を後続対応の基準にするか決めます。受付、担当者の確認、対応完了の各段階で記録がどこに残るかを追うと、転記が必要になる地点を特定できます。
- 記録項目は後続の判断に使うものに絞る ── 問い合わせ内容、分類、対応状況などです。
- 取得する情報と確認して入力する情報を分ける ── チャットから取得する情報と担当者が確認して入力する情報を分け、顧客固有の条件をAIが推測して埋めないようにします。
- 会話での申告と確認済みの条件を区別する ── 利用者が契約内容に触れていても、契約記録との照合が必要なら、会話で述べられた内容と確認済みの条件を区別して残します。
選定時には、担当者が会話の経緯を読めるか、未対応の相談を見つけられるか、対応後に結果を残せるかを実際の画面で確かめます。会話だけが保存され、担当や対応状況が分からない場合は、連携方法と自社の記録手順を見直します。会話を受けた担当者とは別の担当者にも記録を開いてもらい、追加で顧客に聞くべきことと次の対応を判断できるか確認します。判断できなければ、要約や記録項目を直してから再試行します。
自動化する範囲と人が判断する範囲を分ける
よくある質問への回答、問い合わせの分類、会話内容の要約は、AIに任せる範囲として検討できます。契約条件の例外判断、重大な不具合への対応、顧客への最終的な約束には、担当者が確認する手順を置きます。
境界は質問ごとに、次の順で確認します。
- 資料の記載だけで回答が確定するか ── 資料だけで確定するなら回答を試します。
- 顧客固有の条件を聞く必要があるか ── 条件が不足するなら必要事項を聞いて人へ渡します。
- 誤った案内が出たときに担当者の判断が必要か ── 判断の影響が大きい質問は、案内文を追加する前に受付先を決めます。
一般的な手順の案内から契約上の適用可否へ話が移った時点でも、扱いを切り替えます。
引き継ぎを試すときは、通知に加え、担当者が質問内容、確認済みの条件、未確認の条件を読めるかを確認します。顧客に同じ質問を繰り返す必要があれば、引き継ぎ時に残す項目を見直します。担当者が回答を確定した後は、その結果を記録し、同種の質問を今後も人が扱うか判断します。
従来型とAI型の違いを比較する
従来型はあらかじめ設計した選択肢やシナリオに沿って回答し、AI型はナレッジなどを参照して自然文で回答を作ります。方式を選ぶ際は、質問の表現だけでなく、回答の根拠を管理できるか、情報を更新する担当を置けるかも確認します。
回答方式と運用負荷を比べる
| 比較項目 | ルールベース型 | AI型 |
|---|---|---|
| 回答の作り方 | シナリオや選択肢を事前に定義します | 質問の文脈と参照情報をもとに回答を生成します |
| 対応できる質問 | 想定して登録した質問や分岐に向いています | 言い回しの異なる質問にも対応しやすい一方、根拠の確認が必要です |
| 情報の更新 | シナリオや回答を個別に更新します | 参照するナレッジを更新し、回答への反映を確認します |
| 向いている用途 | 回答内容が固定された案内です | 製品情報や手順など、参照資料に基づく案内です |
| 主な注意点 | 想定外の質問で分岐が行き詰まる場合があります | 誤った回答や古い情報をもとにした回答が起きる場合があります |
比較用の質問は自社で受けた問い合わせから選び、次の種類を両方式に同じ条件で入力します。
- 公開資料で答えられるもの
- 同じ意図の言い換え
- 適用条件で答えが変わるもの
- 資料に答えがないもの
質問ごとに期待する案内、根拠資料、回答してはいけない条件、引き継ぎ先を比較表に記録してから試します。資料に答えがない質問では、答えを作らず引き継げるかも確認します。
試した後に正解や終了条件を変えると、方式間の結果を比べられなくなります。
結果は「根拠」「適用条件」「次の対応」の順で確認します。正式な資料と異なる案内が出た場合は、その質問を解決扱いにしません。
- 資料が誤っている場合 ── 資料を直します。
- 資料が正しいのに回答が異なる場合 ── 参照先や回答範囲を見直します。
- 条件付きの記載を省いた場合 ── 回答文が自然でも解決扱いにはしません。条件を回答へ反映できるか再試行し、できなければ人へ渡す範囲に変えます。
資料に答えがない質問では、推測せず回答を保留し、担当者に引き継げるかを確認します。保留できても利用者が次へ進めない場合は、受付先と案内を直します。
- ルールベース型を選ぶ理由 ── 固定した案内で解決し、変更時に該当する分岐を保守できる場合です。
- AI型を試す場合 ── 複数資料を参照する必要があり、正式な参照先と適用条件を管理できる場合です。
参照資料や設定した条件が方式間で異なる場合、その結果だけで方式の差は判断しません。
RAGを使う場合も参照情報を整える
RAGは、質問に関連する文書を検索し、その内容を参照してAIが回答する方式です。FAQを一問一答で登録する方法と比べ、複数の資料から関連情報を探せる点が特徴です。ただし、参照資料が古い、重複している、適用条件が明確でない場合は、回答の根拠も曖昧になります。資料の準備方法はRAG構築の実践ガイド｜社内データを活用したAI検索システムの作り方でも解説しています。
資料は、次の順で整えます。
- 資料を仕分ける ── 「利用者へ案内してよい」「社内でのみ参照する」「内容を確認するまで使わない」に分けます。
- 正式な案内を決める ── 同じ内容を扱う資料のうち正式な案内を決め、適用対象や例外条件を読める状態にします。
- 更新担当を決める ── 更新担当が決まってから回答を試します。
公開範囲が混在する場合は、回答内容だけでなく、利用者に表示される参照先も確認します。
試す質問には、資料に答えがないものだけでなく、古い版と新しい版で案内が異なるもの、例外条件が別の資料に書かれているものも含めます。回答を読む際は、示された根拠が正式な資料か、その資料の適用対象に質問者が含まれるかを確認します。次の場合は対応が分かれます。
- 資料間で結論が違う ── 更新担当が正式な案内を決めるまで回答対象から外します。
- 適用条件が資料にない ── 条件を明記した後で同じ質問を再試行します。
- 更新後も以前の案内が出る ── 参照対象や更新の反映状況を調べ、正しい根拠を示せるようになってから運用に戻します。
導入の速さだけで方式を決めない
初期設定と日々の運用では、担当者が行う作業が異なります。比較時には回答の作成に加え、情報変更の受付、回答の点検、例外への対応を同じ業務について書き出します。
| 観点 | ルールベース型を選びやすい場合 | AI型を選びやすい場合 |
|---|---|---|
| 質問の傾向 | 質問と回答が定型的です | 同じ意図でも質問の表現が多様です |
| 情報の状態 | 固定した案内を明示できます | 参照する資料を管理・更新できます |
| 誤回答の影響 | 選択肢で案内を限定したいです | 人への引き継ぎを設けたうえで回答範囲を管理できます |
| 運用体制 | シナリオを保守する担当者を置けます | ナレッジの責任者と回答確認の手順を置けます |
方式を選んだら、情報の変更を誰が受け取り、どの案内を再確認するかを決めます。案内内容が変わったとき、ルールベース型では該当する分岐と回答を、AI型では正式な参照資料と条件付きの質問を確認します。更新箇所や確認担当を特定できない場合は、利用範囲を広げる前に管理方法を整えます。
変更後の試行では、以前は正しく答えた質問も再確認します。変更した案内だけが正しくても、別の条件に適用してしまうなら運用へ進めません。担当者が変更を受け取り、案内を修正し、影響する質問の結果を確認できる方式を選びます。
製品比較は機能名より業務との接続で行う
製品紹介にある機能名だけでは、受付から解決までの流れに合うか判断できません。自社で使う問い合わせの入口、回答資料、記録先、有人対応の担当を決め、各製品で同じ流れを試します。比較を始める前に、利用者に示す回答、担当者に残す記録、対応を終える条件をそろえておきます。
製品を比較する際は、実際の問い合わせを使い、回答品質や運用・セキュリティの要件を確認します。
| チェック項目 | 確認内容 |
|---|---|
| ハルシネーション対策 | 回答の根拠を確認できるか、答えられない場合に質問の確認や有人引き継ぎへ進むかを試す。出典 |
| CRM連携 | 必要なCRMプロパティの参照権限を設定できるか、対象コンタクトでの応答を試せるかを確認する。出典 |
製品ごとの特徴を整理する
| 製品 | 特徴 | 比較時に確認すること |
|---|---|---|
| HubSpot Breeze Bot | HubSpot CRMとの統合 | 会話の記録先と営業・サポートの後続対応 |
| Intercom Fin | 複雑な質問への対応をうたう製品 | 参照ナレッジ、回答根拠、CRMとの連携範囲 |
| Zendesk AI | チケットシステムとの統合 | 問い合わせからチケット対応までの引き継ぎ |
| PKSHA Chatbot | 日本語に強い製品として紹介されている | 対象業務、連携方法、運用時の支援範囲 |
| KARAKURI chatbot | CX特化、有人切替がスムーズと紹介されている | 引き継ぎ条件と有人窓口で見える情報 |
| Tidio | 中小企業向けとして紹介されている | CRM連携、対象チャネル、必要な運用機能 |
| セキュリティ | 認証規格への対応状況 | データの保存場所と暗号化の有無 |
| 日本語での応答 | 日本語の質問意図を理解し、自然な文章で回答するか | 質問の言い換えも試し、意図の取り違えや不自然な表現がないか確認する |
比較表にある特徴は製品の優劣を示すものではありません。現在の仕様や提供条件は変わることがあるため、選定を進める段階で公式情報と個別の契約条件を確認します。
試す質問と終了条件は製品間でそろえます。
- 公開資料で答えられる質問 ── 回答の根拠と解決状況を確認します。
- 個別判断が必要な相談 ── AIが判断を確定せず、担当者へ条件と経緯が届くかを確認します。
- 引き継ぎ後の状態を追えない場合 ── 回答が適切でも、その工程を別の運用で補えるかまで確認します。
比較結果には「できた・できなかった」に加え、どの工程で止まったかを残します。止まった工程ごとに、次を調べます。
- 根拠を示せない ── 参照設定を調べます。
- 顧客の条件が抜ける ── 記録項目を調べます。
- 担当者が未対応を見つけられない ── 割り当てや状態管理を調べます。
必要な工程を通して確認できた製品から、運用担当者による点検へ進めます。業務に必要な工程を試せない製品は、提供条件と代わりの運用方法を確認してから判断します。
各製品の問い合わせ対応機能、CRMとの接続方法、料金の確認方法を比較します。
| ツール | 提供元 | 特徴 | CRM連携 | 料金目安 |
|---|---|---|---|---|
| Breeze Customer Agent | HubSpot | CRMの顧客情報を参照して応答 | HubSpot Smart CRM | Professional・Enterpriseで利用可能、解決した会話1件あたり$0.50 |
| Zendesk AI agents | Zendesk | チケット対応と連携し、問い合わせの自動解決を支援 | Zendeskのサポート基盤内で運用 | Suite・Support各プランで利用可能、利用量は自動解決件数で算定 |
| PKSHA ChatAgent | PKSHA Technology | 問い合わせへのAI応答と有人チャット連携 | 標準搭載の外部APIでCRMなどと連携可能 | 料金は製品資料で確認 |
CRM連携は記録と担当者の行動まで確かめる
CRM連携を評価するときは、会話が記録されるかに加え、誰がどの画面で確認し、次に何をするかを確かめます。Webサイトの相談をコンタクトに関連付け、商談化した場合は取引へつなぎ、顧客からの技術的な問い合わせはチケットで追う、といった流れを自社の業務に沿って設定します。
試す際は、受付、担当者の確認、対応状況の更新まで追います。
- 会話の要約から質問の条件が抜けている ── 元の会話を確認できるかを見ます。
- 未対応を識別できない ── 担当の割り当てや状態の記録方法を見直します。
- 対応後も未対応として残る ── 完了をどこに記録し、誰が確認するかを決め直します。
連携の可否は、画面上の動きと記録内容で確かめます。
HubSpotのチャットボット機能を選定対象にする場合、利用可能な機能や要件は公式ドキュメントで確認します。確認した提供条件を、自社で試した受付、記録、引き継ぎの結果と照らして判断します。顧客固有の回答では、AIが過去の会話や契約状況を参照できるかを確認し、参照できない場合は担当者が確認できる情報を引き継ぎます。
質問の種類ごとに適した製品を考える
- Webサイトからの見込み顧客の相談 ── 質問への回答から資料案内やフォーム入力へつながるかを見ます。
- 製品サポート ── 手順や仕様を参照した回答と有人エスカレーションを確認します。
- 社内ヘルプデスク ── 参照情報のアクセス範囲と更新担当を先に決めます。
- 顧客オンボーディング ── 初期設定や基本操作を案内し、解決しない質問をカスタマーサクセス担当へ渡せるかを試します。
用途ごとに質問と終了条件が異なるため、最初に扱う業務を定めてから製品を比べます。資料案内で終わる質問と、設定状況を確認しなければ解決しない質問を分けると、回答対象と引き継ぎ対象を決めやすくなります。
選ぶ順序は、参照資料が明確か、質問の終了条件を決められるか、引き継ぎ先が対応できるかです。資料が曖昧なら情報を整え、終了条件が曖昧なら担当者と完了の判断を決めます。引き継ぎ先を置けない業務は、受付後の体制を整えてから試します。企業様によって最適な形は異なります。
ナレッジと有人エスカレーションを設計する
回答の点検には、参照情報が正しいか、適用条件に合うか、答えられないときに人へ渡せるかという別々の確認が必要です。問題が起きた工程を分けると、資料、回答範囲、引き継ぎ手順のどれを直すべきか判断できます。
回答に使う情報を選び、更新責任を決める
最初に、回答に使う資料の利用者、適用対象、更新担当を確認します。古い版や内容が重複する資料があれば、正式な案内を決めます。公開情報と社内向け情報が混在する場合は、利用者へ示してよい範囲を分けます。正式な案内が決まらない資料は回答対象に加えず、判断できる担当者へ確認します。
回答の確認には、よくある質問、条件付きの質問、資料に記載がない質問を使います。結果は次の三つに分けます。
- 根拠と適用条件に沿って回答した
- 回答を控えて引き継いだ
- 根拠と異なる案内をした
根拠と異なる案内が出たら、まず参照された資料を調べます。資料自体が誤っていれば更新し、資料は正しいのに条件を取り違えたなら回答範囲や引き継ぎ条件を見直します。
修正後は同じ質問を再試行し、回答だけでなく、担当者が見る記録も確認します。判断に必要な条件を資料へ明記できない質問は自動回答の対象から外します。回答例を見る際も、案内の根拠となる情報と更新時期を確認し、連携の可否や処理結果は自社の条件に沿って確かめます。根拠の扱いを整理する際はAIハルシネーション（幻覚）を防ぐ方法｜企業でのAI活用における品質管理も参考になります。
引き継ぎ条件を会話の流れに組み込む
回答の根拠がない場合に加え、緊急性が高い相談や個別の契約確認も、人へ渡す条件に含めます。条件は最初の質問だけで判断せず、会話中に新しい事情が分かった時点でも確認します。利用者が一般的な操作を尋ねていても、途中で障害や個別の契約条件に触れたなら、そこで扱いを切り替えます。
一般的な案内を始めた後に顧客固有の条件が示されたら、自動回答を止めます。担当者には、次の四つを分けて渡します。
- 質問内容
- 顧客が示した条件
- 案内済みの内容
- まだ確認していない事項
利用者にも、回答を確定せず担当者へ渡すことが伝わる案内を用意します。
受付時間外を含め、誰が引き継ぎを受け、どこで未対応を確認するかも決めます。通知は届いていても対応状況を追えない場合は、担当の割り当てと記録先を見直します。引き継ぎ後の対応が記録され、問い合わせの終了を確認できてから、その流れを運用に採用します。
ナレッジの範囲が合わないケースを見分ける
回答の根拠が見つからない、資料間で記述が矛盾する、質問に個別判断が必要という状況では、直す場所が異なります。いずれもAIの回答をそのまま顧客へ案内せず、問い合わせと参照できた情報を残します。
- 根拠資料がない質問 ── 回答を控え、更新担当に正式な案内を追加できるか確認します。
- 資料同士が矛盾するとき ── 更新担当が正式な案内を確定するまで回答を保留します。
- 個別契約によって回答が変わる質問 ── 契約内容を確認できる担当者に引き継ぎます。
資料を追加しても個別判断が必要な質問は、回答対象に含めません。
見直し後は、問題が出た質問と同じ種類の質問で、回答と引き継ぎを再確認します。正式な資料と適用条件がそろい、回答の根拠を確認できた質問だけ回答対象へ加えます。個別判断が残る質問は人が対応する条件として維持し、担当者が確認した結果を次の対応へ引き継げるかを確かめます。
導入効果を測りながら段階的に広げる
導入後は、会話数や自動回答数に加え、問い合わせが解決したか、必要な相談が担当者へ届いたかを確認します。最初に対象業務を絞ると、資料、回答、引き継ぎのどこを直すべきか判断しやすくなります。運用範囲を検討する際は、HubSpotのサポートに関する案内も確認し、自社の受付体制と照らし合わせます。
小さな対象を選び、確認する指標を決める
参照資料、更新担当、有人対応の担当が明確な業務を選びます。導入前の問い合わせについて、どのように解決し、どこで人の判断が必要だったかを確認します。運用開始後も同じ種類の質問を見て、回答から終了までの流れを比べます。比較する質問の種類が変わった場合は、結果をそのまま並べず、対象の違いを記録します。
「解決」は、回答の表示、利用者による問題解決、担当者の対応完了を区別して定義します。自動回答が増えても未対応の相談が残るなら、回答範囲を広げる前に引き継ぎを直します。利用者が解決したか分からない会話は、回答を表示した事実と解決した事実を分けて扱います。
| 確認する観点 | 見る内容 | 結果を受けた対応 |
|---|---|---|
| 回答の妥当性 | 根拠資料と回答が一致しているか | 不一致があれば資料や回答範囲を見直します |
| 解決状況 | 会話後に問い合わせが解決したか | 解決しない質問を分類し、ナレッジか案内を修正します |
| 引き継ぎ | 必要な相談が担当者へ届いているか | 漏れがあれば条件と通知先を調整します |
| 担当者の負荷 | 同じ内容の再確認や転記が残るか | 重複作業が残る工程を整理します |
| 顧客の反応 | 案内が役に立ったか | 低評価の質問から回答や導線を確認します |
| 分析・レポート | 質問の傾向や満足度に加え、自動解決率を可視化できるか | 対象と解決の定義をそろえ、自動回答後に利用者が解決した割合を確認できるか試す |
評価時は、対象の質問と終了条件をそろえたうえで、表の観点を会話ごとに確認します。根拠と異なる回答、条件の省略、必要な引き継ぎの漏れがあれば、その質問を解決扱いにせず、原因に応じて修正します。回答が根拠と違えば参照資料と適用条件を調べ、引き継ぎが漏れれば会話中のどの発言で条件に該当したかを確認します。案内後も解決しなければ、回答文、案内先、人へ渡すタイミングを調べます。
修正後は同じ条件で試し直します。問題が再現するなら対象を広げず、起きる条件を記録して回答範囲を狭めます。結果を比べる前には、対象とした質問の種類、参照資料、解決の定義がそろっているかを確かめます。いずれかが変わっていれば、その変更も結果と一緒に残します。
結果を営業・サポートの改善へ戻す
チャットボットの会話からは、顧客が迷った点や、案内が届かなかった箇所を確認できます。質問を営業やサポートと共有するときは、次の三つに分けます。
- 説明がない ── 資料を整えます。
- 説明はあるが見つけられない ── 案内への導線を確認します。
- 顧客ごとの判断が必要 ── 担当者が受け取る条件と記録を改善します。
修正後は、同じ種類の質問を使い、回答から後続対応まで再確認します。資料を整えた質問でも、利用者がどの条件に当てはまるか分からないなら、確認事項や引き継ぎ先を見直します。
HubSpotを使う場合は、会話の記録をコンタクトや関連する取引・チケットと結び付け、次の対応状況を追える形を検討します。問い合わせの傾向をレポートで確認する際も、会話の件数だけでなく、解決と引き継ぎの結果を業務の判断に使います。
適用範囲を広げる前に運用を振り返る
対象業務で回答の根拠、引き継ぎ、記録を確認できたら、次に扱う質問を選びます。問題が残る場合は範囲を保ち、資料、回答方針、担当者への通知のうち原因に合う箇所を修正します。対象を追加するときは、既存の質問で確認できた動きが維持されるかも見ます。
新しい対象へ進む条件は、管理された参照資料、更新担当、有人対応の担当、解決状況の確認方法がそろっていることです。欠けている項目があれば、対象を増やす前に担当や確認方法を定めます。個別判断が必要な相談や誤回答の影響が大きい問い合わせでは、人が回答を決めます。AIには情報案内や要約など、担当者の補助を任せます。
よくある質問
- 自動化できる割合 ── 問い合わせの何割を自動化できるか
- RAG型とFAQ型 ── どう使い分けるか
- CRM連携 ── 何を確認すればよいか
- 答えられない質問 ── どう扱うか
BtoB向けAIチャットボットは問い合わせの何割を自動化できますか？
一律の割合では判断できません。問い合わせを「資料だけで回答が確定する」「追加条件の確認が必要」「人の判断が必要」に分け、最初の種類だけを自動回答の対象にします。実際の質問で試し、利用者が解決できたか、解決できない場合に必要な引き継ぎができたかを確認します。
資料と回答が一致していても解決しない質問は、案内先や回答を終える条件を見直します。追加条件や人の判断が必要な質問は、自動回答だけで完結させる対象には向きません。確認結果に応じて対象を維持するか狭め、別の種類の質問へ広げる場合は同じ方法で確かめます。
RAG型とFAQ型はどう使い分けますか？
回答内容が定型的で、選択肢や決められた手順に案内したい場合はFAQ型を検討します。複数の資料を参照して自然文の質問に答える必要があり、資料の更新担当と回答確認の手順を置けるならRAG型を試します。同じ質問で両方式を比べ、正式な根拠に沿っているか、条件付きの説明を省かないか、対象外の質問を人へ渡せるかを確認します。
資料が確定していない場合は、先に正式な案内と更新担当を決めます。条件の省略が続くなら、その質問を自動回答の対象から外して再設計します。
CRM連携で何を確認すればよいですか？
会話内容がどの顧客記録に保存され、営業やサポートの担当者がどこで確認するかを決めます。見込み顧客の相談はコンタクトや取引、顧客の技術的な問い合わせはチケットなど、後続業務に合う記録先を検討します。受付から担当者の確認、対応状況の更新まで試し、質問の条件や経緯が欠ける場合は記録項目と引き継ぎ方法を見直します。担当者が対応を終えた後、その結果を記録できることも確かめます。
AIが答えられない質問はどう扱いますか？
根拠がない質問、個別契約に関わる質問、緊急性の高い相談などを引き継ぎ対象として定めます。担当者には質問、顧客情報、会話の経緯、確認できていない条件を渡し、対応状況を記録します。対応後に、正式な資料を整えれば回答できる質問か、引き続き人が判断すべき質問かを分けます。資料を直した質問は同じ条件で再試行し、個別判断が残る質問は自動回答の対象に含めません。
まとめ
BtoB向けAIチャットボットは、回答の根拠、有人対応への引き継ぎ、CRMでの記録を一続きの業務として試して選定します。運用開始後も、解決しない質問の原因を資料、案内、引き継ぎに分けて直します。
まずは、参照資料と担当者が明確な業務を一つ選びます。
- 対象にする質問と参照するナレッジを選び、適用条件と更新担当を決めます。
- AIが回答する範囲と、人へ引き継ぐ条件、担当者が確認する記録先を定義します。
- 根拠のある質問、条件付きの質問、資料にない質問を試し、回答と引き継ぎを確認します。
- 解決状況と対応記録を見直し、資料と担当体制が整った業務から対象を広げます。
CRMを活用した業務効率化やAIとの連携に関するご相談は、StartLinkまでお気軽にお問い合わせください。
あわせて読みたい
業務への組み込み方、ナレッジの管理、問い合わせ対応の設計を詳しく検討する際は、次の記事も参考にしてください。取り組む業務が決まっていれば、その業務に近い記事から確認できます。
記事の内容を、そのまま実務に落とし込みたい方向け
HubSpotゴールドパートナーのStartLinkが、HubSpot導入・AI活用・CRM整備・業務効率化までをまとめて支援しています。記事で気になったテーマを、そのまま相談ベースで整理できます。
次に読む
株式会社StartLinkは、事業推進に関わる「販売促進」「DXによる業務効率化（ERP/CRM/SFA/MAの導入）」などのご相談を受け付けております。 サービスのプランについてのご相談/お見積もり依頼や、ノウハウのお問い合わせについては、無料のお問い合わせページより、お気軽にご連絡くださいませ。
著者情報
