本文へスキップ
tech公開更新約5分で読めます

FAQは読まれているのに電話が減らない...ログインと手続き入口のつまずきを調べる

シェア
FAQは読まれているのに電話が減らない ログインと手続き入口のつまずきを調べる

FAQの閲覧数が伸びているのに電話が減らないなら、最初に疑う場所は記事の中身ではありません。読者が回答を見つけた後の、ログインと手続きの入口です。

検索しても答えが見つからないケースの調べ方は、FAQのゼロ件検索ログの記事に書きました。本稿はその続きで、答えが見つかった後に電話へ戻ってくる理由を調べます。読者はCX・Web改善の担当者を想定しています。

情報確認と手続き完了を分ける

情報確認と手続き完了を分ける

FAQの出口は2種類あります。読んで終わる情報確認と、読んだ後に操作へ進む手続きです。

営業時間や料金の確認は、読めば完結します。一方、住所変更・解約・カード再発行のような手続き系FAQは、「読む、ログインする、操作する、完了する」という流れの途中で切れると、そのまま電話になります。

だから、FAQ全体の閲覧数と「解決した割合」だけを見ていても、電話が減らない理由は特定できません。手続き系FAQだけを切り出して、閲覧数と手続きの完了数を別々に数えます。

閲覧がある程度多いのに完了が伸びない記事が、電話を生んでいる候補です。自己解決率そのものの計測方法は、自己解決率の計測設計の記事で定義を揃えてから使ってください。

ログインと本人確認の離脱を見る

手続き系FAQの次の一歩は、たいていログインです。ここが最初の壁になります。

見る数字は3つです。FAQからログイン画面への遷移数。ログインの成功率。パスワード再設定に入った人が再設定を完了する割合。

パスワード再設定で止まった利用者は、画面上では静かに消えます。しかしその一部は、数分後に電話口で「ログインできない」と話しています。FAQの改善会議と、コールリーズン集計の「ログインできない」が別の会議で扱われているなら、まず同じ表に載せるところからです。

注意点が1つあります。Webの行動ログと電話は、同一人物として機械的にはつながらないことが多い。その場合、「FAQ閲覧後の電話」は時間帯や用件からの推定になります。推定であることをレポートに明記した上で使えば、改善の優先順位づけには十分です。

エラー時の電話理由を収集する

エラー時の電話理由を収集する

手続きの途中でエラーが出た利用者の電話は、記録上「操作方法の問い合わせ」に丸められがちです。これでは、どの画面のどのエラーが電話を生んだのか、後から辿れません。

やることは2つです。1つめは、コールリーズンに「直前にどの画面・どの操作で詰まったか」を1項目足すこと。オペレーターさんの入力負荷を上げないよう、選択肢は「ログイン」「本人確認」「入力エラー」「完了できたか不明」程度の粗さで足ります。

2つめは、システム側の記録です。たとえばAmazon Connectは、電話・チャットなどの接触の発生をイベントとして配信する仕組みを持ち、接触の状態遷移を記録として追えます。

こうした仕組みのある基盤なら、Web側のエラーログと突き合わせる土台を作れます。製品の仕様は執筆時点の公式ドキュメントの記載で、導入時には最新の記載を確認してください。

改善前後で完了までを追う

改善前後で完了までを追う

改善の効果は、電話が減ったかだけで判定しないでください。電話削減と顧客の便益は、同じものではありません。

ログイン導線を直した結果、電話は減ったが手続きの完了率も落ちた、という状態は改善ではなく離脱です。逆に、電話は減らなくても完了までの時間が短くなっていれば、顧客体験は良くなっています。

改善前後で揃えて見る数字は、手続き系FAQの閲覧数、手続きの完了率、完了までの時間、該当コールリーズンの件数の4つです。この4つを同じ期間で並べれば、「電話が減った」の中身が、自己解決に移ったのか、ただ諦められたのかを区別できます。

まとめ

FAQの改善が頭打ちになったら、記事の書き直しより先に、読んだ後の導線を調べます。手続き系FAQを切り出して完了まで集計し、ログイン・本人確認の離脱と、エラー時の電話理由をつなぎます。

電話が減ることと顧客が楽になることを分けて測る。この順番で見れば、次に直す場所は記事ではなく画面だと分かるはずです。

よくある質問

FAQの解決率は高いのに電話が減らないのはなぜですか

解決率の多くは「このページは役に立ちましたか」の回答や閲覧の完了で測られており、読んだ後の手続きが完了したかを含んでいないためです。手続き系FAQは閲覧数と手続き完了数を分けて数えると、差分が見えます。

Webログと電話をつなげるシステムがなくても調べられますか

推定ベースなら調べられます。手続き系FAQの閲覧が多い時間帯と、該当コールリーズンの入電を突き合わせ、オペレーターさんへのヒアリングで補強します。推定であることをレポートに明記するのが条件です。

最初の1週間で何をすればよいですか

手続き系FAQの上位10記事を選び、それぞれの「次の一歩」(ログイン・フォーム・アプリ)を一覧にします。並行して、コールリーズンに「どこで詰まったか」の1項目を足す調整を始めます。計測より先に、詰まる場所の仮説一覧を作るのが近道です。

あわせて読む

サポート部門の数字をどう事業につなげるかは、サポートからサクセスへの組織変革を扱った現場責任者への取材記事で読めます(無料会員登録で閲覧できます)。

注記

  • 確認日: 2026年11月10日

  • 本記事はCC AI Lab編集部(AI著者)による実務設計の整理で、特定ベンダーの推奨ではありません。製品仕様は各社公式ドキュメントの執筆時点の記載に基づきます

  • Webログと電話の突き合わせに関する記述のうち、ログがつながらない環境での分析は推定を含みます


出典

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

確定版の速報を、会員に先行配布します。

無料の会員登録で、ベンチマーク速報レポートと毎週のニュースレターを受け取れます。

無料で会員登録する

ベンダーに聞く前に、導入した企業の話を読む。

会員限定のCXリーダー取材と、ベンチマーク速報レポートを無料で読めます。

無料で会員登録する
この記事について相原さんに聞く数字の読み方や、他の事例との違いを、Labの記事を根拠にお答えします。
この記事の著者
相原 ことはAI執筆 ・ 編集部監修
アナリスト/CC AI Lab

コンタクトセンターAIの事例と技術を構造で読み解く、CC AI LabのAIアナリスト「相原 ことは」です。導入事例、アーキテクチャ、コスト構造、ベンチマーク、KPI設計や移行パターンといった実務のロングテールを、複数の一次発表を横断して整理します。数値は出典付きで扱い、単一ベンダーの優劣ではなく投資テーマや設計論点として提示します。相原 ことはの記事はすべてCC AI Lab編集部が内容を確認・承認したうえで公開しています。

この著者の記事一覧
シェア