問い合わせ管理システムでは、ステータスとタグをどう分けるかで、日々の使いやすさと後からの分析しやすさが変わります。 どちらも問い合わせを分類するための項目ですが、役割は同じではありません。
ステータスは「今どの段階にあるか」を示すものです。 一方、タグは「何についての問い合わせか」「どんな原因や背景があるか」を残すためのものです。 この2つを混ぜてしまうと、一覧画面もレポートも分かりにくくなります。
この記事では、問い合わせ種別・確認できた原因・改善テーマを、別の分類として記録する方法を扱います。業務ごとのステータス構成や変更条件は、問い合わせステータス設計の実例とパターンを参照してください。
「未対応」かつ受付種別が「不具合」の問い合わせを表示する例です。画面内の案件・件数は説明用の架空データで、実際には操作できません。上部は絞り込み前の集計、一覧は条件に一致する2件を示します。下部の原因確認が未実施の5件は、絞り込み条件とは別に集計しています。期限超過は進捗とは別の条件なので、未対応・対応中の件数と重なり得ます。
まず、ステータスとタグの役割を分けておきます。 この前提が曖昧なまま項目を作ると、ステータス名の中に問い合わせ種別や原因が混ざり、後から集計しにくくなります。
| 項目 | 役割 | 例 |
|---|---|---|
| ステータス | 問い合わせの進捗や状態を表す | 未対応、対応中、回答待ち、完了 |
| タグ | 問い合わせの内容、原因、改善テーマを表す | 不具合、仕様確認、請求関連、UI改善 |
ステータスは、着手・追加情報の依頼・回答・対応終了などの出来事に応じて更新します。タグは複数の分類を記録できる項目で、受付時に付けるものもあれば、調査後に追加・訂正するものもあります。時間が経過したことだけで、担当者が確認した状態へ変更しない設計にします。
この例では、主となる進捗は1件につき1つ、タグは分類ごとに複数付けられる構成を想定します。同時に複数部署が作業する場合は、部署別の作業状況を別に持つ方法もあります。「対応中」「不具合」「請求関連」を同じ選択欄へ入れる前に、その項目が何を表すのかを決めます。
ステータスは、問い合わせの進捗を把握するための最小限の区切りとして設計します。 BtoBの問い合わせ管理であれば、最初は次の程度に抑えると扱いやすくなります。
中間ステータスを細かく増やすこともできますが、最初から増やしすぎると、担当者がどれを選ぶべきか迷います。 まずは大きな流れを押さえ、実際の運用で不足が出た場合だけ追加する方が安全です。
タグは、問い合わせの内容や原因を残すための項目です。 後からレポートや改善施策に使うため、ステータスよりも分析寄りの役割を持ちます。
受付時タグは、「どんな問い合わせが来ているか」を見るためのものです。ここでの「不具合・障害報告」は利用者からの申告内容であり、不具合が確認済みという意味ではありません。受付チャネルや対象製品を集計する場合は、それぞれ別の項目として記録します。
原因タグには、調査や利用者への確認で根拠が得られた内容を記録します。「画面表示が分かりにくい」という原因と、「UI改善を検討する」という次の施策は別です。改善テーマは別の分類にし、原因を特定できなかった案件に、推測した原因を必須入力させないようにします。
ステータスとタグは、別々に作るだけではなく、運用ルールとして組み合わせて使うことが重要です。
このように分けると、「何が来ているか」と「なぜ発生したか」を別々に見られます。 前者は日々の対応量の把握に、後者はサービス改善やFAQ整備に使いやすくなります。
原因タグが空欄でも、調査していない場合と、調査したが特定できない場合があります。両方を「タグ未設定」でまとめると、必要な確認が残っている案件を判別できません。例えば、原因確認の状態を次のように記録します。
利用者への回答を終えた後も原因調査を続ける運用なら、問い合わせ対応と原因調査の完了条件を分けます。原因が不明でも対応を終了できるか、誰が判断するか、調査を引き継ぐかは運用側が決める事項です。架空の原因を選ばないと保存・完了できない構成は避けます。
タグは便利ですが、自由に増やせる状態にすると、似た意味のタグが乱立しやすくなります。 例えば、同じ受付内容を指す「見積依頼」と「お見積り依頼」が別々に作られる場合です。一方、「入力誤り」と「設定誤り」は原因が異なることがあるため、表現が似ているだけで統合しません。
タグを別の意味へ転用すると、以前の記録まで新しい意味で読まれてしまいます。意味が変わる場合は、新しい分類として登録し、必要なら既存案件を確認して移行します。判断できない記録を、新しい分類へ自動的に置き換えないようにします。
コンサルティング会社や専門サービス業では、問い合わせの内容が幅広くなります。 そのため、ステータスはシンプルに保ち、タグでテーマ・業種・顧客属性を残す構成が向いています。
「既存顧客からの紹介で、セミナーにも参加した人」のように、取引関係・相談の経路・参加履歴は同時に成り立ちます。一つの択一項目にまとめず、別々に記録します。新規・既存は問い合わせ時点の関係を残すか、現在の顧客情報を表示するかを決め、集計にも明示します。
問い合わせ・資料請求・セミナー申込などをまとめて管理する考え方は、 コンサル向けWebシステム活用アイデアのような業種別ページとも相性があります。 単独の問い合わせ管理ではなく、周辺業務まで含めて設計する場合の参考になります。
ステータスとタグは、一覧画面とレポート画面で使われて初めて意味が出ます。 登録するだけでなく、どこで見るかも先に決めておきます。
この分け方にすると、日々の対応ではステータスを見て動き、改善会議ではタグを見て傾向を確認する、という使い分けができます。
説明用に、問い合わせ10件のうち「見積」が6件、「仕様確認」が5件、両方付いている案件が2件とします。タグ別件数の合計は11件ですが、どちらかのタグが付く問い合わせは9件です。タグの合計を問い合わせの総数として表示してはいけません。
レポートには、対象期間が受付日基準か完了日基準か、集計対象に重複・対象外の案件を含むか、何件を分母にするかを明記します。原因別の分析では、未実施・調査中・特定できずも別に数え、原因が分かった案件だけの比率を全体の傾向と混同しないようにします。
問い合わせ管理におけるステータス・タグ設計では、進捗を表すステータスと、内容・原因を表すタグを分けることが出発点です。 ステータスはシンプルに保ち、タグ側で問い合わせ種別・原因・改善テーマを残すと、現場の負担を増やしすぎずに分析しやすいデータが蓄積できます。
受付時タグ、対応後タグ、原因タグの役割を分け、タグマスタを定期的に見直す。 そのうえで、ダッシュボードやレポート画面と合わせて設計すると、問い合わせ管理は日々の処理だけでなく、改善の材料としても使いやすくなります。