問い合わせ管理システムを使い始めると、次に必要になるのが集計レポートです。 ただし、問い合わせ件数のグラフを増やすだけでは、現場改善にはつながりません。 大事なのは、何を判断するためのレポートなのかを先に決めることです。
たとえば、Webフォームからの問い合わせが増えたとしても、それが営業にとって良い問い合わせなのか、サポート負荷が増えているだけなのかは、件数だけでは分かりません。 カテゴリ、チャネル、ステータス、担当者、対応時間、案件化率などを組み合わせて見ることで、ようやく次の判断につながります。
最初に決めるべきなのは、グラフの種類ではなく、レポートを見る目的です。 目的が曖昧なまま作ると、見た目は整っていても、会議で眺めるだけの資料になってしまいます。
目的によって、必要な軸は変わります。 問い合わせ管理の設計時点で、将来どのようなレポートを出したいかを軽く決めておくと、必要なデータを取りこぼしにくくなります。
画面例 問い合わせ集計レポートの基本画面
件数だけでなく、未対応・初回返信・商談化まで並べると、運用と営業の両方で使いやすいレポートになります。
問い合わせを集計するときは、いくつかの基本軸があります。 最初から全部を細かく見る必要はありませんが、次の軸は多くの業種で使います。
| 集計軸 | 例 | 確認できること | 設計時の注意点 |
|---|---|---|---|
| 時間軸 | 日次、週次、月次、四半期 | 問い合わせの増減、繁忙期、施策後の変化。 | 作成日時だけでなく、完了日時・初回返信日時も残す。 |
| チャネル | Webフォーム、電話、メール、展示会、代理店 | どの入口から問い合わせが来ているか。 | 手入力だと揺れやすいため、選択式や自動付与にする。 |
| カテゴリ | 製品別、サービス別、問い合わせ種別 | 関心が高いテーマ、FAQ化すべき内容。 | 問い合わせ分類（カテゴリ）を最適化する方法 と連動させる。 |
| ステータス | 未対応、対応中、追加確認待ち、完了、キャンセル | どこで対応が止まっているか。 | 変更履歴を残さないと、滞留時間を計算できない。 |
| 担当者・部署 | 営業部、サポート部、担当者A、担当者B | 対応負荷、偏り、担当変更の傾向。 | 現在の担当だけでなく、担当変更履歴も残す。 |
| 成果 | 商談化、見積化、受注、FAQ解決 | 問い合わせが次の行動につながったか。 | 営業管理やCRMと連携できる範囲を決める。 |
これらの軸は、問い合わせステータス設計の実例とパターン や 問い合わせ分類（カテゴリ）を最適化する方法 で決めた内容と直結します。 フォームや管理画面の設計時点で分類が曖昧だと、後からレポートを作っても精度が出ません。
問い合わせレポートは、最初から複雑にする必要はありません。 まずは、運用改善と営業判断の両方に使いやすいレポートを数種類に絞る方が、現場に定着しやすくなります。
問い合わせ全体の増減を確認する基本レポートです。施策の前後比較にも使えます。
どの入口が問い合わせにつながっているか、どの入口の質が高いかを確認できます。
問い合わせが多いテーマを見れば、WebサイトやFAQの改善対象を決めやすくなります。
日々の運用で見落としやすい対応遅れを確認するためのレポートです。
BtoB営業に関係する問い合わせでは、単なる件数よりも、商談や見積につながったかどうかが重要です。 問い合わせが多くても、商談化しないものばかりであれば、フォーム項目や流入導線を見直す必要があります。
提案型ビジネスでは、単発の問い合わせ数よりも、どの入口から来た問い合わせが次の商談につながっているかを見る方が有用です。 コンサル向けWebシステム活用アイデア のような業種では、問い合わせ管理と案件管理を連動させると、レポートの価値が上がります。
日々の運用で見るダッシュボードと、月次・四半期で振り返るレポートは、役割が違います。 ここを分けずに一画面へ詰め込むと、現場にも管理者にも使いにくい画面になります。
| 種類 | 主な利用者 | 見るタイミング | 主な内容 |
|---|---|---|---|
| 運用ダッシュボード | 担当者、チームリーダー | 毎日 | 未対応、期限超過、今日対応すべき問い合わせ、担当別の件数。 |
| 集計レポート | 管理者、営業企画、マーケティング、経営層 | 週次・月次・四半期 | 件数推移、チャネル別、カテゴリ別、商談化率、対応時間の傾向。 |
| 改善用レポート | Web担当、CS、サポート責任者 | 施策検討時 | FAQ候補、フォーム改善候補、問い合わせの多いページやカテゴリ。 |
問い合わせ管理のための保存ビュー・フィルタ設計ガイド で扱うビューは、主に日々の運用向けです。 このページで扱うレポートは、1か月〜数か月単位で振り返り、ルールや施策を見直すための資料に近い位置づけです。
レポートを作る段階になってから、「必要な情報が記録されていなかった」と気づくことがあります。 特に、ステータス変更日時、担当変更履歴、チャネル、カテゴリ、キャンペーン情報は、後から追加しても過去データには反映できません。
インテンスでも、将来レポートで使う可能性が高い軸は、まず項目として持たせる設計を検討します。 画面に最初から全部出す必要はありませんが、データとして残っていれば、後から集計画面を追加できます。
問い合わせ集計レポートは、画面を先に作るより、データの定義を決めてから進める方が安全です。 実務では、次のような順番で設計すると無理がありません。
手順 問い合わせレポート設計の流れ
件数確認、滞留改善、営業分析など、判断したい内容を決める。
時間、チャネル、カテゴリ、担当者、ステータスなどを選ぶ。
必要な日時や履歴が記録されているか確認する。
カード、グラフ、一覧、CSV出力の形を決める。
月次会議や改善ミーティングで見るレポートとして運用する。
問い合わせ集計レポートは、グラフを増やすことが目的ではありません。 問い合わせ件数、チャネル、カテゴリ、ステータス、担当者、対応時間、商談化などを組み合わせ、次の判断に使える形にすることが重要です。
まずは、今ある問い合わせデータを見て、どの軸で記録されているか確認してみてください。 チャネルやカテゴリが曖昧であれば、フォームや管理画面の項目設計から見直す必要があります。 反対に、作成日時・初回返信日時・完了日時・担当履歴が残っているなら、対応スピードや滞留状況のレポートから始められます。
問い合わせ管理システムを単なる受付台帳で終わらせず、Web改善、営業改善、サポート改善の材料として使うために、レポート設計は早い段階で考えておく価値があります。