問い合わせが減らないとき、何を見直す？

同じ質問に何度も答えているのに、問い合わせが減らない。返信用の文章やヘルプを増やす前に、利用者がどの場面で立ち止まり、なぜ連絡する必要があったのかを見直してみます。

この記事では、繰り返し届く問い合わせから、案内・画面・対応方法の改善候補を見つける手順を紹介します。連絡先を見つけにくくして件数を下げるのではなく、利用者が必要な作業を終えられる状態を目指します。

まず、何が繰り返されているかを確かめる

「問い合わせが多い」には、異なる問題が含まれます。初めて使う人が毎回同じ場所で迷う場合と、一度質問した人が解決できずに戻ってくる場合では、見直す場所が違います。

• 別の人から同じ質問が届く：画面の説明、初回の案内、ヘルプへの入口を確認する。
• 同じ人から再び届く：回答で作業を終えられたか、別の条件が抜けていなかったかを確認する。
• 対応状況を尋ねる連絡が届く：次の案内や待ち時間の説明が足りていたかを確認する。

これは調べ始めるための見方です。この段階で原因を決めず、実際のやりとりで確かめます。同じ件名でも、管理者だけができる操作と、誰でも使える操作が混在しているかもしれません。

GOV.UKのユーザーサポートのガイドは、サポートから得た情報をサービス改善に使い、連絡の理由や対応状況も把握することを勧めています。返信を速くする取り組みとは別に、連絡が必要になった場面へ戻る時間を設けてみてください。

一つの作業を選び、問い合わせの前後を読む

最初から全件を調べる必要はありません。「請求書を取得する」「メンバーを招待する」など、繰り返し質問される作業を一つ選び、対象期間を決めます。分析用に抽出した一部の記録と、期間内の全件は区別してください。

各記録では、次の項目を確認します。問い合わせ文に書かれていないことを、担当者の想像で補わないようにします。

1. 利用者は何を終えようとしていたか。
2. その前に、どの画面や案内を見ていたか。
3. どこで止まり、何を質問したか。
4. 担当者はどの手順や条件を案内したか。
5. 回答後に作業を終えられたか、再び連絡があったか。

対応履歴が「解決済み」でも、利用者が完了を確認したとは限りません。運用上閉じただけなら、その状態を分けて記録します。結果が分からない案件は、無理に成功・失敗へ振り分けず「未確認」と残します。

件数を数えるときは、一往復のメールを一件とするのか、一つの相談を一件とするのかをそろえます。複数の窓口に届いた同じ相談も、別の問題として重ねて数えないよう、追える範囲で関連づけます。

回答を増やす前に、つまずく場所を探す

原因の候補は、ヘルプ不足だけではありません。次のように、利用者が止まった場所と改善候補を対応させて考えます。表は本記事で提案する確認用の整理です。

不具合か改善要望か迷う場合は、顧客の「使えない」を見分ける考え方も参考になります。この記事では種別の判定より、同じ連絡が生まれる流れを追います。

ヘルプを追加するなら、「説明がない」と「説明にたどり着けない」を分けてください。すでに必要な説明がある場合は、ページを増やすより、迷う画面から案内する方法を試せます。

架空例で、問い合わせから改善候補までたどる

以下は、架空の請求管理サービスを使った説明用の例です。実際の顧客事例や改善実績ではありません。

利用者から「先月の請求書をダウンロードしたい」と連絡がありました。担当者は請求書一覧へのリンクを送りましたが、その後「ボタンがありません」と再び問い合わせが届きました。

確認すると、請求書の取得は管理者だけが行える仕様でした。利用者は一般メンバーで、画面には取得ボタンも権限の説明も表示されていませんでした。この記録から、すぐに「ダウンロード機能を追加する」と決めるのは早すぎます。

• 確認できたこと：一般メンバーの画面に取得ボタンと権限の説明がない。
• 考えられる原因：利用者が、自分で取得できるか判断できない。
• 改善候補：請求書の取得に必要な権限と、管理者への依頼方法を画面に示す。
• 回答側の見直し：一覧のリンクだけでなく、権限の条件も案内する。
• 別途判断すること：一般メンバーに取得を許可する必要があるか。

権限を広げる変更と、現在の権限を分かりやすく説明する変更は、分けて検討します。説明を足した後も作業が進まないなら、権限や業務の運用自体に問題がないか調べます。

小さく試し、問い合わせが減った理由まで確認する

改善候補が出たら、確認できた根拠、影響を受ける人、担当者、試す内容、確認日を短く残します。まず一つの画面や案内を対象にすると、どこを変更したかを追いやすくなります。

架空例なら、画面の案内を変えた試作品で、一般メンバーが「誰に何を頼めばよいか」を判断できるか確かめます。操作の観察方法は、ユーザーテストの進め方で確認できます。

公開後は、問い合わせの件数だけで結論を出さないでください。利用者が減った、対象の作業が少ない時期だった、窓口を見つけにくくした、といった変化でも件数は動きます。比較する期間と対象をそろえ、可能なら対象作業の利用回数や利用者数も一緒に見ます。

同じ人からの再問い合わせ、作業が完了したか、別の窓口へ連絡が移っていないかも確認候補です。問い合わせがなくても、利用者があきらめている可能性は残ります。数字だけで分からない部分は、実際の操作や担当者の記録で補います。

振り返りで確認するチェックリスト

• 同じ人の再連絡と、別の人の同じ質問を分けたか。
• 問い合わせ前に見ていた画面や案内を確認したか。
• 回答後の完了と、運用上の「解決済み」を混同していないか。
• 観察できたことと、原因の仮説を分けたか。
• 改善を試す担当者と、結果を確認する日を決めたか。

サポート担当者だけに改善を任せず、画面やヘルプを変更できる人と一緒に確認します。すぐ直せない場合も、当面の案内と、再検討する条件を残しておけば、同じ調査を最初から繰り返さずに済みます。

よくある質問

まとめ

問い合わせから見つけた要望を受付・判断・回答へつなぐ全体の流れは、機能要望管理の基本で確認できます。

繰り返す問い合わせは、質問の種類だけでなく、連絡が必要になった場面から見直します。一つの作業の前後を追い、案内・画面・対応のどこを変えるか決めて、小さく確かめてください。

少量なら、問い合わせ記録と改善メモを結びつけるところから始められます。記録が増え、似た困りごとを毎回探し直しているなら、集まった要望を整理する方法も見直す余地があります。

アーコレ！は、集めた要望を整理し、改善の検討につなげるためのサービスです。問い合わせの原因や対応方針はチームで確かめながら、判断材料をどうまとめるかを検討できます。

アーコレでどう整理できるかを見る