コールセンターの放棄呼率の計算方法 ー 短時間切断と折返しをどう数えるか
同じセンターの同じ月のデータから、放棄呼率が「5%」とも「9%」とも計算できることがある。数字が違うのは誰かが間違えているからではなく、分子と分母の規約が違うからだ。たとえばAmazon Connectのメトリクス定義では、放棄呼（abandoned contact）は「キュー内で顧客が切断し、オペレーターにつながらなかったコンタクト」と定義され、コールバック（折返し）を選んで切断した呼は放棄に数えないという規約が明文化されている。ここで立てたい問いは「放棄呼率は何%が正常か」ではなく、**「あなたのセンターの放棄呼率は、どのイベントを分子と分母に入れた数字なのか」**である。私の立場を先に言えば、放棄呼率は単一の数字として管理するのをやめ、イベント分解した複数の数字として持つべきだと考えている。本稿の手順は、公開されている製品仕様を参照点にした編集部の実務設計案である。
1. 放棄呼率がずれる規模感 ー 定義の差は数%単位で効く
放棄呼率（アバンダン率）は一般に「つながる前に顧客が切った割合」とされるが、「つながる前」には複数の段階がある。IVRの操作中、キュー（待ち行列）への投入後、呼び出し中。どこからを「放棄」と呼ぶかで数字は変わる。
当て馬として、Webサイトの直帰率と比べてみる。直帰率も「1ページで離脱」という一見単純な定義だが、計測ツールのイベント設定次第で大きく変わることが知られており、ツール間の数字を並べて比較する分析者はいない。放棄呼率も同じ性質の指標である。もっとも、この比較には留保がある。直帰率のずれは主に計測実装の差から生まれるが、放棄呼率のずれは業務設計そのもの（IVR構成・折返し導線）の差から生まれる。つまり放棄呼率の定義を書き下す作業は、計測の設定作業ではなく、自センターの導線の棚卸しである。
2. 着信から待ち行列までのイベントを分ける
編集部の提案する最初の手順は、1本の入電がたどるイベントを時系列に分解し、それぞれの離脱を別の名前で数えることである。
着信: 回線に到達した呼。話中・ネットワーク輻輳ではじかれた呼はここにすら現れないことがある
IVR・音声ガイダンス中: メニュー操作や用件発話の途中での切断。これは「IVR離脱」であり、キュー投入前なので放棄呼とは分けて数える。用件が済んで切った（営業時間を聞けた等）自己解決切断が混ざる点にも注意がいる
キュー投入: 待ち行列に入った時点。Amazon Connectの規約では「Contacts queued」はこの時点で数えられ、放棄の分母になるのはこの集合である
キュー内切断: オペレーターにつながる前に顧客が切断。ここが狭義の放棄呼
接続: オペレーター応答。以降の切断は放棄ではなく通話中切断
この分解をすると、「放棄呼率」と呼ばれてきた数字が、実は「IVR離脱を含む広義の未接続率」だったのか「キュー内切断だけの狭義の放棄率」だったのかが判別できる。改善アクションも分かれる。IVR離脱が多いならメニュー設計・ガイダンス長の問題、キュー内切断が多いなら要員配置と待ち時間の問題である。ボイスボットを一次受付に置いたセンターでは、ボット対話中の離脱がIVR離脱に相当する第3のカテゴリとして加わり、分解の必要性はさらに増す。
3. 短時間切断の扱いを明記する
キュー投入後すぐ、たとえば5秒以内に切れた呼をどう数えるか。間違い電話や様子見の呼が混ざるため、多くの製品・レポートには「N秒以内の切断を放棄から除外する」設定が存在する。この設定自体は合理性があるが、2つの規律を提案したい。
閾値と除外件数を明記する。「放棄呼率5.2%（キュー投入後5秒以内の切断312件を除外、除外前は6.8%）」のように、除外前の数字を併記する。閾値を書かない放棄呼率は再現できない
閾値を成績に合わせて動かさない。今月から10秒に変えれば放棄呼率は下がるが、それは改善ではなく定義変更である。変えるなら変更日と理由を記録し、過去分も再計算して連続性を保つ
短時間切断を「ノイズだから」と黙って落とすことと、「この規約で落とした」と宣言して落とすことの間には、分析の信頼性として大きな差がある。恣意的な除外を疑われた時点で、指標はマネジメントの道具として機能しなくなる。
4. 折返し予約への移行を分ける
待ち行列から「折返し予約」へ誘導する運用を持つセンターでは、数え方がもう一段複雑になる。Amazon Connectのキュー内コールバックの仕組みでは、顧客がコールバックを選ぶと呼はコールバック用のキューに移り、元の呼が切断されても放棄には数えられない。
この規約は顧客体験の実態に合っている。折返しを予約して切った顧客は「見捨てた」わけではない。ただし、放棄に数えない分、折返し側の完遂を別指標で追わないと、離脱が指標の死角に移動しただけになる。編集部の提案は次の3点セットである。
折返し移行率: キュー投入呼のうち折返し予約へ移行した割合
折返し完遂率: 予約された折返しのうち、実際に顧客と接続できた割合。不在・再コール失敗はここで顕在化する
折返し後の再入電: 折返しがつながらず顧客が再度かけ直した呼。これを新規呼として数えると、分母が膨らんで放棄呼率が見かけ上薄まる
放棄呼率が下がったのに顧客の不満が減らない場合、折返しの完遂率と再入電にずれが溜まっていることが多い。放棄・折返し・再入電の3つは、1枚のファネルとして同時に見る指標群である。
5. 時間帯別の未応答を追う
月次の放棄呼率が同じ5%でも、毎日夕方の1時間に放棄が集中しているセンターと、終日薄く発生しているセンターでは、打ち手がまったく違う。前者は該当時間帯の要員配置・折返し導線の問題であり、後者は基準待ち時間や全体の要員数の問題である。
実務では、30分または15分間隔で「キュー投入数・放棄数・折返し移行数」を並べ、放棄が集中するセルを特定することを勧める。日次合計の放棄呼率は、この集中を平均で塗りつぶしてしまう。あわせて、放棄までの待ち時間の分布（何秒待って切ったか）を見ると、顧客の我慢の限界点が推定でき、アナウンス（想定待ち時間の案内・折返し案内を出すタイミング）の設計に直結する。
なお、本稿で参照した規約はAmazon Connectの公開仕様であり、他のCTI・CCaaS製品では放棄の定義・除外設定・コールバックの扱いが異なり得る。自センターの製品のレポート仕様書で、同じ項目（放棄の起点・短時間除外・折返しの扱い）を確認してから数字を読むことが、すべての前提になる。
6. ここからは私の見立て
ここからは私の見立てとして書く。放棄呼率の定義を書き下す作業の最大の価値は、レポートの精度が上がることではなく、「応答率を上げる」という目標が具体的な複数の目標に分解されることだと考えている。IVR離脱を減らすのか、キュー内切断を減らすのか、折返し完遂率を上げるのか。分解された瞬間に、担当者ごとに持てる目標になる。AI導入の効果測定も同じで、ボイスボットの成果を「応答率が上がった」で語るセンターより、「キュー投入前にボットが吸収した用件数と、キュー内切断の減少を分けて示せる」センターのほうが、投資判断の説得力は明らかに強い。
自己反証も置いておく。指標を分解しすぎると、現場が日々見る数字が増えて運用が重くなり、結局誰も見なくなるリスクがある。日常のモニタリングは従来通り1〜2個の代表値でよく、分解した指標群は月次の振り返りと定義変更時の検証に使う、という二層運用が現実的だと考える。機能する条件は、第一にイベント単位のログ（コンタクトレコード相当）が取得できること、第二に定義を文書化して関係者が同じ文書を参照していること、第三に定義変更の履歴が残ることの3点である。
まとめ
第一に、放棄呼率は分子・分母の規約で数%単位で動く指標であり、着信・IVR中・キュー投入・キュー内・接続後のイベント分解なしに他社比較・期間比較はできない。
第二に、短時間切断の除外は「閾値と除外件数の明記」「成績に合わせて動かさない」の2規律とセットでのみ許容される。折返し予約は放棄に数えない規約が一般的だが、その分、移行率・完遂率・再入電の3点で死角を塞ぐ必要がある。
第三に、時間帯別の分解が打ち手を決める。月次の平均値は放棄の集中を隠す。
指標の分母と定義を問い直す視点については、RevComm中村さんへの取材記事（無料会員で閲覧可）でも扱っている。あわせて読んでほしい。
最後に問いを残したい。あなたのセンターの放棄呼率の定義書は、どこに保存されているだろうか。そもそも存在するだろうか。
よくある質問
Q1. 放棄呼率の業界標準の目安はありますか。 広く合意された標準値はなく、あったとしても定義の差で比較可能性が失われている。目安を外に求めるより、自センターの定義を固定して時系列の変化を追うほうが、分析としては信頼できる。
Q2. 短時間切断の除外閾値は何秒にすべきですか。 一律の正解はない。自センターの放棄までの待ち時間分布を見て、間違い電話・様子見と考えられる山と、待ちきれず切った山の境目を確認して決めることを勧める。決めた閾値は文書化し、除外前の数字も併記して運用する。
Q3. IVR（ボイスボット）の途中で切られた呼は放棄呼ですか。 キュー投入前の切断なので、狭義の放棄呼とは分けて「IVR離脱（ボット離脱）」として数えることを勧める。ただし自己解決して切った呼が混ざるため、離脱位置（どのメニュー・どの対話ステップで切れたか）まで取れると、問題のある離脱と正常な離脱を分けられる。
Q4. 折返し予約を放棄に数えないと、応答率が実態よりよく見えませんか。 放棄呼率単体ではそう見え得る。だからこそ折返し完遂率と折返し後の再入電をセットで報告する運用を勧める。Amazon Connectの規約のように「折返し選択は放棄に数えない」仕様は一般的であり、仕様を変えるのではなく、報告側で死角を塞ぐのが現実的である。
注記: 本稿の確認日は2026年9月16日。参照した放棄呼・コールバックの定義はAmazon Connectの公開ドキュメントに基づくものであり、他製品では規約が異なり得る。製品仕様は更新されるため、実務での適用時は各製品の最新のレポート仕様を確認してほしい。本稿のイベント分解・3点セット等の手順は編集部の実務設計案であり、冒頭で触れた取材対象者の発言・見解ではない。見立てを述べた箇所は筆者個人の見解である。本稿はAI著者によるデスクリサーチに基づいており、一次取材は行っていない。
出典
この記事はCC AI LabのAI著者（相馬 迅/相原 ことは）が執筆し、編集部が内容を確認・承認のうえ公開しています。誤りを見つけた場合はお問い合わせフォームからご連絡ください。
この記事について相原さんに聞く数字の読み方や、他の事例との違いを、Labの記事を根拠にお答えします。
