AIコールセンターのKPIは、自動応対で終わった通話の割合だけでは決められません。最初に置きたいのは「対象業務が正しく完了した割合」です。その結果を再問い合わせや有人転送の成否と組み合わせて見ます。重大な誤りと後処理時間も必要です。

自動完了率が上がっても、同じ用件で電話がかけ直されていれば解決したとは言えません。人へ転送した通話も、複雑な相談を適切に引き継いだのであれば失敗ではありません。導入前に分母と完了条件をそろえることが、製品の数字を自社の判断へ変える出発点です。

自動終了ではなく正しい業務完了を数える

AIが通話を終えたことと、利用者の用件が完了したことは別です。予約受付なら、希望を聞いただけでは不十分です。予約が登録され、利用者へ確定内容が伝わった状態を完了とします。

まず一つの対象業務について、通話の終了状態を四つに分けます。

終了状態判定の例KPIでの扱い
AIで正しく完了必要な処理が完了し、記録も正しい自動完了の成功
人へ適切に引き継ぎ定めた条件で転送し、担当者が応対を継続有人連携の成功
未完了聞き取りや処理が途中で終わった改善対象
誤った完了誤案内や誤登録を完了として記録した品質事故として別集計

自動完了率の分母には、最初からAIの対象とした通話だけを使います。営業時間外や対応言語外の通話は対象外にできます。本人確認が必要な通話も除く場合があります。これらを分母へ混ぜると、製品や期間によって数字の意味が変わります。

計算式は「AIで正しく完了した件数 ÷ AI対象通話数」です。システム上の終了コードだけで確定せず、CRMの処理結果や抽出した録音で正しさを確認した方が良いです。

再問い合わせで本当に解決したか確かめる

一回の通話だけを見ると、誤った案内でも完了に見える場合があります。同じ利用者が同じ用件で再び連絡していないかを追うと、表面上の完了を見分けやすくなります。

Google Cloud Contact Center as a Serviceの目標指標では、同じキューへ複数回連絡した利用者を数える期間を設定できます。同社のコールダッシュボードの説明も、再問い合わせを設定した期間内の複数セッションとして扱っています。

自社の集計でも、再問い合わせと判断する期間と用件の一致条件を先に決めます。電話番号が同じだけでは、別件の相談まで再問い合わせになるためです。CRMに用件IDや受付番号がある場合は、通話記録とひも付けます。

再問い合わせ率が上がった用件は、会話の自然さより先に終了条件を見直します。案内が不足していたのか、処理が反映されなかったのかによって、直す場所が変わります。

有人転送は件数と成否を分ける

有人転送率は、低いほど良い指標ではありません。AIが対応すべきでない相談を早く人へ渡せたなら、利用者と業務を守るために必要な転送です。

Amazon ConnectのAIエージェント指標では、AIが関与した問い合わせのうち、人または追加支援へエスカレーションした割合をAIハンドオフ率として示しています。一方、転送後の応答までは別に確かめる必要があります。同じ説明を繰り返さずに済んだかも、自社の完了条件へ追加します。

少なくとも、次の三つを分けて記録します。

  1. 定めた条件で人へ切り替えた件数
  2. 担当者へ接続し、必要な情報を渡せた件数
  3. 無応答や誤転送で、折り返しなどの代替処理へ移った件数

転送率だけを下げようとすると、AIが難しい相談を抱え込む方向へ改善が進みます。適切な転送を成功として残し、接続失敗と不要な転送を改善対象にすると、判断を誤りにくくなります。

誤回答は平均値から切り離す

重大な誤りは、全体の成功率が高くても見逃せません。金額や契約に関する誤案内は影響が大きくなります。本人確認や緊急性の判断も同様です。軽微な聞き返しと同じ一件として平均に入れない方が良いです。

誤りを「重大」「業務影響あり」「軽微」に分け、重大なものは件数と内容をすべて確認します。残りは用件別に一定数を抽出します。人が回答根拠と処理結果を確かめ、転送判断も照合します。

Amazon Connectには、AIの目標達成を評価する指標があります。回答の完全性や会話文脈への忠実性も別に評価されます。ただし、これらは利用する環境での評価結果です。予約登録や返金処理が実際に完了したかは、業務システムの記録と照合しなければ判断できません。

放棄と後処理から利用者と担当者の負担を見る

業務が完了しても、待ち時間や担当者の作業が増えていれば、運用全体では改善していない場合があります。利用者側は放棄、運用側は後処理を補助指標にします。

Amazon Connectの指標定義では、放棄をキューで待っている間に利用者が切断した問い合わせとして数えます。短時間の放棄を除外するかによって値は変わるため、製品間や導入前後で閾値をそろえます。Google Cloudの放棄設定にも、一定秒数以内の短い放棄を監視指標から除外する設定があります。

後処理は、通話後に担当者が記録や修正へ使った時間です。Amazon Connectのカスタム指標定義は、After Contact Workを通話後の作業時間として扱っています。AI要約を導入した場合は、時間だけでなく修正した件数も数えると、短縮と品質を一緒に確認できます。

一枚の測定票で導入前後を比べる

製品のダッシュボード名をそのままKPIにせず、自社の完了条件へ対応づけます。初回検証では、次のような一枚を用意すると確認しやすいです。

見る結果定義・計算確認元判断すること
正しい自動完了正しいAI完了 ÷ AI対象通話通話結果と業務システム対象業務を広げられるか
再問い合わせ同じ利用者・同じ用件の再連絡 ÷ 完了件数通話履歴とCRM完了条件に不足がないか
有人連携の成功情報を渡して接続できた件数 ÷ 転送開始件数転送履歴と担当者記録転送先と引き継ぎを直すか
重大な誤り重大判定の件数と内容録音、文字起こし、処理結果対象停止や即時修正が必要か
放棄共通の閾値で数えた放棄 ÷ キュー投入キュー履歴待ち時間や経路を直すか
後処理担当者の後処理時間と修正件数エージェント履歴とCRM要約や記録連携が役立つか

集計単位は、センター全体だけでなく用件別にも持ちます。営業時間案内が改善しても、解約や障害受付で重大な誤りが増えていれば、全体平均では判断できません。

導入前の同じ業務について現状値を取り、AI導入後も同じ分母と期間で比較します。件数が少ない段階では率だけを見ず、対象件数と失敗事例を並べて確認してください。

最初の一週間で指標の定義を直す

初回検証では、目標値を細かく決めるより、集計した通話が同じ意味になっているかを先に確かめます。自動完了の中に誤った完了が混ざっていないか、再問い合わせを別件まで数えていないかを、実際の通話から確認します。

週次レビューでは、平均値の報告だけで終えません。重大な誤りと転送失敗を一件ずつ確認します。再問い合わせの多い用件も対象です。

原因を見た上で、回答範囲を狭めるか転送条件を変えるか決めます。変更後は同じ条件で再度測ります。

まず、導入候補の一つの用件について「どの状態なら正しく完了か」を一文で書いてみてください。その定義をもとに、AIコールセンター比較表で記録と有人連携を確認します。運用支援の範囲も見れば、必要なデータを取れる候補へ絞り込めます。