コールセンターの自己解決率を測る ー FAQ閲覧後の未解決を見落とさない設計
CX TodayによるGartner調査の報道によると、2024年8月に公表されたGartnerの顧客5,728人調査では、顧客の73%がサービス利用の過程のどこかでセルフサービスを使う一方、セルフサービスだけで完全に解決した問い合わせは14%にとどまった。顧客自身が「とても簡単」と答えた問題でも、完全解決は36%だという。それなのに社内の報告書では、FAQのページビューが伸びたことをもって「自己解決が進んだ」と書かれることが少なくない。FAQを見た人のうち、何人が本当に解決し、何人が黙って電話をかけ直したのか。本稿の立場は、自己解決率は計算式より先に「観測できる範囲」を設計しないと数字にならない、というものである。以下は編集部の実務設計案であり、特定製品の推奨ではない。
1. 閲覧・回答評価・手続き完了を分ける
まず当て馬として、よく使われる比率を置く。Zendeskのセルフサービス指標の解説は、セルフサービススコアを「ヘルプセンターの総ユーザーセッション数 ÷ チケットを起票した総ユーザー数」と定義し、比率が大きくなるほど改善と読む。分かりやすい指標だが、これは「試みた人」と「問い合わせた人」の比であって、FAQを見た人が解決したかどうかは含まれない。閲覧が倍になれば、解決が増えていなくてもスコアは上がる。もっとも、同じ解説はチケット起票につながった検索や記事の評価票も合わせて見るよう促しており、比率単体で判断せよとは言っていない点には留保が要る。
そこで、FAQ閲覧後の行動を少なくとも3つの層に分けて記録することを提案する。
閲覧: FAQ記事が開かれた。解決の可能性があるだけの状態
回答評価: 「役に立った／立たなかった」の評価票が押された。本人の主観的な判定
手続き完了: FAQから誘導した画面で住所変更や解約受付などの手続きが完了した。業務システム側で確認できる客観的な結果
たとえるなら、閲覧は「来店」、回答評価は「店を出るときの一言」、手続き完了は「レジを通った記録」である。来店数を売上と呼ぶ店はない。3層を別々に集計するだけで、「閲覧は多いが評価票は押されない」「評価は高いが手続きは完了しない」といったズレが見えるようになる。自己解決の上限そのものの議論は8月30日の記事で扱ったので、本稿は測り方に絞る。
2. 追跡可能な再問い合わせをつなぐ
3層を分けても、最も重要な「FAQを見た後に有人窓口へ来たか」は、FAQ側のログだけでは分からない。コンタクトセンター基盤側の記録とつなぐ必要がある。
公開仕様の一例として、AWSのコンタクトセンター基盤（2026年4月にAmazon ConnectからAmazon Connect Customerへの改称が報じられた）を見る。コンタクトイベントの仕様によれば、音声・チャット・タスク・メールのコンタクトについて、INITIATED（開始）、QUEUED（キュー投入）、CONNECTED_TO_AGENT（オペレーター接続）、DISCONNECTED（切断）などのイベントがAmazon EventBridge経由でほぼリアルタイムに配信される。各イベントには、APIで開始されたかどうかを示すInitiationMethodや、関連するコンタクトを示すRelatedContactIdといった項目が含まれる。
さらにチャット開始API（StartChatContact）は、任意のキーと値を「Attributes」としてコンタクトに持たせられる。FAQ画面からチャットへ移る導線であれば、直前に閲覧していた記事IDやFAQ側のセッションIDを属性として渡しておけば、「どの記事を読んだ後に有人へ来たか」を後から突合できる。宅配便の追跡番号を、受付票に書き写しておくようなものだ。これは編集部の設計例であり、実装条件は各社の環境で確認されたい。
注意点も仕様に書かれている。同じページは、イベントは順序付けされず（タイムスタンプで並べ替えて使う）、ベストエフォートで配信されると明記している。取りこぼしがありうる前提で、日次で業務システム側の記録と件数を照合する仕組みを別に持つのが安全だ。また、突合の時間窓（閲覧から何時間以内の問い合わせを「FAQ後の再問い合わせ」とみなすか）は用件ごとに決める必要がある。請求の確認なら当日中、手続きの不明点なら数日後に電話が来ることもある。窓を短く取れば未解決は少なく見え、長く取れば無関係な問い合わせが混ざる。窓の長さ自体を集計表に明記しておくことが、数字の信頼性を担保する。
3. 結果不明の利用を独立表示する
どれほど丁寧につないでも、追跡できない利用は必ず残る。ログインせずに閲覧した匿名の利用者、スマートフォンでFAQを見てからパソコンで問い合わせた人、Webで調べた後に電話をかけた人は、FAQ側のセッションと有人側のコンタクトを結ぶ手がかりがないことが多い。
ここでやってはいけないのが、追跡できなかった利用を「再問い合わせなし＝解決」に数えることだ。問い合わせが観測されなかったことは、問い合わせが無かったことを意味しない。
参考になるのは、ボット側の成果分類である。同じAWSのボット指標の定義では、会話の結果をSUCCESS（最終意図が成功）、FAILED（失敗、またはフォールバックに落ちた）、DROPPED（成功か失敗かが決まる前に顧客が応答しなくなった）の3つに分けている。途中で黙って去った会話を、成功にも失敗にも寄せず、独立したバケツに入れているわけだ。FAQ計測も同じ考え方で、集計表を「解決確認あり」「未解決（再問い合わせを確認）」「結果不明」の3列にし、結果不明を分母から消さずに並べて表示する。自己解決率を1つの数字で出すなら、結果不明をすべて未解決とみなした下限値と、すべて解決とみなした上限値を併記すると、読み手が過大評価に気づける。
4. 導入前後で観測範囲を揃える
ここからは私の見立てとして書く。FAQやチャットボットの刷新効果を報告する場面で、最も起きやすい誤りは「導入後だけ観測範囲が広がる」ことだと考えている。新しいツールを入れると、評価票やイベント連携も同時に整うため、導入前には見えていなかった未解決が導入後に初めて数えられる。逆に、新ツール側だけ閲覧数を解決数として数えれば、効果は実態より大きく見える。どちらの場合も、比べているのは効果ではなく観測範囲の差である。
対策は単純で、比較する2期間で「どの層を」「どの時間窓で」「どのチャネルまで」追跡したかを揃えることだ。導入前の記録が閲覧数しかないなら、導入後も閲覧数同士で比べ、3層の数字は導入後の新しい基準線として別に持つ。前述のボット指標の定義にも、各指標のデータは2024年12月2日以降のものに限られると注記されており、それより前の期間とは同じ指標で比べられない。どの基盤でも、指標ごとに「いつから取れているか」を台帳にしておくべきだろう。
自己反証もしておく。追跡の設計に手間をかけすぎると、改善より計測の整備が目的化するおそれがある。問い合わせ件数の少ないセンターでは、3層の分解や突合の仕組みを作るより、オペレーターが応対の冒頭で「FAQはご覧になりましたか」と聞き、応対記録に残すほうが安く、十分に役立つ場合もある。完全な追跡は目標ではなく、どこまで見えていないかを数字の横に書けることが目標だ、と言い換えたほうが正確かもしれない。
FAQ製品の方式の違い（検索型・生成型など）についてはFAQ・チャットボットのサービス一覧で整理している。計測の設計は、どの方式を選んでも必要になる土台である。
FAQとチャットボットの先を考えるなら
計測の先にある「FAQやチャットボットがこれからどう変わるか」については、TENTIALのカスタマーサポート部長・谷合北斗氏に、CS業務のAI化の全貌と5年後のCSの姿を聞いた取材記事を無料会員向けに公開しています。本稿の計測手順は編集部の設計案であり、取材内容とは独立しています。
【あらゆるCS業務をAI化】リカバリーウェア「BAKUNE」のカスタマーサポートAXの全貌／5年後のCSは「二極化」する（会員限定）
まとめ
第一に、FAQの閲覧数や閲覧と問い合わせの比率は、自己解決の「試み」を測る数字であって解決の数字ではない。閲覧・回答評価・手続き完了の3層に分けて記録することが出発点になる。第二に、FAQ後の再問い合わせは、FAQ側のIDをコンタクトの属性として渡すなどの設計でつなげられるが、配信の取りこぼしや時間窓の決め方という限界を数字と一緒に示す必要がある。第三に、追跡できない利用は「結果不明」として独立表示し、導入前後で観測範囲を揃えて比べる。あなたのセンターが報告している自己解決率は、顧客が解決した割合なのか。それとも、観測できなかった割合を解決と呼んでいるだけなのか。
注記: 本記事の数値・仕様は2026年9月時点でWeb上の公開情報を確認したものです。製品仕様は変更されることがあるため、実装前に各社の最新ドキュメントを確認してください。計測の手順・判断例は編集部の実務設計案であり、取材対象者の発言ではありません。見解にわたる部分は筆者個人の分析であり、特定ベンダー・製品の推奨ではありません。
出典
Zendesk「Getting started with self-service - Part 6: Tracking essential self-service metrics」
Gartner「Gartner Survey Finds Only 14% of Customer Service Issues Are Fully Resolved in Self-Service」
CX Today「Only 1 in 7 Customer Service Queries Resolved with Self-Service, Gartner Study Finds」
この記事はCC AI LabのAI著者（相馬 迅/相原 ことは）が執筆し、編集部が内容を確認・承認のうえ公開しています。誤りを見つけた場合はお問い合わせフォームからご連絡ください。
この記事について相原さんに聞く数字の読み方や、他の事例との違いを、Labの記事を根拠にお答えします。
