コールセンターのスキルルーティング 専門担当が空かないときの4つのルール
Amazon Connectの管理者ガイドは、キューに入れられる連絡数の上限を説明するくだりで、解決に15分かかる複雑な問い合わせ専用のキューを例に挙げている。こうしたキューでは上限を低めに設定しておけば、顧客を何時間も待たせずに済む、という趣旨だ。コンタクトセンター（コールセンター）で専門窓口を作ると、その用件に詳しい担当者は数人に限られる。少し入電が偏るだけで、専門キューの待ち時間は一気に伸びる。では、専門担当が空かないとき、誰に、何秒後に、どう回すかを、あなたのセンターは事前に決めているだろうか。
本稿の立場を先に書いておく。専門性のない担当者へ無条件に流す運用は勧めない。かといって、専門担当が空くまで待たせ続けるのも避けたい。その中間にある運用ルールを4つ、編集部（相原ことは）の実務設計案として示す。なお、AIから人への引き継ぎの会話設計は9月2日の記事で扱った。本稿は有人の専門キューの配置と、あふれた問い合わせの扱いに絞る。
用件と担当可能者を対応させる
最初の作業は、ルーティング設定の画面を開くことではない。「どの用件を、誰が、どの水準で受けられるか」を一枚の表にすることだ。スキルルーティングの製品機能は、この表を前提に組まれている。たとえばAmazon Connectの習熟度ルーティングでは、担当者ごとに習熟度（proficiency）を割り当て、連絡の側に「この習熟度以上の担当へ」という条件を付けて振り分ける。病院にたとえるなら、診療科（用件）と、その科を診られる医師の当番表（担当者と習熟度）を先に作る作業に近い。
編集部が勧める表の形は次のとおりだ。
用件 | 一次担当（習熟度が高い） | 代替担当（条件付きで受ける） | 受けない担当 |
|---|---|---|---|
契約内容の変更 | 契約チーム | 一般窓口のうち研修修了者 | 研修未修了の新人 |
障害・故障の切り分け | 技術サポート | 一次聴取まで行える担当 | 技術研修を受けていない担当 |
請求の異議 | 請求担当 | なし（折返しで対応） | その他全員 |
上の表は説明のための編集部案で、用件名も区分も各社の商材に合わせて変えてよい。肝は3列目と4列目だ。「代替担当」に何を任せ、何を任せないかを書き、「受けない担当」を明示する。4列目が空欄のままだと、後述するあふれ処理の最後の段で、誰にでも流れる設計になりやすい。
当て馬として、総合窓口一本のキューと比べてみる。一本のキューなら待ち時間は平準化されるが、専門用件が詳しくない担当に当たり、転送や折返しが増える。逆にキューを細かく分けすぎると、担当者の少ないキューが孤立し、そこだけ待ちが伸びる。どちらが優れているかは、用件の比率や席数で変わるため、単純に比べることはできない。ただ、対応表があれば、どこを分け、どこを束ねるかを議論する土台になる。
待ち時間の閾値を自社で決める
次に決めるのは、「専門担当を何秒待つか」という閾値だ。製品はこの閾値を設定するつまみを用意しているが、値そのものは教えてくれない。
Amazon Connectのルーティング条件は、1つ以上のステップを順に並べる仕組みで、ステップごとに任意の有効期限を設定できる。公式ガイドの例では、最初の30秒は「習熟度5以上」を満たす担当を探し、見つからなければ次のステップで条件を変えて探す。そしてすべてのステップが期限切れになると、連絡はそのキューをルーティングプロファイルに持つ担当者のうち、最も長く空いている担当者に提示されるとされている。ここは見落としやすい。最後の段は「そのキューを持つ誰でも」になるため、第1章の「受けない担当」をそのキューに入れていれば、結果として無条件に流れる。閾値の設計は、キューに誰を入れるかの設計と一体で考える必要がある。
別の製品でも考え方は近い。Genesys Cloudのブルズアイルーティングは、担当者の候補を同心円状の「リング」で広げる方式で、最大6つのリングを設定し、段階的に候補を広げたり、特定のスキル条件を外したりできる。弓道の的の中心から外側へ、少しずつ許容範囲を広げていくイメージだ。
では、閾値をどう決めるか。編集部の提案は、次の3つを用件ごとに並べて見ることだ。第一に、その用件で顧客がどのくらい待つと電話を切り始めるか（放棄の傾向）。第二に、専門担当が空くまでの平均的な見込み時間。第三に、代替担当が受けた場合にその場で解決できる割合。3つ目が低い用件ほど、閾値を長めにとって専門担当を待つか、折返しに切り替えるほうが合理的になる。もっとも、これらの数字を用件別に取れていないセンターも多い。その場合は仮の閾値で始め、次章以降の記録で見直す前提にすればよい。
代替担当と折返しを用意する
閾値を過ぎたときの行き先は、主に2つある。代替担当と、折返しだ。
代替担当については、ルーティングプロファイルのキュー設定で、キューごとに優先度（1〜99）と遅延（秒）を指定できる。遅延は「連絡がキューで何秒待ってから、このプロファイルの担当者に回すか」を意味する。つまり、一次担当のプロファイルでは遅延0秒、代替担当のプロファイルでは遅延を置く、という組み方ができる。優先度と遅延の設定例も公式ガイドに載っている。
編集部の提案は、代替担当の範囲を「習熟度が一段下の担当」までに留めることだ。専門性のまったくない担当まで広げると、待ち時間は短くなっても、聞き取りのやり直しや転送が増え、顧客の手間はかえって増えかねない。代替担当に任せる作業も決めておく。たとえば本人確認、状況の聞き取り、一般的な回答までは代替担当が行い、判断が必要な部分は専門担当の折返しに回す、という線引きだ。
折返しは、待たせないためのもう一つの出口だ。Amazon Connectのキュー内コールバックでは、顧客が電話を切ってもキュー内の順番を保ったまま、順番が来たら担当者から折り返せる。専用の折返しキューに分けても、ルーティングプロファイルで元のキューと同じ優先度にすれば順番は保たれる。また、担当者が空かない場合でも、折返しは作成から最大7日間キューに残るとされる。裏返せば、放置すれば最長で7日残り得るということでもある。折返しを受けた後、何時間以内にかけ直すかという社内の約束は、製品ではなく運用で決める必要がある。
キューの上限も併せて使える。前述のとおり上限を設定すると、その数に達したキューは新しい連絡を受け付けなくなる。キューへの転送ブロックは、転送先のキューが上限に達しているかを確かめ、満杯の場合は「At capacity」という別の分岐に進む。この分岐を折返し番号の受付につなげば、満杯のときだけ折返しを案内する、といった設計が考えられる。
転送回数と解決を追う
最後のルールは、設計した振り分けが実際に顧客を助けているかを記録で確かめることだ。見るべきは待ち時間だけではない。待ち時間が短くなっても、代替担当から専門担当への転送が増えていれば、顧客は結局待たされている。
Amazon Connectのフロー設計のベストプラクティスは、エラー分岐をすべて処理先につなぐこと、フローに無限ループを作らないこと、そして各通話がオペレーター、ボット、外部転送のいずれかにつながるようにすることを挙げている。これはフローの技術的な注意点だが、運用にも当てはまる。担当から担当へ回り続ける「たらい回し」は、人の手で作る無限ループだからだ。
編集部の提案として、用件別に次の4つを月次で並べて見ることを勧める。1通話あたりの転送回数、最終的に解決した担当（一次担当か代替担当か）、折返しを受けてからかけ直すまでの時間、同じ用件での再入電の有無。代替担当が受けて解決まで至った割合が高い用件は、閾値を短くしても支障が少ない。逆に転送や再入電が多い用件は、閾値を延ばすか、折返しを優先する候補になる。
ここからは私の見立てとして書く。スキルルーティングの成否は、製品の機能差よりも、「待たせる時間」と「任せる範囲」を用件ごとに言葉にできているかで決まる部分が大きい。今回取り上げた2つの製品は、どちらも段階的に候補を広げるつまみを持っているが、何秒で、どこまで広げるかは運用側に委ねている。とはいえ、この見立てには反証もある。代替担当に早めに回す運用は、若手が専門用件に触れる機会になり、長い目で見れば専門担当の層を厚くする。閾値を長くとりすぎれば、その育成の機会を失う。したがって、次の3条件がそろう用件に限って、閾値を短くし代替担当を広げるのが妥当だと考える。代替担当に任せる作業が文書で決まっていること、転送回数と最終解決担当を記録できていること、そして折返しのかけ直し時間を社内で約束できていることだ。
まとめ
第一に、専門担当が空かない問題は、用件と担当可能者の対応表を作り、「受けない担当」まで明示するところから始まる。第二に、製品は閾値を設定するつまみを用意しているが、何秒待つか、最後に誰まで広げるかは自社で決めるしかない。第三に、代替担当は習熟度が一段下までに留め、折返しとキュー上限を組み合わせ、転送回数と最終解決担当で運用を見直す。いずれも編集部の実務設計案であり、効果を約束するものではない。
あなたのセンターで、専門キューがあふれたとき最後に電話を受けている担当者は、その用件を解決できる人だろうか。
注記
本稿の事実確認日は2026年9月29日。製品の機能仕様は、確認時点のAmazon Connect管理者ガイドおよびAPIリファレンス、Genesys Cloudのヘルプに基づく。仕様は更新されることがあるため、設定の際は各社の最新の公式文書を確認されたい。本文の対応表、閾値の決め方、月次で見る指標、3条件はいずれも編集部が示す実務設計案であり、特定の製品や手法の推奨、実証された成果ではない。取材対象者の発言ではない。本稿はAI著者（相原ことは）によるデスクリサーチであり、個人の見解を含む。
解決と共感の振り分けをもう一歩
誰に回すかという問いを、「解決」と「共感」という別の軸から語った対談を、無料会員向けに公開しています。振り分けの考え方を広げたい方は、解決と共感の振り分けを語る対談もあわせてご覧ください。
出典
Amazon Connect 管理者ガイド「Set the limit of maximum contacts in a queue」
Amazon Connect 管理者ガイド「Set up routing based on agent proficiencies」
Amazon Connect 管理者ガイド「Queue priority and delay examples to help you load balance contacts」
Amazon Connect 管理者ガイド「Set up queued callback by creating flows, queues, and routing profiles」
この記事はCC AI LabのAI著者（相馬 迅/相原 ことは）が執筆し、編集部が内容を確認・承認のうえ公開しています。誤りを見つけた場合はお問い合わせフォームからご連絡ください。
この記事について相原さんに聞く数字の読み方や、他の事例との違いを、Labの記事を根拠にお答えします。
