チャットボットのシナリオ設計方法|分岐・聞き返し・離脱防止の実務
記事概要:チャットボットのシナリオを、利用目的、入口、選択肢、聞き返し、入力形式、エラー、有人引継ぎ、完了確認の順に設計します。画面ごとの会話例とテスト観点を用い、利用者の迷いと途中離脱を減らす方法を解説します。
本記事の目次
チャットボットのシナリオ作り方は、社内の業務フローをそのまま選択肢へ置き換えることではありません。チャットボット会話設計では、利用者の言葉と目的から入口を作り、必要な情報だけを順番に聞き取ります。
目的と完了条件を一つに絞る
各シナリオで、情報を見つける、予約を受ける、配送を確認する、有人担当へ渡すなどの完了条件を決めます。一つの会話で複数業務を扱う場合も、現在の目的を画面上で示します。
数値が改善しても、別チャネルへの移動、再問い合わせ、訂正、顧客の諦めが増えていないかを確認します。チャットボットのシナリオ設計方法の成果は部分最適ではなく、受付から問題完了までの総工数と顧客結果で判断します。

入口は顧客の言葉で作る
社内部門名ではなく、注文を変更したい、ログインできないなどの用件を表示します。主要選択肢を絞り、該当なしと自由入力、前へ戻る操作を用意します。
定例会では全件を読み上げず、変化が大きい用件と影響の大きい例外を選びます。原因が運用、製品、情報、需要のどこにあるかを分け、次回までの担当と確認値を決めます。
聞き返しは理由と形式を示す
注文番号を聞くなら、確認に使うことと入力例を伝えます。日付、電話番号、郵便番号は形式を制御し、エラー時には同じ文を繰り返さず、どこを直すか示します。
聞き返しは理由と形式を示すの改善前には、対象件数、発生条件、顧客影響、担当者の追加作業を基準値として残します。会話設計担当者、CS企画担当者が原因を一つに決めつけず、流入、導線、データ、権限、システムの順に切り分けると対策を選びやすくなります。
| 画面 | 表示・質問例 | テスト観点 |
| 入口 | ご用件を選んでください | 主要用件、該当なし、戻る |
| 確認 | 注文番号を入力してください | 形式、入力例、桁数 |
| 分岐 | 発送前か発送後かを確認 | 境界日時、状態更新 |
| エラー | 確認できない理由と再入力 | 回数上限、代替手段 |
| 有人転送 | 受付時間と引継ぎ内容 | 履歴、待ち時間、閉局時 |
| 完了 | 受付番号と次の連絡 | 外部処理との一致 |
分岐は条件の優先順位を決める
顧客種別、契約、期限、商品状態など複数条件がある場合は、判定順を記録します。後から条件を追加して既存分岐と競合しないよう、共通確認と例外処理を分けます。
変更は対象用件や時間帯を限定して行い、前後で同じ指標を比較します。複数の設定を同時に変えると効果の理由が分からなくなるため、仮説、変更内容、観測期間、結果を一つの記録へ残します。
有人引継ぎで会話を切らない
転送条件、営業時間、待ち時間、代替連絡を案内し、顧客情報、用件、入力値、表示済み回答、エラーを担当者へ渡します。担当者が同じ質問を繰り返さない画面を用意します。
担当者の経験に依存する部分は、判断条件と例外を文章化し、ナレッジまたはシステム設定へ反映します。個別に解決した案件を共有するだけでなく、次回に同じ問題を早く処理できる形へ変えます。
テストは正常系だけで終えない
戻る、無入力、誤形式、途中離脱、連打、外部API停止、営業時間外、個人情報、想定外表現を試します。完了メッセージと実際の処理結果が一致することも確認します。
テストは正常系だけで終えないの変更後は、対象の指標だけでなく、再問い合わせ、訂正、別チャネルへの移動を同じ期間で確認します。改善が確認できなければ、仮説と実施内容を分けて記録し、次の変更で同じ原因を重ねて検証しないようにします。
シナリオの対象範囲と分岐条件を整理する
チャットボットのシナリオは一度作って終わりにせず、問い合わせ内容、顧客行動、有人対応への転送条件を確認しながら見直します。要件票には必須、希望、対象外だけでなく、その理由と確認方法を記載し、例外時にどの段階で有人担当へ切り替えるかも決めておきます。
UdeskのWatsons事例では、複数チャネルを統合し、AIチャットボットによって定型的な問い合わせの85%に対応しています。こうした運用でも、すべての質問をボットだけで処理するのではなく、繰り返し発生する問い合わせを自動化し、複雑な案件は有人対応へ振り分ける考え方が基本になります。シナリオ設計でも、回答内容だけでなく、分岐と転送条件まで一つの流れとして設計することが必要です。

公開後の結果と変更履歴を残す
本番後は利用件数だけでなく、途中離脱、有人転送、再問い合わせ、手作業への戻りも確認します。利用数が増えていても未解決の問い合わせが増えている場合は、質問の選択肢、分岐、回答内容、有人転送の位置のどこを修正すべきかを切り分けます。
会話設計担当者やCS企画担当者は、月次結果とともに変更前の基準値、対象期間、除外条件を残します。繁忙期や障害日の数値を通常時と分けておけば、改善がシナリオ変更によるものか問い合わせ量の変化によるものかを判断しやすくなります。変更理由と適用日も記録し、旧シナリオで進行中の会話をどこから切り替えるか決めておきます。
会話ログを次の改善へ反映する
シナリオを改善するには、ボット内の利用状況だけでなく、有人担当へ移った後にどのような回答で解決したかまで確認する必要があります。未回答や離脱が集中する箇所を把握し、実際の問い合わせに合わせて選択肢やナレッジを修正することで、公開後もシナリオを更新できます。
UdeskではAIチャットボットと有人チャット、問い合わせ管理、ナレッジを組み合わせられるため、ボットで入力された情報を有人担当へ引き継ぎながら、未解決や転送の履歴を次のシナリオ改善に活用できます。シナリオの完成度を公開時だけで判断せず、実際の会話データをもとに回答範囲と導線を継続して見直す運用に適しています。
FAQ
Q:選択肢はいくつがよいですか
A:一画面で迷わず比較できる数に絞り、残りは次の階層へ分けます。
Q:自由入力だけでもよいですか
A:AI型でも回答範囲と例を示し、認識できない場合の選択肢を用意します。
Q:シナリオは誰が更新しますか
A:業務責任者が内容を承認し、運用担当がログを基に変更する体制にします。
》》Udesk AI チャットボットの無料トライアルを開始するにはクリックし、メリットを実際にご体験ください
本記事はUdeskのオリジナルであり、転載する際は出典を明記してください:https://www.udesk.jp/blog/news/guide/6330/

Customer Service& Support Blog



