コールセンターKPIダッシュボードの作り方 ー 応答率・一次解決率・コストを一枚にする

月次の経営会議で、コンタクトセンター（コールセンター）のダッシュボードを映す。応答率は前月比で改善、一次解決率は横ばい、1件あたりコストはやや上昇。説明を終えたところで経営側から「それで、どこを直せばいいのか」と聞かれ、答えが画面のどこにも載っていない。指標の数は足りているのに、判断に使えない報告画面は珍しくない。本稿の問いは「どの指標を載せるか」ではなく、「経営が改善箇所を決められる並べ方とは何か」である。私の立場を先に言えば、報告画面の出来は指標の選び方より、定義の脚注と用件別の分解、そして次の判断を書く欄の有無で決まると考えている。以下の手順と図例は編集部の提案であり、図例の数値はすべて架空である。

1. 現場指標と経営判断を対応させる

最初にやるべきは、指標を並べる前に「経営がこの画面で何を決めるのか」を書き出すことだ。コンタクトセンターについて経営が下す判断は、おおむね次の3種類に収まる。

• 人員と予算を増やすか減らすか（採用・外部委託・シフト）

• どの用件の仕組みを直すか（ナレッジ、権限、手続き、Webやボットへの移管）

• AIやシステムへの投資を続けるか（導入済み施策の継続判断）

この3つに、現場指標を1対1で対応させる。応答率や放棄呼率、サービスレベルは「待たせているか」を示すので、主に人員と予算の判断材料になる。一次解決率や再入電率は「解決できているか」を示すので、どの用件の仕組みを直すかの判断材料になる。1件あたりコストは投資判断の材料だが、分子に何の費目を入れるかで意味が変わる。費目の切り分けはROI試算の費目を分解した記事で扱ったので、本稿では前提として引き受ける。

地図に例えるなら、指標は現在地を示す座標で、判断は目的地である。座標だけを並べた地図では、どちらへ歩けばよいかは分からない。対応表を画面の設計図として先に作り、どの判断にもつながらない指標は、報告画面から外して現場の運用画面に残す。指標を減らすことは情報を捨てることではなく、見る人に合わせて置き場所を分けることである。

2. 分母・期間・チャネルを脚注に置く

報告画面で最も揉めるのは、数字の良し悪しではなく「その数字は何を数えたのか」である。同じ名前の指標でも、製品によって分子と分母が違う。

例えばAmazon Connect（管理者ガイド上の表記はAmazon Connect Customer）のメトリクス定義では、サービスレベルは「キューに追加されてから0〜X秒の間にキューから取り除かれたコンタクトの割合」と定義され、取り除かれる事由には応答のほか、顧客の放棄とコールバック要求が含まれる。放棄率はキュー内で顧客が切断したコンタクトの割合で、コールバック待ちに移ったコンタクトは放棄に数えない。平均処理時間（AHT）は通話・保留・後処理（ACW）を含む。

一次解決率はさらに注意が要る。同じ定義ページには「Contacts resolved in X seconds」という指標があるが、これはコンタクト開始から切断または後処理終了までの時間で数えるもので、用件が解決したかどうかは見ていない。一次解決に相当するのは「Cases resolved on first contact」というケース単位の指標で、クローズ済みのケースのうち、紐づくコンタクト（通話・チャット・メール）がちょうど1件だったものの割合として計算される。名前に「resolved」が入っていても、時間で数える指標と用件で数える指標がある。

製品側で定義を切り替えられる場合もある。Genesys Cloudの分析設定では、サービスレベルの計算に放棄・短時間放棄・フローアウトを含めるかを管理者が選べ、短時間放棄とみなす秒数の区切りも設定で変えられる。つまり同じ製品を使っていても、センターごとに設定が違えば数字は比べられない。

このため編集部は、報告画面のすべての指標に次の4点を脚注として付けることを提案する。

1. 分母: 何を数えた件数か（着信・キュー投入・応答・ケース）

2. 期間: 集計期間と、再入電を数える窓（例: 同一顧客・同一用件で7日以内）

3. チャネル: 電話のみか、チャット・メールを含むか

4. 除外条件: 短時間切断、コールバック移行、時間外着信などの扱い

脚注は小さな文字で構わないが、省略はしない。放棄呼率の数え方は放棄呼率の計算方法を分解した記事で、事例やベンダー資料との突合は指標定義の突合チェックリストで詳しく扱っている。定義を変えた月は、変更前後で数字を並べず、変更を注記してから比較を再開する。

3. 平均と用件別の悪化を分けて見る

全体の平均だけを載せた画面は、悪化を隠す。例えば、センター全体の一次解決率が前月と同じでも、件数の多い用件が少し改善し、件数の少ない用件が大きく悪化していれば、平均は動かない。経営が知りたいのは後者である。

以下は説明のための架空の図例である（実在のセンターのデータではない）。

全体の数字だけなら「横ばい、問題なし」で終わる。用件別に割ると、解約・プラン変更の一次解決率が9ポイント下がっており、ここが今月の論点だと分かる。平均は体温計のようなもので、熱があるかどうかは分かっても、どこが悪いかまでは教えてくれない。

画面の作り方としては、上段に全体の数字を置き、その直下に「前月から一定幅以上悪化した用件」だけを抜き出して表示する形を編集部は勧める。全用件の表を常に並べると画面が埋まり、結局誰も見なくなる。悪化幅のしきい値は、件数の少ない用件で偶然の揺れを拾いすぎないよう、件数の下限とセットで決める。一次解決率の改善策そのものは一次解決率を上げる設計の記事で扱っているので、本稿は「悪化をどう見つけるか」までに絞る。

同じことは応答率にも言える。月平均の応答率が目標を満たしていても、特定の曜日や時間帯で大きく割り込んでいれば、その時間帯の顧客は待たされている。サービスレベルと稼働率のトレードオフを整理した記事で述べたとおり、平均で人員を置くと波の山で崩れる。報告画面には、月平均の横に「目標を下回った時間帯の数」を添えるだけでも、人員判断の材料になる。

4. 次の判断と担当を一枚に載せる

最後の設計要素は、数字ではなく文章の欄である。報告画面の下段に、次の3列の表を置く。

例はいずれも架空である。この欄があると、会議の問いが「この数字は良いのか悪いのか」から「この判断をするか、しないか」に変わる。判断を先送りした論点は、翌月の画面に残し続ける。消し込みの履歴が残ることで、報告画面は単なる数字の一覧ではなく、判断の記録になる。

1件あたりコストの扱いにも一言添えておく。コストは下がれば良い指標に見えるが、一次解決率が下がって再入電が増えた月は、件数が増えて1件あたりコストが下がって見えることがある。分母が処理件数なら、解決できずに増えた再入電も分母を膨らませるからだ。コストは単独で載せず、一次解決率と同じ行に並べ、両方が同時に改善しているかを見る。コストと売上・解約の関係を画面に載せたくなる場面もあるが、両者の因果は本稿の範囲では検証していない。相関を並べる場合も「因果は未検証」と注記しておくことを勧める。

5. ここからは私の見立て

ここからは私の見立てとして書く。AIの導入が進むほど、この報告画面の設計はむしろ難しくなると考えている。ボイスボットやチャットボットが定型の用件を吸収すると、有人窓口に残るのは解約や苦情のような難しい用件になり、有人部分の一次解決率やAHTは導入前より悪く見えやすい。全体の平均だけを見ている経営は、それを「AIを入れたのに人の生産性が落ちた」と読み違えかねない。用件別の分解と、AIと有人のどちらで受けたかの区別を画面に持っていないセンターほど、この誤読が起きやすいはずだ。

自己反証を一つ置く。用件の分類が現場で安定していないセンターでは、用件別の表そのものが信頼できない。オペレーターさんが後処理で選ぶ分類が人によってぶれていれば、「悪化した用件」は分類のぶれかもしれない。その場合は、用件別の表を作る前に分類ルールの統一と抜き取り確認を先に済ませる必要がある。分解は万能ではなく、分類の品質を前提にしている。

現場の指標を経営の言葉につなぐという論点は、サポート部門の役割を事業モデルから問い直す議論とも地続きである。元HubSpot Japanの1人目のカスタマーサクセスで、現在はTSUMAMI CONSULTING代表取締役の川村拓司氏との対談では、カスタマーサクセスの使命を既存顧客のLTV最大化と定義したうえで、サポート組織がサクセスへ転換する際の壁と、その成果を売上で証明する難しさを語っている。川村氏との対談記事は無料会員登録で全文を読める。

まとめ

第一に、報告画面は指標を並べる前に、経営が決める判断（人員・仕組み・投資）と指標を対応させて設計する。第二に、応答率や一次解決率は製品や設定で分子・分母が変わるため、分母・期間・チャネル・除外条件の4点を脚注に必ず置く。第三に、平均は悪化を隠すので用件別の悪化を抜き出し、画面の下段に次の判断と担当を書く欄を設ける。あなたのセンターの報告画面を見た経営は、会議の後に何か一つでも判断を下せているだろうか。

よくある質問

Q1. コールセンターのKPIダッシュボードには何の指標を載せればよいですか？ 指標名から選ぶのではなく、経営がその画面で下す判断から逆算するのが編集部の提案である。待たせているか（応答率・放棄呼率・サービスレベル）、解決できているか（一次解決率・再入電率）、いくらかかっているか（1件あたりコスト）の3系統を、それぞれ人員・仕組み・投資の判断に対応させる。

Q2. 一次解決率は製品の標準レポートの数字をそのまま使ってよいですか？ 定義を確認してから使う。例えばAmazon Connectでは、時間で数える「Contacts resolved in X seconds」と、ケース単位で数える「Cases resolved on first contact」が別の指標として存在する。自社の製品で何を分母にしているか、再入電を何日の窓で数えるかを確認し、脚注に書く。

Q3. 全体の平均が安定していれば問題ないのでは？ 平均が安定していても、件数の少ない用件が大きく悪化していることがある。全体の数字の直下に、一定幅以上悪化した用件を抜き出して表示すると、改善箇所を見落としにくくなる。

Q4. 1件あたりコストはどう載せればよいですか？ 一次解決率と並べて載せる。再入電が増えると処理件数が増え、1件あたりコストが下がって見えることがあるためである。売上や解約との関係を載せる場合は、因果が検証されていない旨を注記する。

注記: 本稿は2026年9月18日時点で確認できた公開情報に基づく編集部のデスクリサーチであり、報告画面の設計手順は編集部の提案です。表中の用件・構成比・一次解決率などの数値はすべて説明用の架空データです。指標の定義は製品・バージョン・設定によって異なるため、実際の設計では自社で利用している製品の最新ドキュメントと設定画面を一次確認してください。

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