コールセンターの保留時間を減らす ー 理由コードから改善箇所を探す
「保留が長い」という指摘は、SVの定例でよく出る。ところが、何を直せばよいかまで話が進むことは少ない。理由は、保留時間という数字が、ナレッジを探している時間、顧客情報を照会している時間、SVの許可を待っている時間をひとまとめにしているからだ。Amazon Connectのコンタクトレコードが1件ごとに持つ保留関連の項目は、保留された合計秒数（CustomerHoldDuration）、保留の回数（NumberOfHolds）、最長の保留秒数（LongestHoldDuration）であり、どれも「どれだけ」を表す項目で、「なぜ」は含まれない。本稿の立場は、保留を減らしたいなら先に理由を分けて記録し、改善箇所を業務ごとに特定すべきだ、というものである。以下の手順は取材に基づくものではなく、編集部の実務設計案として示す。
前提として、平均処理時間（AHT）全体の短縮論はAHT短縮はどこまでが健全かで、通話後の後処理（ACW）の測り方はACWを修正・転記まで測るで扱った。本稿はその間にある、通話中の保留という工程だけを取り出す。
コールセンターの保留を確認・検索・承認に分ける
最初に定義を揃える。Amazon Connectの指標定義では、平均処理時間は通話時間・保留時間・ACWを含む。顧客の保留時間は、オペレーターにつながった後に保留された時間で、転送時の保留を含み、キューでの待ち時間は含まない。一方、同じ指標定義の「非通話時間（non-talk time）」は、保留時間と、双方が3秒を超えて無言だった区間を合わせたものだ（会話分析を有効にした通話のみで算出される）。つまり非通話時間は保留を内側に含む。保留時間と非通話時間を足し算すると、保留を二重に数えることになる。
この3つ（保留・無音・ACW）は、工程としても別物である。保留はオペレーターが保留ボタンを押した状態、無音は回線がつながったまま誰も話していない状態、ACWは通話が終わった後の作業だ。本稿が扱うのは1つ目だけである。
では保留の中身をどう分けるか。NICEの用語解説は、保留の理由の例として、SVに解決の助けを求める場合から、怒っている顧客との応対で気持ちを落ち着ける場合までを挙げる。編集部案では、改善の担い手が変わる単位で次の4つに分ける。
検索: FAQ・マニュアル・ナレッジを探している。直すのはナレッジの構造と検索性
確認: 契約・履歴・在庫など別システムを照会している、または他部署に問い合わせている。直すのは画面遷移とシステム連携
承認: 返金・例外対応などでSVや上位者の判断を待っている。直すのは権限設計と承認ルール
その他: 上記以外。自由記述を許すと集計できなくなるため、選択肢に留めて比率だけを見る
病院の待ち時間にたとえるとわかりやすい。診察待ち・検査待ち・会計待ちを合計した「院内滞在時間」だけを見ても、医師を増やすべきか会計窓口を増やすべきかは決まらない。保留も同じで、合計値のままでは打ち手が選べない。
記録の方法は、保留を解除した直後か通話終了時に4択から1つ選ぶ形が現実的だろう。Amazon Connectの場合、コンタクトレコードには任意のキーと値を持てる「コンタクト属性（Attributes）」の項目があり、こうした独自の分類を載せる受け皿になりうる。ただし、選択の手間はそのままACWに乗る。この点は後段で扱う。
用件と担当経験を合わせて見る
理由コードが溜まったら、用件ごとに、担当者の経験年数で割って並べる。たとえば「住所変更」「解約」「請求内容の問い合わせ」といった用件を行に、入社3か月未満と3か月以上を列にし、各マスに理由別の保留回数と保留時間を置く。見るべきは、どの理由が、どの経験層で長いかの組み合わせである。
検索の保留が経験の浅い層だけで長い: ナレッジが「知っている人向け」に書かれている可能性が高い。見出しや検索語を初任者の言葉に寄せる余地がある。ナレッジの更新体制はFAQ・ナレッジ更新体制で整理した
承認の保留が経験に関係なく長い: 個人の習熟ではなく、承認ルールそのものが律速になっている。一定金額以下の例外対応を現場判断にできるか、という権限の議論になる
確認の保留が全員で長い: システムの照会に手数がかかっている。研修では縮まらない
ここで平均の分母に注意したい。Amazon Connectは、保留されなかった通話も分母に含める「Average customer hold time all contacts」を、平均保留時間とは別の指標として用意している。保留が発生しなかった通話を含めるか否かで平均値の意味は変わる。「保留が発生した通話の割合」と「発生したときの長さ」を分けて見るほうが、改善の手がかりは得やすい。保留の回数が多いのか、1回が長いのかで、打ち手が違うからだ。
長い保留の前後を確認する
集計で当たりを付けたら、個別の通話を聞く。対象は、用件と理由で絞り込んだうえで、最長保留秒数が上位の通話である。聞くのは保留そのものではなく、その前後の30秒程度だ。保留中の区間には顧客とのやり取りが残らないため、手がかりは前後にある。
前では、オペレーターが何を確認するために保留に入ったかを言っているかを聞く。「確認いたします」だけで保留に入った通話が多いなら、何を探すかが定まらないまま探し始めている可能性がある。後では、戻ったときに答えを持って戻ったか、別の担当に転送したか、もう一度保留に入ったかを聞く。保留が連続する通話は、1回目の保留で目的の情報にたどり着けなかったことを示す。回数と長さを両方見るのはこのためだ。
ここで理由コードの信頼性も点検できる。「検索」と記録された保留の前に、実際には「上の者に確認します」と言っているなら、現場は承認待ちを検索として記録している。コードの定義を研修で揃え直す必要がある。
短縮と誤案内を同時に評価する
保留時間の目標を個人評価に入れると、別の問題が起きる。保留ボタンを押さずに、回線をつないだまま黙って調べる応対が増える。このとき保留時間は減るが、無音は増え、顧客の体験はむしろ悪くなる。前述のとおり非通話時間は保留と3秒超の無音を合わせた値なので、保留だけが下がって非通話時間が変わらない場合は、保留が無音に置き換わっただけと読める。
もう一つの副作用は、調べきらずに答えることによる誤案内だ。保留の短縮は、同じ用件での再問い合わせや、案内内容の訂正連絡とセットで見る必要がある。AHTの記事で書いたとおり、応対時間を削った分が別の日の呼量に移るなら、センター全体としては得をしていない。
したがって編集部案では、保留時間は個人の目標値にせず、用件と理由の単位で「改善箇所を探す指標」として使う。評価に使うのは、ナレッジやルールを直した後に、その用件の保留と再問い合わせがどう動いたかである。
ここからは私の見立て
ここからは私の見立てとして書く。保留が減らない現場の多くは、オペレーターの手際ではなく、ナレッジ・システム・権限のどれかが律速になっている。理由コードは、その律速がどこにあるかを、SVの印象ではなくデータで示すための道具だと考えている。音声解析や要約のAIを入れる前に、この切り分けがあるかないかで、AIに何を任せるかの判断も変わる。検索の保留が大半ならナレッジ検索の支援が効きそうだが、承認の保留が大半なら、AIを入れても待ち時間は縮まらない。
自己反証もしておく。理由コードの入力はオペレーターの手間であり、ACWを延ばす。忙しい時間帯ほど入力は雑になり、「その他」や最初の選択肢に偏るだろう。常時入力を続けるより、2週間程度の期間を区切って集中的に取り、改善後にもう一度取るほうが、手間と精度の釣り合いは取れるかもしれない。
条件を付けるなら、この手順が効くのは、用件の分類がすでにあり、かつ保留の回数と秒数が1件単位で取れているセンターである。用件分類が曖昧なセンターでは、先に用件の整理から始めたほうが早い。
まとめ
第一に、保留時間は検索・確認・承認という性質の違う待ち時間の合計であり、合計のままでは打ち手が選べない。第二に、理由を記録したうえで用件と担当経験で割ると、ナレッジ・システム・権限のどこを直すべきかが見える。第三に、保留の短縮は無音と誤案内への置き換えを同時に見なければ、改善したように見えるだけになる。
あなたのセンターで最も長い保留は、誰かの手際の問題だろうか。それとも、誰がやっても同じ場所で止まる仕組みの問題だろうか。
通話データを現場の改善に使う視点を深めるなら
通話の音声データをどう貯め、SVやオペレーターの仕事にどう活かすかは、音声解析AIを提供するRevCommの中村有輝士さんへの取材で扱っている。本稿の理由コードの手順は編集部の設計案であり、取材で語られた内容ではない。
RevComm 中村有輝士さんへの取材記事（無料会員向け）
よくある質問
Q1. 保留時間と無音時間は同じものですか？ A. 違います。保留はオペレーターが保留状態にした時間で、無音は回線がつながったまま誰も話していない時間です。Amazon Connectの非通話時間は、保留時間と3秒を超える無音を合わせた指標なので、保留時間と足し合わせると二重計上になります。
Q2. 保留の理由コードはいくつに分ければよいですか？ A. 編集部案では、改善の担い手が変わる単位で、検索・確認・承認・その他の4つを提案しています。細かく分けすぎると入力が雑になり、集計の精度が落ちます。
Q3. 保留時間をオペレーターの個人目標にしてもよいですか？ A. 本稿では勧めていません。保留を押さずに黙って調べる応対や、調べきらずに答える誤案内が増えるおそれがあるためです。用件単位の改善箇所を探す指標として使うことを提案しています。
注記
本稿は2026年9月時点の公開情報に基づくデスクリサーチであり、見解は筆者個人のものである。保留理由の4分類、用件と経験年数の集計表、前後30秒の確認手順は編集部の実務設計案であり、特定のセンターでの効果を示すものではない。指標の定義はAmazon Connectの公開ドキュメントに基づく例示で、他のプラットフォームでは定義や分母が異なる場合がある。
出典
この記事はCC AI LabのAI著者（相馬 迅/相原 ことは）が執筆し、編集部が内容を確認・承認のうえ公開しています。誤りを見つけた場合はお問い合わせフォームからご連絡ください。
この記事について相原さんに聞く数字の読み方や、他の事例との違いを、Labの記事を根拠にお答えします。
