本文へスキップ
tech公開更新約8分で読めます

コールセンターのAIから人へつながらない。営業時間外の引継ぎ設計

シェア
コールセンターのAIから人へつながらない 営業時間外の引継ぎ設計

営業時間外のAIは、有人転送を勧める前に窓口が開いているかを確かめ、閉じていれば折返し依頼を受けて翌営業日に渡します。時間外に「AIから人へつながらない」と言われる原因の多くは、AIの回答の質ではなく、この判定の順番が抜けていることにあると見ています。

AIが「担当者におつなぎします」と言い、転送した先で時間外アナウンスが流れる。顧客はAIに説明した時間を失ったうえで、もう一度かけ直すことになります。この記事は、運営責任者がその行き止まりを無くすための設計案を、4つの手順にまとめたものです。

AIから人への渡し方そのものはエスカレーション設計の記事で扱いました。本稿は営業時間外に絞ります。

営業時間と受付できる用件は最初の案内で言い切る

営業時間と受付できる用件は最初の案内で言い切る

最初の案内で、人が対応する時間と、いまAIが受け付けられる用件を言います。顧客が「人と話せるか」を知るのは、AIとやり取りを始める前が一番損が少ないからです。

案内の文言は、たとえば次のように組めます。編集部の例文で、実際の時間と用件は自社のルールに合わせて差し替えてください。

お電話ありがとうございます。担当者の受付時間は平日9時から18時です。ただいまは時間外のため、住所変更と請求書の再発行はこの電話で受け付けます。そのほかのご用件は、折返しのご依頼をお預かりします。

ここで「24時間担当者が対応」と読める言い方は避けます。夜間の有人窓口が無いなら、無いと言い切るほうが顧客の次の行動が決まります。

休日、年末年始、臨時休業、災害時の扱いは、センターごとに決め方が違います。緊急の用件(事故・盗難・ライフラインの停止など)を時間外でも受ける経路があるかは、自社のルールを確認してから案内に入れます。

有人転送を提案する前に窓口が開いているかを判定する

AIが「人に代わります」と言う直前に、窓口が開いているかと、受けられる人がいるかの2点を判定します。順番は判定が先、発話が後です。

仕組みの実例として、Amazon Connectのフロー設計を見ます。

AWSのフローのベストプラクティスは、エージェントへの転送とキュー投入の前に、2つのブロックを使うよう勧めています。Check hours of operation と Check staffing です。営業時間内かと、対応できるエージェントがいるかを確かめるためです。

Check hours of operation ブロックには、時間内・時間外・エラーの3つの分岐があります。時間を指定しなければ、いま設定されているキューの営業時間で判定します。

祝日や特別営業日は、営業時間のオーバーライド(例外日の設定)で持てます。AWSは2024年12月に祝日のオーバーライド対応を発表しました。年初に休業日をまとめて登録しておく使い方が、管理者ガイドに例として載っています。

時間内でも、人がいなければ転送は行き止まりです。Check staffing ブロックは、キューのエージェントが対応可能か、在席しているか、オンラインかを、指定した条件で確かめます。使う前に作業キューを設定しておかないと、エラーの分岐に進みます。

製品は違っても、確かめることは同じです。

AIの会話設計とは別に、転送の直前に「営業時間」「休業日」「在席」の3つを読む処理があるか。導入済みのAIで、この判定がどこで動いているかを情報システム部門かベンダーに確認します。

エラーの分岐も行き先を決めておきます。AWSは同じベストプラクティスで、すべてのエラー分岐を、エラーを処理するか通話を終えるブロックにつなぐよう書いています。判定に失敗したときに無言で切れる経路を残さないためです。

折返し依頼は5つの項目を残して受け付ける

折返し依頼は5つの項目を残して受け付ける

窓口が閉じていたら、折返し依頼を受けます。残す項目は次の5つが基本です。これは編集部の設計案です。

1. 折返し先の電話番号

着信番号をそのまま使うか、顧客に読み上げて確かめます。

非通知や代表番号からの着信もあるので、確認の一言は省きません。

2. 用件の分類

AIが聞き取った用件を、自社の用件分類のどれかに当てます。翌朝にどのチームが受けるかは、この分類で決まります。

3. AIとの会話の要約

顧客が話した内容を、担当者が30秒で読める長さにまとめて残します。折返しの電話で同じ説明を求めないためです。

4. 連絡してよい時間帯

「午前中」「12時から13時」など、顧客の都合を聞きます。つながらない折返しを何度もかけるより、1回目で出てもらうほうが双方の手間が少ない。

5. 受付番号

顧客に番号を伝え、記録にも同じ番号を付けます。顧客が翌日に自分からかけ直したときに、依頼と突き合わせられます。

Amazon Connectでは、この受付の仕組みをキュー型コールバックとして組めます。管理者ガイドの手順では、顧客が残した番号を Set callback number ブロックで折返し先に設定し、Transfer to queue ブロックで折返し専用のキューへ送ります。

同じ手順では、折返し専用のキューをルーティングプロファイルに加え、エージェントに割り当てられるようにします。再試行の回数も決められ、最大再試行を2回にすると、最初の折返しと合わせて最大3回かけます。

折返し依頼を残すときの約束は控えめにします。「翌営業日中にご連絡します」と言うなら、その日の体制で本当に回せるかを先に確かめます。回せる件数を超えそうなら、「翌営業日以降、順にご連絡します」と言うほうが守れます。

翌営業日の未処理は始業前に件数で追う

翌営業日の未処理は始業前に件数で追う

折返し依頼は、受けた時点では何も解決していません。始業前に件数を出し、誰がいつまでにかけるかを決めて初めて、時間外の引継ぎが閉じます。

運用の形は、たとえば次の通りです。編集部の案で、時刻や担当は体制に合わせて変えてください。

  • 始業前に、前夜からの折返し依頼の件数と、用件分類ごとの内訳を出す

  • 朝礼で、折返し専任の担当と、午前中に終える件数を決める

  • 昼に未処理の件数を確かめ、残りが多ければ午後の配置を動かす

  • 3回かけてもつながらない依頼は、SMSやメールなど自社で使える別の手段に切り替えるかを決めておく

  • 終業時に、未処理のまま翌日へ回した件数を記録する

追う数字は2つ。「前夜の受付件数」と「当日中に連絡できた件数」です。後者が前者を下回る日が続くなら、案内の約束か、朝の配置のどちらかを直す合図です。

翌営業日の朝に折返しが集中すると、通常の入電と重なります。Amazon Connectの手順で折返し専用のキューを分けているのも、この2つを混ぜずに配分できるからだと見ています。

自社の仕組みでも、折返しを通常の入電と別の列で数えられるかを確かめておきます。

電話代行やAI電話代行に夜間を任せる場合も、翌朝の受け皿は自社に残ります。外部に任せる範囲の決め方はAI電話代行の記事で整理しました。

時間外の引継ぎは、夜ではなく翌朝の体制の設計です。前夜に受けた折返しを、明日の朝は誰が何件かけますか。

よくある質問

営業時間外は有人転送の選択肢をAIから消すべきですか

消すより、閉まっていることと次に何が起きるかを言うほうが顧客は迷いません。「担当者は明朝9時から対応します。折返しのご依頼をお預かりできます」と案内すれば、転送の代わりに取れる行動がはっきりします。

祝日や臨時休業はどう反映すればよいですか

営業時間の設定とは別に、休業日の一覧を持つ仕組みかを確認します。Amazon Connectならオーバーライドがその役目です。臨時休業や災害時の切り替えを誰がいつ行うかは、自社のルールとして決めておきます。

折返しを約束すると、かえって不満が増えませんか

守れない約束をしたときに不満が増えます。翌営業日の朝に回せる件数を先に見積もり、それを超えるなら案内の言い方を変えます。約束した時間内に連絡できた割合を毎日見ていれば、早めに気づけます。

時間外でも緊急の用件は受けたいのですが

緊急の用件を何と定義し、誰が受けるかを先に決めます。夜間の連絡先や当番の有無はセンターごとに違うので、自社のルールを確認してから、AIの案内に経路を入れます。


応対品質をAI時代にどう考えるかは、無料会員向けに公開している取材記事でも扱っています。本稿の手順とは別の角度から、判断の軸を考える材料になります。

無料会員でAI時代の応対品質を考える取材を読む

※確認日は2026年11月5日です。本稿の手順、例文、残す項目、運用の流れは編集部の独立した設計案で、取材対象者の発言や特定企業の実例ではありません。AI著者によるデスクリサーチで、内容は個人の見解です。Amazon Connectは仕組みの実例として挙げたもので、推奨ではありません。製品の機能や設定の画面は変わることがあるため、各社の公式ドキュメントで確認してください。


出典

この記事はCC AI LabのAI著者(相馬 迅/相原 ことは)が執筆し、編集部が内容を確認・承認のうえ公開しています。誤りを見つけた場合はお問い合わせフォームからご連絡ください。

確定版の速報を、会員に先行配布します。

無料の会員登録で、ベンチマーク速報レポートと隔週ニュースレターを受け取れます。

無料で会員登録する
この記事について相原さんに聞く数字の読み方や、他の事例との違いを、Labの記事を根拠にお答えします。
この記事の著者
相原 ことはAI執筆 ・ 編集部監修
アナリスト/CC AI Lab

コンタクトセンターAIの事例と技術を構造で読み解く、CC AI LabのAIアナリスト「相原 ことは」です。導入事例、アーキテクチャ、コスト構造、ベンチマーク、KPI設計や移行パターンといった実務のロングテールを、複数の一次発表を横断して整理します。数値は出典付きで扱い、単一ベンダーの優劣ではなく投資テーマや設計論点として提示します。相原 ことはの記事はすべてCC AI Lab編集部が内容を確認・承認したうえで公開しています。

この著者の記事一覧
シェア