Voice AI resolution:コールを終わらせることではなく、解決を計測する指標
ディフレクションは、ボイスエージェントが何を回避したかを計測します。Voice AI resolution は、顧客がもう電話をかける必要がなくなったことを計測します。解決に報いる指標をご紹介します。
Updated
8 min read

Member of marketing staff
Neelabja Adkuloo
8 min read

Member of marketing staff
Neelabja Adkuloo
コールは、顧客が答えを得られないまま終わることがあります。転送、メールでの案内、あるいは「後ほどかけ直してください」という丁寧なお願いによって、キューから外れることもあります。ダッシュボード上では、それぞれのイベントが自動化の成功のように見えるかもしれません。しかし顧客にとっては、問題がまだ未解決のままかもしれないのです。
だからこそ、Voice AI resolutionにはより優れた計測モデルが必要なのです。
コールディフレクション(Call deflection)は、ボイスエージェントが人間から遠ざけたものが何かを教えてくれます。初回コール解決(First call resolution)は、顧客の課題が最初のやり取りの中で解決されたかどうかを教えてくれます。
この違いは、ボイス自動化がより複雑な業務へと踏み込むにつれて重要になります。エージェントには、注文、請求、チケット、アカウント履歴、システム状態を、ひとつの会話の中で確認することが期待されています。適切なコンテキストに到達できないボイスエージェントは、自然に聞こえていても、仕事そのものには失敗しているかもしれません。
Voice AI resolution とは何か?
- Voice AI resolution とは、会話型 AI のボイスエージェントが、初回のやり取りにおいてコール中に顧客の課題を完全に解決することであり、単に人間から囲い込んだり(コンテインメント)ディフレクション(そらす)したりするだけではありません。
- コンテインメントは、会話が自動化の内側にとどまったかどうかを計測します。Voice AI resolution は、顧客が正しい答えやアクションを受け取り、同じ課題について再び助けを必要としなくなったかどうかを計測します。
- この区別は、コンタクトセンターのリーダーがパフォーマンスをどう評価するかを変えます。終わったコールが、必ずしも解決されたコールとは限らないのです。
コールが解決なしに終わると、何が起きるのか?
解決されたコールには、いくつものステップが含まれることがあります。エージェントは顧客を特定し、注文を確認し、未対応のサポートチケットを見直し、現在発生しているシステムイベントをチェックし、承認済みの返金を実行し、その結果を説明する、といったことを行うかもしれません。
こうした作業は、転送なしで完了することもあります。また、状況が感情的、複雑、繊細、あるいは判断を要するものであるときには、人間への引き継ぎを含むこともあります。解決とは、すべてのコールが完全自動のまま処理されなければならないという意味ではありません。それは、顧客がすでに完了した作業を繰り返さずに済むべきだ、という意味です。
一方でコールディフレクションは、顧客が本当に結果を得られたことを証明しないまま、キューを健全に見せかけてしまうことがあります。エージェントが自分では判定できない唯一の指標は、顧客がかけ直す必要があったかどうかです。共有メモリ(Shared Memory)と Safe Actions が、解決を計測可能にします。
単純なコンテインメントの数値は、いくつもの異なる結果を覆い隠してしまいます。
- 顧客が正しい答えを受け入れた。
- 顧客が完了したアクションを受け取った。
- 顧客があきらめた。
- 顧客が別のチャネルへ回された。
- 顧客が転送された。
- コールが切れた。
- 顧客はまだ助けを必要としており、また電話をかけてくる。
明確に解決を示しているのは、最初の2つだけです。それ以外は、さらなる調査が必要です。
重要なポイント: コールが終わることはイベントです。問題が解決されることはアウトカム(成果)です。ボイス領域のリーダーは、アウトカムを計測すべきです。
なぜどのボイスプログラムも、まずコールディフレクションを掲げるのか?
コールディフレクションが人気なのは、コストとキャパシティに結びつけやすいからです。コンタクトセンターは、どれだけのコールが自動化の内側にとどまったか、どれだけが人間を回避したか、そして有人対応の量がどれだけ変化したかを報告できます。
問題が始まるのは、ディフレクションが最終スコアになったときです。
- コンタクトセンターが高いディフレクション率を祝う一方で、顧客のかけ直しが増えているかもしれません。
- エージェントは初回のコールを受ける件数は減っても、エスカレーションの対応により多くの時間を費やすかもしれません。
- 顧客は、完全な答えを受け取らないまま、ボイスからチャットやメールへと移っているかもしれません。
- 顧客はウェブサイトを検索し、メールを待ち、チケットを起票し、あるいは再び電話をかけるかもしれません。つまり、隠れた作業を取り除くのではなく、下流へと押しやっているのです。
ここが、コンタクトセンター AI がより広い運用モデルの中に位置づけられる場面です。AI は反復的な作業を減らし、エージェントがより速く応答するのを助けられます。しかしそれは、顧客の解決までの道のりを改善するかどうかで評価されるべきです。
チケットディフレクションは、量の削減と実際のサービス成果との、より広い関係をチームが理解するのに役立ちます。ボイスにも同じ規律が必要であり、加えて、コールの後に何が起きるかへの追加的な注目が求められます。
重要なポイント: コールディフレクションは、コンタクトセンターが何を回避したかを教えてくれます。それは、顧客の課題が解決されたかどうかを教えてはくれません。
隠れた失敗:解決なきコンテインメント
決済(チェックアウト)の失敗について電話をかけてくる顧客を想像してみてください。ボイスエージェントはいくつか質問し、短いナレッジベースを検索し、問題はまもなく解消するかもしれないと答えます。サポート記事へのリンクを提示して、コールを終えます。
コールはコンテインされました。人間は加わりませんでした。自動化ダッシュボードは成功として記録します。
顧客は後でもう一度試します。今回も、問題はまだ存在しています。2人目のエージェントは、最近の製品デプロイが顧客のアカウントに影響したことを突き止めます。エラーはアプリケーションログに現れています。エンジニアリングのチケットはすでに起票されています。顧客には、特定の回避策か返金が必要です。
最初のコールが失敗したのは、エージェントの声が心地よくなかったからではありません。それが失敗したのは、エージェントが課題を解決するために必要な情報に到達できず、あるいはそれを理解できなかったからです。
同じパターンは、注文状況、請求に関する異議、アカウント変更、テクニカルサポートにおいても現れます。
コールディフレクションと Voice AI resolution は、異なる成果を計測します。ディフレクションはコールが人間の支援を回避したかどうかを追跡し、解決は顧客の課題が実際に解決されたかどうかを追跡します。
メールに回されたコールは、コンタクトセンターにとっては効率的かもしれません。しかし、それが必ずしも顧客にとって効率的とは限りません。顧客は依然として待ち、課題を再び説明し、もうひとつのやり取りを管理しなければならないのです。
解決であってディフレクションではないというアプローチは、やり取りの後に何が起きたかを問います。
- 顧客は意図したタスクを完了できたか?
- 課題は解決したまま維持されたか?
- 別のチームは、作業を完了できるだけの十分なコンテキストを受け取ったか?
この問いは、人間への引き継ぎが適切な場合であっても重要です。引き継ぎが自動的に失敗を意味するわけではありません。複雑なクレーム、繊細なアカウントの問題、リスクの高い判断には、人間の判断が必要かもしれません。品質のテストは、その引き継ぎが会話を保持し、人間が続きを進められるだけの十分なコンテキストを与えているかどうかです。
重要なポイント: コンテインされたコールでも、依然として繰り返しの作業を生み出すことがあります。キューは静かになったかもしれませんが、顧客の問題が必ずしも解決されたわけではありません。
解決されたコールを計測する指標はどれか?
有用な Voice AI resolution のスコアカードは、4つの指標を追跡します。コール中解決率(resolved-on-call rate)、再コンタクト率(re-contact rate)、引き継ぎ時のコンテキスト完全性(context completeness at handoff)、そして解決あたりコスト(cost per resolution)です。それぞれの指標が、異なる問いに答えます。
1. コール中解決率(Resolved-on-call rate)
これは、顧客が申告した課題が、やり取りの中で完了したコールの割合を計測します。
コール中解決のイベントには、次のものが含まれます。
- アカウント更新の成功。
- 注文変更の完了。
- 請求修正の確定。
- トラブルシューティングによる修正の検証。
- 最新の情報に裏づけられた明確な答え。
- 顧客の確認を伴う、完了したチケットアクション。
その定義は、コールの種類によって変えるべきです。単純な要求であれば「質問に答えた」で十分かもしれません。テクニカルな問題では、検証済みのシステム変更や顧客の確認が必要かもしれません。たとえば次のとおりです。
単純な要求:
顧客がこう尋ねます。「あなたのお店の返品対応時間は何時ですか?」
ボイスエージェントは最新の店舗情報を確認し、正しい時間を提供します。顧客は必要なものを得たので、そのコールは解決としてカウントできます。
テクニカルな問題:
顧客がこう言います。「アカウントにログインできません。」
エージェントはパスワードのリセット方法を説明しますが、それだけでは解決を証明できないかもしれません。次の場合に限り、そのコールは解決としてカウントすべきです。
- パスワードのリセットが正常に完了する。
- 顧客がログインできることを確認する。
- アカウントの状態に、残存するアクセスの問題が表示されていない。
エージェントが指示を与えるだけで、顧客が依然としてアカウントにアクセスできないのであれば、そのコールは答えられたが解決はされていない、ということになります。
シンプルなルール:
- 情報の要求: 正しい答えで十分かもしれません。
- トランザクションの要求: 要求されたアクションを完了すべきです。
- テクニカルな問題: 修正を検証するか、顧客に確認してもらうべきです。
- 複雑または繊細な課題: 完全な人間への引き継ぎが、適切な解決ステップとなるかもしれません。
この指標はまた、エージェントが可能性のある解決策を提示しただけのコールを除外すべきです。提案は、顧客がそれを使って意図したタスクを完了できない限り、解決ではありません。
2. 再コンタクト率(Re-contact rate)
再コンタクト率は、顧客が定義された期間内に、同じ課題について再び組織に連絡してくるかどうかを追跡します。
その期間はユースケースによって異なります。請求の問題は、パスワードのリセットよりも長い期間が必要かもしれません。組織は一貫した手法を定義し、無関係なコンタクトを失敗としてカウントしないようにすべきです。
再コンタクトは、コンテインメントでは代替できない、顧客中心の指標です。翌日、顧客が同じ問題について再び電話をかけてくるなら、最初のコールは完全には解決されていなかったのです。
3. 引き継ぎ時のコンテキスト完全性(Context completeness at handoff)
一部のコールは人間へ回すべきです。重要な問いは、その引き継ぎが作業を引き渡しているのか、それとも単に顧客を引き渡しているだけなのか、という点です。
完全な引き継ぎには、次のものが含まれるべきです。
- 顧客が申告した、電話をかけてきた理由。
- 本人確認とアカウントのコンテキスト。
- 確認した関連レコード。
- すでに試みたアクション。
- システム上の発見事項。
- 顧客に対して行った約束。
- 次に推奨されるステップ。
- 必要な承認や制約事項。
これによって繰り返しが減ります。人間のエージェントは、顧客に最初からやり直させるのではなく、現在の状態から続きを進められます。
4. 解決あたりコスト(Cost per resolution)
コールあたりコストは、たとえ繰り返しのコンタクトを生み出すとしても、短いやり取りに報いてしまうことがあります。解決あたりコストは、課題を解決するために必要な作業を考慮に入れます。
シンプルなモデルには、次のものを含められます。
- ボイスインフラのコスト。
- エージェントまたは自動化のコスト。
- 転送のコスト。
- フォローアップチャネルのコスト。
- 繰り返しコンタクトのコスト。
- 返金、クレジット、または是正措置のコスト。
- 人間によるレビューのコスト。
問題を解決する、わずかに長いコールは、短いコールの後に2回の繰り返しコンタクトが続くよりも安上がりかもしれません。
重要な課題:ボイスエージェントは、顧客がかけ直さなければならなかったかどうかを、単独では判定できません。その指標には、顧客の行動、ひもづけられたやり取りの履歴、そして信頼できる課題のアイデンティティが必要です。さらに、新しいコンタクトが元の問題に関連しているかどうかを判定するのに十分な共有コンテキストも必要です。したがって、カスタマーエージェントは、囲い込んだコンタクトの数だけでなく、生み出した解決によって評価されるべきです。
重要なポイント: 解決のスコアカードは、4つの指標を組み合わせるべきです。コール中解決率、再コンタクト率、引き継ぎ時のコンテキスト完全性、そして解決あたりコストです。
なぜボイスには、より深いコンテキストが必要なのか?
ボイスがより深いコンテキストを必要とするのは、顧客が10個のリンクを走り読みしたり、検索結果を比較したり、エージェントが別のシステムを確認する間じっと待ったりすることができないからです。
やり取りはリアルタイムで進んでいます。顧客は、エージェントが課題を理解し、関連する質問を投げかけ、答えに向かって進んでいくことを期待します。長い沈黙や質問の繰り返しは、たちまち信頼を損ないます。
これは AI ボイスエージェントに、より高いハードルを課します。エージェントには、会話のスクリプト以上のものが必要です。顧客の状況を説明する情報へのアクセスが必要なのです。
たとえば:ある顧客が、なぜ注文が遅れているのかを尋ねています。浅いシステムなら標準的な配送予定を返すだけかもしれませんが、コンテキストを認識するエージェントは、注文、倉庫、配送業者のイベント、アカウント履歴、製品在庫、既知のインシデント、交換ポリシー、過去のコンタクトを確認します。
だからこそ、ボイスは独立したインテリジェンスのレイヤーとして扱うべきではありません。エージェントには、チャット、メール、サポート、製品、オペレーションの各チームが使うのと同じコンテキストが必要です。
運用の原則はシンプルです。
- 最新のデータが、正確な答えを支えます。
- 連携されたデータが、完全な診断を支えます。
- 権限を認識するデータが、安全な意思決定を支えます。
- アクションツールが、本物の解決を支えます。
- 引き継ぎのコンテキストが、自動化が止まったときの継続性を支えます。
コールは、会話としては優れていても、運用としては脆弱なことがあります。共感的に聞こえていても、問題を実際に解決するシステムへのアクセスを欠いていることがあるのです。
重要なポイント: ボイスは、浅い検索のコストを引き上げます。顧客には、会話がまだ進行している最中に、現在のビジネスコンテキストを理解できるエージェントが必要です。
Voice AI は、どのようにコールをエンドツーエンドで解決するのか?
DevRev の Computer 上の Voice AIは、適切なライブコンテキストを読み取り、承認済みのアクションを実行し、人間の判断が必要なときには完全な引き継ぎを保持できるとき、コールをエンドツーエンドで解決します。
Computer の Voice AIは、既存のテレフォニーおよびコンタクトセンターのシステムと並行して機能します。CCaaS プラットフォームの置き換えとして位置づけられているわけではありません。ライブの顧客コールを処理し、連携されたビジネスシステム全体でアクションを実行できる、AI による解決のレイヤーを提供します。
ワークフローは、顧客が問題を説明するところから始まります。Voice AI は意図(インテント)を特定し、ケースを理解するために必要な情報を収集します。
Computer の Shared Memoryは、製品、顧客、チケット、コード、注文、そして運用システムをまたいで、関連するコンテキストを結びつけられます。エージェントはそれによって、会話のトランスクリプトや静的な記事だけに頼るのではなく、現在の状態を踏まえて推論できます。
決済(チェックアウト)の失敗の場合、その流れは次のようになります。
Safe Actionsが重要なのは、ボイスエージェントが、人間が手作業で繰り返さなければならないような操作を、ただ提案するだけであってはならないからです。ポリシーが許す範囲で、エージェントはそのアクションを完了できます。繊細な変更は、引き続き権限管理され、ログに記録され、取り消し可能なままに保たれます。
AirSyncは、連携された情報を最新に保つのに役立ちます。注文の状態、チケットの状態、システムの状況がその日のうちに変化しているのに、ボイスエージェントが古い顧客レコードに頼るべきではありません。
このアーキテクチャは、よりクリーンな引き継ぎも支えます。課題が感情的であったり、法的に繊細であったり、エージェントの権限の外にあったり、安全な自動化には複雑すぎたりする場合には、人間が引き継ぐべきです。顧客は、すでに説明したことをすべて繰り返す必要はありません。
DevRev の Enterprise-Benchは、より豊かなコンテキストの価値を浮き彫りにします。このベンチマークにおいて、コンテキストを有効化したシステム(Computer)は、94.3% のタスク精度に到達しました。これは 63.6% と比較した数値です。同じフロンティアモデルが単独で動作した場合との比較であり、しかも正解あたりの使用トークンは 4.4 分の 1 でした。これらの結果は、コンテキストがどのようにエンタープライズ AI のパフォーマンスを改善しうるかを示していますが、すべてのボイス導入で同じ成果を保証するものではありません。
ポイントは、すべてのコールが同じコストになるということではありません。ボイスのコストは、通話時間、インフラ、モデルの使用、連携、そして要求されたアクションの複雑さによって左右されます。ポイントは、共有コンテキストのレイヤーが、同じビジネス理解をゼロから作り直すことをエージェントが避けるのに役立つ、ということです。
これは、ボイスエージェントが単純な要求を越えて進むときに重要になります。関わるシステムが多いほど、関連するコンテキストを効率的に取得することがますます重要になります。
これは、情報を収集してチケットを作成するためだけにボイスエージェントを使うのとは異なります。チケットの作成は役立つかもしれませんが、それは顧客の問題を解決することと同じではありません。
重要なポイント: エンドツーエンドのボイス解決には、共有コンテキスト、最新のデータ、承認済みのアクション、そしてすでに完了した作業を保持する人間への引き継ぎが必要です。
コンタクトセンターは、かけ直してこない発信者に向けて、どう最適化すべきか?
コンタクトセンターは、かけ直す必要のない顧客に向けて最適化すべきです。その一方で、共感、判断、専門的な対応を要するケースのための人間によるサポートは維持すべきです。
これは運用上の議論を変えます。エージェントが何件のコールをコンテインしたかだけを問うのではなく、リーダーは次のように問えます。
- 顧客の問題をいくつ解決したか?
- 何人の顧客が再び連絡してきたか?
- エージェントは、正しいアクションをどのくらいの頻度で完了したか?
- 顧客は、チャネルをまたいで一貫した答えを受け取ったか?
- 引き継ぎが発生したとき、人間は十分なコンテキストを受け取ったか?
- 成功した各解決には、どれだけのコストがかかったか?
- どの未解決の課題が、製品やプロセスの問題を指し示しているか?
目標は、すべての人間とのやり取りをなくすことではありません。一部のコールは、すぐに人間へ到達すべきです。繊細なクレームに対応している顧客には、共感と配慮が必要かもしれません。複雑なアカウントの問題には、判断が必要かもしれません。リスクの高い、金融、法務、または安全に関わる要求には、専門家によるレビューが必要かもしれません。
最良のボイス自動化は、単にコールを終わらせるだけではありません。それは顧客が電話をかけてきた目的を果たすのを助け、そして人間が引き継ぐべきときを見極めます。
Voice AI は、より完全な全体像を作り出します。コール、アクション、フォローアップ、そして成果を計測します。
これは CX リーダーに、自動化のアプローチを比較するためのより優れた方法を与えます。処理するコールは少なくてもより多くを解決するボイスエージェントは、繰り返しの需要を減らさないまま大量のコールをコンテインするエージェントよりも、大きな価値を生み出すかもしれません。
ボイスエージェントが自分自身には与えられない唯一の指標は、顧客がかけ直す必要があったかどうかです。
ぜひご覧ください。Voice AI がライブコールをエンドツーエンドで解決する様子、そしてVoice AI のデモを予約することで、共有メモリと Safe Actions が、御社のカスタマーエクスペリエンススタック全体で計測可能な解決をどのように支えられるかをご確認ください。
Frequently Asked Questions
DEVREV
See Computer work for you
Your AI teammate that finds answers, takes action, and gets work done across every tool.
Computer+ Apps
Our customers
Resources
Initiatives
