チャットボットの有人引き継ぎ対応時間｜目標と案内の決め方

チャットボットが「担当者へ引き継ぎました」と返した後、利用者は、いつ連絡が来るのか分からないまま待つことがあります。画面に受付完了と表示されても、人が内容を確認したのか、営業時間外なのか、返信が翌営業日になるのかが分からなければ、同じ問い合わせの再送や別窓口への重複連絡につながります。

一方、「必ず5分以内」のような目標を先に決めても、担当者が常駐していなければ守れません。簡単な質問への返信を急ぐあまり、期限の迫った重要な相談がキューの後ろで待ち続けるおそれもあります。速さだけを追うのではなく、何を返信と数えるのか、どの案件を先に扱うのか、解決まで時間がかかる場合に何を伝えるのかを決める必要があります。

チャットボットの有人引き継ぎ対応時間は、受付確認、初回の実質回答、途中更新、解決を分け、実際の需要と対応体制を基に目標を決めます。他社が公開するSLAの数値を借りるのではなく、自社が継続して守れる範囲を確認します。超過が見込まれる場合は、利用者が次の行動を選べるよう、次回の連絡時刻や代替手段を先に案内します。

有人引き継ぎの対応時間に万能な正解はない

「応答時間」という言葉には、少なくとも三つの意味が含まれます。一つ目は、チャットボットが画面へ返答を表示するまでのシステム上の時間です。二つ目は、提供会社が製品障害の調査へ着手するまでの契約上の時間です。三つ目は、利用者の相談を有人担当者が確認し、内容に応じた返事をするまでの時間です。有人引き継ぎの運用で主に管理するのは三つ目ですが、資料や管理画面に「応答時間」とだけ書かれている場合は、どの時間を指すのかを確認しなければなりません。

公開されているPKSHA ChatAgentのSLAには、製品インシデントのレベル別に、対応着手・対応完了の目標やサポートデスクの営業時間が示されています。ただし、これは提供会社と契約者の間で製品障害を扱うための条件例です。店舗や企業がエンドユーザーへ返信する時間の一般基準ではありません。個別ベンダーの数値を、そのまま自社の有人返信目標やSocratesの保証として扱わないようにしてください。

LINE公式アカウントのヘルプには、利用者のメッセージに対するおおよその応答時間をプロフィールへ表示する説明があります。KABU&の公開規約には、チャットボットと有人対応で異なる利用時間を示す例があります。これらの公開例から確認できるのは、「今送った問い合わせを人がいつごろ確認するのか」を利用者が判断できる表示の重要性です。各社が示す時間や機能を、自社へそのまま転用できるわけではありません。

対応時間を決める前に、AIから有人対応へ切り替える条件と引継ぎ項目を整理します。そのうえで、有人キューへ入った案件の時間管理を本稿の方法で設計してください。「いつ人へ渡すか」と「渡した後、いつまでに何を返すか」は関連していますが、別々に定義すべき運用ルールです。

最初に四つの時計を分ける

最初から「何分以内」と決めるのではなく、時間の名称、開始条件、停止条件、利用者へ返す内容を定義します。少なくとも、受付確認、初回の実質回答、途中更新、解決の四つを分けてください。Zendeskの製品ヘルプでも、ライブチャットの初回返信時間と会話中の次回返信時間を別の目標として扱っています。ただし、自社でどの指標を取得できるかは、導入製品の最新仕様を確認する必要があります。

受付確認は自動化できますが、有人担当者による初回回答とは別です。「受け付けました。担当者から連絡します」という文面は、受付済みであることを伝える通知であり、相談内容を理解したうえでの返事ではありません。自動受付を初回回答へ含めると、管理画面上の時間は短く見えても、利用者が実際に待った時間を把握できなくなります。

初回の実質回答は、最終的な解決と同じである必要はありません。たとえば、請求内容の確認に別部署の調査が必要なら、「対象の請求番号を確認しました。経理担当へ照会し、明日15時までに、解決していない場合も状況をご連絡します」と返します。これにより、担当者が内容を確認したことと、次に連絡が来る時刻が分かります。最終回答が出るまで沈黙するのではなく、途中更新の時刻を明示することが重要です。

解決の定義も業務ごとに決めます。情報を案内した時点、手続きが完了した時点、利用者が結果を確認した時点のどこで終了とするかにより、解決時間は変わります。利用者からの返信待ちで時計を一時停止する場合は、停止条件、再開条件、一定期間返信がない場合の終了方法を記録してください。担当者の判断だけで自由に時計を止められる状態は避けます。

目標時間を需要と処理能力から決める

目標時間は、競合サイトに掲載された「何分以内」という数値ではなく、自社の記録を基に決めます。最初に2〜4週間程度の試行期間を設け、曜日・時間帯ごとの到着件数、問い合わせ分類、初回の実質回答までの時間、処理に要した時間、実働可能な担当体制を記録します。2〜4週間は普遍的な基準ではありません。季節変動や問い合わせ件数に合わせて期間を調整し、十分なデータが集まるまでは暫定目標であることを明記します。

一日当たりの平均件数だけでは、混雑する時間帯を判断できません。月曜の午前、キャンペーン直後、申込締切前など、問い合わせが集中する時間帯を分けて記録します。同時に、担当者が会議、電話、調査、承認などに使う時間も含め、チャット案件へ実際に割ける時間を確認します。名簿上の人数を、そのまま処理能力として数えないことが大切です。

目標は一つの平均値ではなく、「対象案件のうち、決めた時間内に初回の実質回答ができた割合」として管理できます。ただし、達成率や時間に全組織共通の正解はありません。まず現状を測り、利用者への影響と改善できる範囲を確認したうえで、通常時に継続して守れる暫定値を置きます。繁忙期にも同じ目標を維持するなら、当番体制や受付範囲を変更できるかも併せて検討します。

目標時間を短くする前に、AIで回答する範囲、有人対応へ切り替える条件、引継ぎ要約、担当部署への振り分けを見直します。有人対応が不要な案件まで大量に流れれば、期限や影響の大きい相談も遅れます。問い合わせのカテゴリと優先度を整理する際は、問い合わせ対応のAI分類も参考にしてください。

優先度ごとに時計の開始と停止を決める

すべての問い合わせを到着順だけで処理すると、期限が迫った案件や業務への影響が大きい案件まで待たせることがあります。一方、利用者が「緊急」と入力しただけで最優先にすると、担当者によって分類がぶれます。期限、業務影響、代替手段、必要な専門性、安全・規程上の扱いを組み合わせ、誰が担当しても同じ判断に近づく基準を作ります。

通常、優先、専門確認などの区分ごとに、対象条件、初回の実質回答、途中更新の目標を設定します。具体的な時間は、自社の実測値と勤務体制から決めてください。優先度が高い案件でも、解決までの時間を必ず短くできるとは限りません。専門的な調査が必要な案件では、初回確認と途中更新を早め、解決見込みは確認できた段階で伝える運用が現実的です。

時計の開始点は、利用者がメッセージを送信した時、ボットが引継ぎ条件を満たした時、回答に必要な項目がそろった時など、候補の中から明確に定めます。営業時間外を内部の目標時間から除外する場合でも、利用者にとっての待ち時間は送信時から始まっています。受付画面には、有人窓口の営業時間、次の営業開始時刻、返信の目安を表示してください。内部指標から除外することを理由に、利用者への案内を省いてはいけません。

利用者からの回答待ちで時計を止める場合は、何を質問したのか、いつ停止したのか、返信後にいつ再開するのかを記録します。社内承認待ちや担当者不在を、利用者待ちとして扱ってはいけません。また、担当変更や部署転送のたびに時計をリセットすると、組織全体としての待ち時間を測れません。最初の受付時刻は案件に保持し、会話経緯とともに次の担当者へ渡します。

待つ利用者へのメッセージを四場面で用意する

利用者へのメッセージは、謝罪を伝えるだけでなく、受付状況と次の行動を判断できる内容にします。営業時間内の受付、営業時間外の受付、遅延が見込まれる時、調査継続・解決時の四場面を用意し、実際の運用と一致させます。担当者が返信できない時間帯に「まもなく対応します」と表示しないことも重要です。

返信の目安は、「数分」のような曖昧な表現ではなく、有人窓口の営業時間と組み合わせて示します。ただし、守れない時刻を機械的に表示してはいけません。現在の混雑状況を反映できない仕組みであれば、通常時の目安であること、受付順や問い合わせ内容によって変わること、遅延時にどの方法で連絡するかを説明します。

「24時間受付」と「24時間有人対応」は同じではありません。メッセージの送信だけを常時受け付ける場合は、担当者が確認する曜日と時間も併記します。祝日、年末年始、臨時休業などで通常と異なる場合は、開始画面と受付メッセージの両方を更新し、過去の返信目安が表示されたままにならないよう確認します。

目標を超えた後に初めて対応するのではなく、残り時間やキュー内の古い案件を確認し、超過が見込まれる段階で連絡します。解決予定が分からないのに「本日中に解決します」と断定せず、次に状況を連絡する時刻を約束してください。新しい情報がない場合でも、確認中の内容と次回連絡時刻を伝えれば、利用者は受付が放置されていないことを確認できます。

これらの文面は、そのまま使える完成済みの定型文ではありません。受付番号を発行しない運用なら番号の記載を外し、利用できない代替窓口は載せないでください。個人情報や本人確認情報が必要な場合は、通常のチャット本文へ入力させず、社内で安全性を確認した取得手順へ案内します。表示内容と情報の受け取り方を確認する際は、チャットボットのプライバシー表示チェックも参照してください。

平均ではなく長く待つ案件を見つける

平均返信時間だけでは、大部分の案件へすぐに返す一方、一部の案件を何日も待たせている状態が隠れます。週次では、初回の実質回答時間の中央値、目標内達成率、長く待つ層の時間、未対応件数、最古案件の経過時間を並べて確認します。案件数が少ない場合は百分率だけで良否を判断せず、対象案件を一件ずつ確認してください。

問い合わせ分類ごとに集計すると、遅延の原因を特定しやすくなります。特定部署への振り分けが遅い、本人確認で往復が増える、営業時間外の受付が朝に集中する、AIの要約が不足して担当者が会話を読み直す、といった違いを確認します。単に担当者へ対応を急がせるのではなく、受付項目、振り分け、参照する正本、承認手順、当番体制のどこを変えるのかを決めます。

数値を短く見せるために、難しい案件を終了扱いにしたり、別部署へ移した時点で時計をリセットしたり、未回答案件を集計から外したりすると、指標が利用者の待ち時間を表さなくなります。除外条件は、テスト送信、重複、スパムなど具体的に定め、除外した件数も残します。返信時間だけに偏らず運用品質を確認するには、チャットボットの効果測定とKPIも参考になります。

目標未達が続く場合は、目標を緩める前に、到着量の変化、有人対応へ渡す条件、勤務体制、専門担当の確認待ち、通知漏れを調べます。そのうえで、現在の体制では継続して守れないと判断した場合は、利用者向けの表示と内部目標を現実に合わせて更新します。短い返信目安を表示しながら、実際には恒常的に超過している状態を放置しないでください。

公開前に引き継ぎキューをテストする

設計した時間ルールと案内が、実際の画面や担当者の作業で機能するかをテスト用の問い合わせで確認します。通常の営業時間、終了直前、営業時間外、担当者不在、混雑、追加質問、別部署への転送を試してください。実際の顧客情報は使わず、テストデータであることが分かる内容と、安全性を確認した環境を使用します。

1. 受付：利用者へ受付状態、営業時間、返信目安、代替窓口が正しく表示される。
2. 通知：担当キューと代行者へ通知が届き、見落とした場合の再通知が動く。
3. 引継ぎ情報：質問、選択内容、受付時刻、優先度の判断に必要な情報が過不足なく届く。
4. 時計：受付確認、初回の実質回答、途中更新、解決が定義どおりに記録される。
5. 時間外：営業再開時に古い案件から確認でき、利用者へ誤った即時対応表示を出さない。
6. 遅延：超過前に担当者へ警告され、次回の連絡時刻を利用者へ伝えられる。
7. 転送：部署を変えても受付時刻と会話経緯が失われず、同じ質問を繰り返さずに済む。
8. 終了：解決条件、再開方法、利用者待ちによる停止・再開が記録される。

キューや通知自体が障害で動かない場合は、通常時の返信目標による管理を続けず、障害対応へ切り替えます。停止時の判断、代替窓口、復旧連絡は、AIチャットボット障害対応プレイブックに沿って確認してください。ベンダー側の稼働率や障害時のサポート条件を確認する場合は、顧客への有人返信目標とは分けて、チャットボットSLA契約の確認方法を参照します。

自動振り分け、通知、営業時間設定、履歴、集計など、製品で利用できる機能は最新の仕様と契約で確認します。必要な機能がない場合は、共有キュー、当番表、受付台帳、定時確認を組み合わせて運用する方法もあります。ただし、複数の表へ個人情報をコピーする運用や、担当者個人だけに通知が届く設計は避け、閲覧権限、正本、代行担当を明確にしてください。

対応時間ルールの完成チェック

• システムの応答時間、ベンダーの障害対応時間、顧客への有人返信時間を区別した
• 受付確認、初回の実質回答、途中更新、解決の開始条件と停止条件を定義した
• 自動受付を、有人担当者による初回の実質回答として数えていない
• 実測した到着件数、処理時間、勤務体制を基に暫定目標を決めた
• 期限、影響、代替手段、専門性、安全・規程を基に優先度を決めた
• 営業時間外、休業日、混雑時の表示と次回連絡の方法を用意した
• 超過後ではなく超過前に、次の連絡時刻を伝える手順を作った
• 平均だけでなく、目標内達成率、滞留件数、最古案件を確認する
• 部署転送や担当変更によって、最初の受付時刻をリセットしない
• 通常、時間外、不在、混雑、遅延、転送、終了の各場面をテストした

有人引き継ぎの品質は、最短の返信記録だけでは判断できません。利用者が受付状態を理解し、次の連絡時刻を把握し、急ぐ場合には代替手段を選べることが重要です。まず一週間分の案件について、受付時刻、自動通知時刻、人が内容を確認して返信した時刻、途中更新時刻、解決時刻を分けて記録してください。実際の待ち時間が見えれば、継続して守れる目標と必要な体制を具体的に検討できます。

よくある質問