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

コールセンターの折返し予約を設計する ー 守れる連絡時間の決め方

シェア
【FC要修正】コールセンターの折返し予約を設計する ー 守れる連絡時間の決め方

「ただいま混み合っています。折返しをご希望の方は1を押してください」。この案内を入れた日から、センターの放棄呼は目に見えて減る。AWSのコンタクトセンターサービスのキュー内コールバックの設定ガイドも、顧客が電話を切ったまま待ち行列上の順番を保ち、順番が来たらオペレーターから折り返してもらえる仕組みとして説明している。

ところが数週間後、「30分以内と言われたのに夕方まで電話が来なかった」という苦情が増え始める。ここで立てたい問いは「折返し予約を入れるべきか」ではなく、「受け付けた折返しを、いつまでに、どれだけ履行できるのか」である。私の立場を先に言えば、折返し予約は待ち行列を消す機能ではなく、処理を後ろの時間帯へ移す機能であり、移した先の余力を見積もらずに約束の時間を案内してはいけないと考えている。本稿は、公開されている製品仕様を参照点にした編集部の実務設計案である。

なお本稿が扱うのは有人オペレーターによる折返しの予約と履行に限る。放棄呼率の中で折返しをどう数えるかは放棄呼率の計算方法の記事で整理したので、指標の定義はそちらに譲る。

1. 折返し用の処理能力を見積もる

最初に確認したいのは、製品側の仕様上の優先順位である。AWSのサービスは2026年4月にAmazon Connect Customerへ改称されたと報じられているが、設定ガイドは折返しを着信と同じ優先度に置けば元の着信時刻の順番を保てると説明する一方で、折返しを着信より低い優先度に設定し、着信が少ない時間にだけ処理させる構成も検討するよう勧めている。後者を選んだ場合、繁忙時間帯に受けた折返しは、繁忙が終わるまで原則として動かない。

つまり見積もるべきは「折返しを何件受けたか」ではなく、**「時間帯ごとに、着信処理を終えた後の余力が何分残るか」**である。以下は編集部が作った仮の数値による試算で、1件あたりの折返し処理を6分30秒(接続後の対応6分に、不在時の発信にかかる時間の平均を上乗せした仮定)と置いた。

時間帯

配置席時間(分)

着信処理の見込み(分)

折返しに回せる余力(分)

処理できる折返し(件)

10時台

1,200

1,150

50

7

11時台

1,200

1,080

120

18

12時台

900

720

180

27

13時台

1,200

900

300

46

10時台に折返しを80本受けたとすると、12時台までに処理できるのは合計52本で、残る28本は13時台に持ち越される。この条件で「30分以内に折り返します」と案内すれば、大半の顧客に対して約束を破ることが受付の時点で確定している。守れる案内は「本日13時台までに」である。余力の分母になる着信処理の見込みは、サービスレベルと稼働率の記事やアーラン式の記事で扱った要員計算の結果をそのまま使えばよい。

当て馬として、飲食店の順番待ちを考えると分かりやすい。整理券を配る店は、店内の席数と回転を見て「あと何分」を答える。整理券を配ったこと自体は席を増やさない。折返し予約も同じで、受付は約束の記録であって処理能力の追加ではない。もっとも、飲食店と違ってコンタクトセンターは余力のある時間帯へ処理を移せるので、平準化の効果は現実にある。問題は効果の有無ではなく、移した先の余力を数えているかどうかである。

2. 時間指定と順番待ちを区別する

2. 時間指定と順番待ちを区別する

折返しには、性質の異なる2つの約束がある。

一つ目は順番待ち型である。AWSの設定ガイドでは、折返しは待ち行列上の位置を保ち、エージェントが受け入れた時点で顧客へ発信される。オペレーターが対応できない状態が続けば、折返しは作成から最大7日間キューに残り、その後自動で削除される。この型が約束できるのは「順番」であって「時刻」ではない。

二つ目は時間指定型である。GenesysのCallbackの利用シナリオでは、顧客が希望時刻を選ぶ予約型の折返しについて、希望時刻を目標の時間枠として扱い、顧客が待ち行列の先頭に来て、必要なスキルを持つオペレーターが受付可能になった時点で発信すると説明している。つまり時間指定であっても、仕様上は目標時刻であって分単位の保証ではない。同社のキャパシティルールの説明では、曜日ごとの時間枠に予約可能な上限件数を設定し、値を入れていない時間枠は予約できる余力がないものとして扱う。予約の可否判定には営業時間の設定に紐づくタイムゾーンが使われる。

編集部の提案は、案内文の段階で**「保証」か「目安」かを明記すること**である。時間指定型でも「14時〜15時の間にお電話します(目安)」のように幅と性質を伝え、順番待ち型なら「順番が来しだいおかけします。本日の目安は13時台です」と伝える。分単位の時刻を案内するのは、時間枠ごとの上限件数を実際の余力から設定し、その枠を超えた予約を受けない運用ができている場合に限るべきだろう。自社の営業時間との関係も同時に確認する。終業直前に受けた順番待ちの折返しは、仕様上は翌営業日に持ち越されうるので、受付の締切時刻を決めておかないと「今日中」の案内が成り立たない。

3. 不在・再試行・期限を決める

折返しの約束を破る最大の要因は、センター側ではなく顧客の不在であることが多い。AWSの設定ガイドでは、再試行回数を2にすると初回を含めて最大3回発信し、再試行は呼び出したが応答がない場合にだけ行われる。留守番電話につながった場合は接続とみなされ、再試行しない。再試行の上限を誤って大きな値にすると、オペレーターの無駄な作業と顧客への過剰な発信につながると注意書きもある。

同じサービスでも、顧客に先に発信し、応答を確認してからオペレーターにつなぐカスタマーファースト方式では挙動が変わる。この方式は新しい世代のインスタンスに限られ、再試行は発信側のフローで留守番電話の検知結果に応じて組み立てる。再試行として作られた連絡は待ち行列の最後尾に並び、元の位置を保たないため、優先度を調整しないと再試行のたびに待ち時間が延びる。

ここから編集部が決めておくべきだと考える項目は3つある。第一に、留守番電話を完遂に数えるか。製品が接続とみなしても、用件は何も解決していない。第二に、再試行の回数と間隔。昼休みに不在だった顧客へ10分後にかけ直しても、つながる見込みは低い。第三に、折返しの期限と最終処理。期限を過ぎた予約をいつ打ち切り、顧客にどう伝えるか(SMSやメールでの再受付案内など)を決めずにおくと、仕様上の7日間の保持期間が事実上の期限になってしまう。なお、折返し待ちの顧客がもう一度電話をかけてくると新しい着信として扱われるため、重複した予約の整理も同じ設計の中で決めておきたい。

4. 遅延時の案内と引継ぎを用意する

4. 遅延時の案内と引継ぎを用意する

見積もりが外れる日は必ず来る。そのときに約束を黙って破るか、先に知らせるかで顧客の受け止めは変わる。AWSの設定ガイドでは、折返しが待ち行列にある間に動くフローで待ち時間の指標を取得し、折返しが近いことを顧客にSMSで事前通知する構成が紹介されている。発信時に顧客へ流す案内(「ご予約いただいた折返しのお電話です」など)や、オペレーターが折返しを受け入れた直後、顧客とつながる前に聞く案内(用件の要約など)も、フローで設定できる。

編集部の実務案としては、次の3点を運用ルールに書いておくことを勧めたい。

  1. 遅延の判定基準: 案内した目安の枠が終わる一定時間前に未処理なら「遅延」とし、SVが通知を出すか、持ち越しを決める

  2. 受付時の用件記録: 折返しの冒頭で用件を聞き直すと、顧客は同じ説明を2回することになる。受付時に用件区分と要点を残し、オペレーターの画面か事前の案内で渡す

  3. 上限到達時の分岐: AWSのキュー上限の説明では、着信と折返しはどちらもキューの上限件数に数えられ、上限に達すると次の折返しはエラー分岐へ回される。エラー分岐の先で何を案内するかを決めていないと、顧客は予約が取れたかどうか分からないまま電話を切ることになる

5. 見立て ー 折返しは「約束遵守率」で管理する

ここからは私の見立てとして書く。折返し予約を導入したセンターは、効果を放棄呼率の低下で語りがちである。しかし折返しは放棄に数えない規約の製品もあり、放棄呼率が下がるのは定義上ほぼ当然と言える。本当に管理すべきなのは、案内した目安の枠内に顧客と話せた割合、つまり約束遵守率だと考えている。これは受付の時点で約束を作り、履行の時点で約束を守るという、折返しの本質そのものを測る指標だからである。

AIとの関係でいえば、受付時の用件聴取や遅延の事前通知は自動化しやすい領域で、ボイスボットやSMS配信が役に立つ余地は大きい。ただし、どれだけ受付を自動化しても、折返しを履行するオペレーターの余力は増えない。自動化で受付が滑らかになるほど予約件数は増え、余力の見積もりの重要性はかえって上がる。

自己反証を一つ置く。入電の波が小さく、ピークでも余力が残る小規模なセンターでは、ここまでの設計は過剰かもしれない。受付から数十分で確実に折り返せるなら、時間枠の上限管理や遅延判定を作り込むより、順番待ち型をシンプルに回すほうが合理的である。だからこそ、まず時間帯別の余力を一度表にしてみて、約束を破る時間帯が本当にあるかを確かめるところから始めたい。条件は3つに絞れる。時間帯別の余力が分かっていること、案内文が保証か目安かを明示していること、不在と期限の処理が決まっていること。この3つがそろって初めて、折返しは顧客との約束として機能する。

まとめ

第一に、折返し予約は待ち行列を消すのではなく処理を後ろの時間帯へ移す仕組みであり、案内する時間は時間帯別の余力から逆算する必要がある。第二に、順番待ち型と時間指定型は約束の性質が違い、製品仕様上はどちらも分単位の保証ではないため、案内文で保証か目安かを明記すべきである。第三に、留守番電話の扱い、再試行、期限、遅延時の通知と上限到達時の分岐を運用ルールとして先に決めておくことが、約束遵守率を守る前提になる。あなたのセンターが今日案内している折返しの時間は、どの時間帯の余力を数えて決めた数字だろうか。

会員向けに読める関連取材

折返しの約束を守れるかどうかは、突き詰めると「顧客がコンタクトセンターに何を求めているのか」という問いにつながります。AI導入が進むなかで「お客様が求めるのは品質なのか、解決なのか」を現場の視点から問い直した取材記事を、無料会員向けに公開しています。

【AIに『丁寧さ』はいらない?】AI時代に求められるコンタクトセンターの『応対品質』とは(無料会員限定)

本稿の手順・試算・運用ルール案は編集部の独立した設計案であり、取材対象者の発言ではありません。


注記: 本稿の製品仕様は2026年9月18日時点で各社の公開ドキュメントを確認した内容に基づく。仕様や名称は更新されうるため、導入時は利用中の製品の最新ドキュメントを確認してほしい。表の数値はすべて編集部が置いた仮の数値であり、特定のセンターの実績ではない。見立ての部分は筆者の個人的な見解である。


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

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

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

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

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

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