チャットボット×有人切替の設計が、これからのCX／社内サポートを左右する

チャットボットを導入したものの、「問い合わせは減った気がするが、顧客のモヤモヤは増えている」「ボットでは解決できず、結局すべて有人チャットに流れてくる」という声は少なくありません。これはツールの問題というよりも、チャットボット 有人切替の前提となるSLA 設計とエスカレーション 基準が最初に定義されていないことが原因であることがほとんどです。

カスタマーサクセス（CS）の観点では、「どこまでをボットで完結させ、どこから人が出ていくか」によって、一次解決率やNPSが大きく変わります。一方、情シスの観点では、チャットボット 有人切替の設計次第で、社内ヘルプデスクの負荷やシステム連携の構造、ログ分析のしやすさまで影響します。にもかかわらず現場では、「うまくいかない案件はとりあえず有人チャットへ」「クレーム化しそうなときだけ上長にエスカレーション」という属人的な運用に頼っているケースが多いのが実情です。

本記事では、チャットボット 有人切替を前提にしたSLA 設計とエスカレーション 基準の考え方を整理し、CSと情シスが共通言語で議論できるフレームと具体例を紹介します。「ボットか人か」の二択ではなく、ボット＋人の連携を実務レベルで設計するためのガイドとしてお読みください。

チャットボット運用とSLA設計：ボットにも「サービスレベル」を定義する

多くの現場では、電話やメール、有人チャットには詳細なSLAが定義されている一方で、チャットボットには明確なSLA 設計がない、というアンバランスが生まれています。その結果、チャットボット 有人切替の判断もあいまいになり、「ボットがどれだけ粘るべきか」「ボットで引き延ばして顧客を怒らせていないか」を誰も説明できない状態になりがちです。本来、チャットボットにも初回応答時間・解決までの所要時間・ボット一次解決率・放棄率・稼働率といった指標を持たせ、有人チャットとの役割分担をSLA 設計のレベルで明文化する必要があります。

例えば、外部顧客向けサポートでは、「FAQレベルの問い合わせの80％以上は、チャットボットで60秒以内に解決」「チャットボット 有人切替後は、オペレーターが2分以内に初回応答」というように、ボットと人のSLAをセットで設計します。社内ヘルプデスクであれば、「業務停止を伴わない一般的な問い合わせはチャットボットを第一窓口とし、業務継続に影響する場合はエスカレーション 基準に従い即座に有人チャットに切り替える」といったSLA 設計が現実的です。ここで重要なのは、「ボット用SLA」「有人用SLA」「チャットボット 有人切替に伴うSLA」を一枚の表（マトリクス）に落とし込み、CSと情シスが同じ図を見ながら議論できる状態をつくることです。

また、LLMを活用したAIチャットボットを使う場合は、AIならではのSLA項目も検討に値します。たとえば「AI回答率（ボットが自動回答を返した割合）」「AI回答CSAT（ユーザーが回答を評価する仕組みがある場合）」「AIからのエスカレーション率（有人切替が発生した比率）」などです。これらをモニタリングすることで、「エスカレーション 基準が厳しすぎて、すぐに人へ投げている」「SLAを守るためにボットで引き延ばしすぎている」といったバランスの悪さが見えてきます。SLA 設計は一度決めて終わりではなく、データにもとづいて継続的に更新するべき「生きた指標」です。

ポイント：SLA 設計を「電話・メール・チャット」ごとに別々に作るのではなく、「問い合わせカテゴリ×チャネル」で一本のマトリクスにまとめると、有人切替の優先度が整理しやすくなります。

エスカレーション基準とチャットボット有人切替：四層で考える設計フレーム

つぎに重要になるのが、エスカレーション 基準です。チャットボット 有人切替を「なんとなく難しそうだから人へ」「怒っていそうだから上長へ」といった感覚で行っていると、SLA 設計をどれだけ整えても運用は安定しません。実務では、エスカレーション 基準を「会話ログ」「コンテンツ」「AI判定」「顧客属性」の四層に分けて設計しておくと、現場に落とし込みやすくなります。

会話ログベースでは、「3往復以上の応答でも解決しない場合はチャットボット 有人切替」「ユーザーが『オペレーターにつなぐ』『人に相談したい』と明示した場合は即時エスカレーション」というように、時間と往復回数を軸にルールを定めます。コンテンツベースでは、「解約」「返金」「情報漏えい」「重大インシデント」などのキーワードを検知したら、迷わずエスカレーション 基準に従って有人チャットへ渡す、といった設計が一般的です。

AI判定ベースのエスカレーション 基準では、AIチャットボットが出した「意図推定の信頼度スコア」や「回答確信度」を利用します。信頼度が一定以下の場合は、無理に回答を続けるのではなく、SLA 設計に沿ってチャットボット 有人切替を行います。さらに、顧客属性ベースでは、VIP顧客・重要部門・経営層など、影響範囲が大きいユーザーからの問い合わせは、低いハードルでエスカレーション 基準を満たすようにしておくとよいでしょう。

こうした基準をもとに、「AIチャットボット → 一般オペレーター → 専門担当者 → 管理職」といった多段階フローを設計し、それぞれのレイヤーに対してSLA 設計を行うことで、「どのレベルで何分以内に応答するべきか」を明確にできます。有人切替の瞬間には、会話要約・参照ナレッジ・推定意図・検知キーワード・ユーザー属性を自動で引き継ぐようにしておくと、オペレーター側の負担が大きく減り、エスカレーション 基準が「机上のルール」から「現場で使えるルール」として定着していきます。

現場で機能するSLA設計とエスカレーション運用：ステップで進める導入プロセス

実務で一番難しいのは、「分かってはいるが、どこから手をつければいいか分からない」という状態から抜け出すことです。ここでは、CSと情シスが協力して、チャットボット 有人切替とSLA 設計・エスカレーション 基準を整えていくための手順を、実務に落ちる順番で整理します。

Step1：現状把握。まずは、チャネル別の問い合わせ件数・時間帯・カテゴリ・一次解決率を、ざっくりでよいので可視化します。ここで大切なのは「完璧な集計」よりも、実感を数字で共有することです。例えば「パスワード再設定」「アカウントロック解除」といった定型問い合わせはボット完結の余地が大きい一方、「契約変更」「システム障害」は有人切替が前提になりやすい、といった切り分けが見えてきます。

Step2：ターゲットSLA 設計の仮決め。次に、「まずはこの水準を目指す」というSLAを仮置きします。例として、「営業時間内のFAQレベルはチャットボットで60秒以内に解決」「有人切替後は、有人チャットが2分以内に初回応答」といった組み合わせです。社内ヘルプデスクでは、「業務継続に影響しない問い合わせは当日中」「重大インシデントは即時エスカレーション」といったSLA 設計が典型です。

Step3：エスカレーション 基準とフローの設計。上記の四層フレームを使って、有人切替の条件をフローチャート化します。ここで大事なのは、自動エスカレーション（ルールで自動的に人へ渡す）と、手動エスカレーション（オペレーターが状況判断で上長へ上げる）の両方を用意することです。CSと情シスが共同で作成したフロー図を、Slack／Teamsのワークフロー、チケット管理、CRM画面と結びつけていきます。

Step4：ツールへの実装とモニタリング。シナリオ型チャットボットであれば、分岐条件にSLA 設計とエスカレーション 基準を反映させます。LLM型チャットボットであれば、プロンプト内に「この条件のときは有人チャットへ切り替える」といった指示を埋め込みます。実装後は、「SLA達成率」「チャットボット 有人切替の件数・タイミング」「たらい回し件数」「ユーザー評価」を定期的にレビューし、条件の微調整を続けていくことで、徐々に“現場にフィットした”運用へ近づけていきます。

実務TIP：週次または月次で「SLAレビュー会議」を設定し、有人切替のログを見ながら、エスカレーションルールをCSと情シスで一緒に見直す習慣をつくると、改善スピードが一気に上がります。

CSと情シスの責任分界線と、持続可能な運用体制のつくり方

チャットボット 有人切替の運用を安定させるうえで、SLA 設計やエスカレーションルールそのものと同じくらい重要なのが、「誰が何に責任を持つか」という責任分界線です。CSは顧客接点とナレッジの専門家として、チャットボットで回答すべき内容・トーン・FAQの優先度を決める立場にあります。一方、情シスは、チャットボットや有人チャットツールの選定、ID連携、ログ管理、セキュリティ要件の担保など、技術面の責任を負います。

この2つの役割が曖昧なままだと、「誰がSLA 設計を変えてよいのか」「エスカレーションルールを増やしたいとき、どこに相談すべきか」が不明瞭になり、結果として有人切替のルールが形骸化します。そこで有効なのが、CSと情シスからメンバーを出し合い、少人数のワーキンググループとして「サポート運用チーム」を立ち上げる方法です。このチームがSLA 設計のオーナーとして、チャネル横断の指標とエスカレーションルールを管理します。

運用フェーズでは、例えば以下のような分担が考えられます。

• CS：問い合わせカテゴリ設計、FAQ・テンプレの作成と更新、有人切替時に引き継ぐ情報（要約・参照ナレッジ等）の定義
• 情シス：チャットボット・有人チャット・チケット管理・CRMの連携、ログ収集基盤の整備、SLA 設計に沿った監視とアラート設定
• 両者共同：エスカレーションルールの見直し、ユーザー向け周知（「どこまでボットで、どこから人が出るか」の明示）

外部のSaaSやBPOと連携している場合は、ベンダー側のSLAと自社のSLA 設計を突き合わせることも欠かせません。たとえば「システム障害時は即座にベンダーへエスカレーションするのか、それともまず社内一次窓口で切り分けるのか」といった運用ルールを、あらかじめエスカレーションルールとして合意しておくことで、インシデント発生時も慌てずに対応できます。責任分界線が明確であればあるほど、チャットボット 有人切替の運用は安定し、現場も安心してルールに乗れるようになります。

失敗パターンから学ぶ：設計の落とし穴とソフィエイトが支援できること

最後に、チャットボット 有人切替とSLA 設計・エスカレーションルールに関する「よくある失敗パターン」と、それを避けるポイントを整理します。代表的なのは、「チャットボットを入れればSLAが自動的に改善する」という期待からプロジェクトが始まり、設計よりもツール導入を優先してしまうケースです。この場合、エスカレーションルールがないため、難しい案件はすべて人に丸投げされ、有人切替のログを分析する余裕もないまま、「ボットは役に立たない」という評価だけが残ってしまいます。

もう一つのパターンは、CSと情シスがそれぞれ別々にツール導入を進めてしまうことです。CSは顧客向けチャットボットに注力し、情シスは社内ヘルプデスクツールを導入するものの、両者のSLA 設計やエスカレーション 基準がバラバラなため、ユーザーから見ると「窓口が多すぎてどこに聞けばいいか分からない」という状態になりがちです。この状態では、有人切替も部門間でちぐはぐになり、結果としてサポートコストが増えることも少なくありません。

株式会社ソフィエイトでは、こうした状況に対して、現状診断 → 設計ワークショップ → 実装・運用伴走という流れで支援することが可能です。具体的には、既存の問い合わせログやダッシュボードをもとに、有人切替の現状と課題を可視化し、CSと情シスが同じテーブルでSLA 設計とエスカレーション 基準を議論できる場を設計します。そのうえで、お使いのチャットボット／有人チャット／CRM／ITSMツールにあわせた実装方法や、ローンチ後のレビュー会の進め方まで含めて伴走します。

CSと情シスの両方の視点から、チャットボット 有人切替・SLA 設計・エスカレーションルールを結び直すことで、サポート現場の安定性と生産性は大きく変わります。自社だけで抱え込まず、必要に応じて専門家と一緒に設計を進めることも、現場に優しい選択肢のひとつです。

まとめ：ボットvs人ではなく、「ボット＋人」を設計する時代へ

ここまで、チャットボット 有人切替を前提にしたSLA 設計とエスカレーションルールの考え方を、CSと情シスの両方の視点から整理してきました。重要なのは、「ボットか人か」という対立構造ではなく、ボットと人をどう組み合わせれば、限られたリソースで最高の体験を提供できるかを考えることです。そのためには、チャットボットにも明確なSLA 設計を行い、チャットボット 有人切替のエスカレーション 基準を四層で定義し、現場で回せるステップに落とし込む必要があります。

また、設計だけでなく、CSと情シスが協働できる運用体制や責任分界線を整え、定期的なレビューを通じて、SLA 設計とエスカレーションルールを「改善可能な仕組み」として扱うことも欠かせません。有人切替のログは、顧客や社内ユーザーがどこでつまずいているかを教えてくれる貴重なデータです。そのデータをもとに、ナレッジの改善やフローの見直しを続けていくことで、サポート組織全体の成熟度は確実に高まっていきます。

もし、チャットボット 有人切替やSLA 設計、エスカレーションルールの設計でモヤモヤを抱えているようであれば、現状を棚卸ししつつ、外部の視点も取り入れながら、一歩ずつ改善していくことをおすすめします。その過程で、本記事の内容が少しでもヒントになれば幸いです。

チャットボットと有人チャットの役割分担を見直し、SLAとエスカレーション基準を再設計することで、顧客対応・社内サポートの両方で「早く・正確で・ストレスの少ない」体験を実現できます。CSと情シスが協力しながら、自社にとって最適なチャットボット 有人切替の仕組みづくりに取り組んでみてください。