問い合わせ管理システムでは、「ステータス」と「タグ（ラベル）」をどう設計するかが、 運用のしやすさと分析のしやすさを大きく左右します。 どちらも “問い合わせを分類する” 機能を持ちますが、役割が異なるため、 やみくもに項目を増やすと、現場が混乱して使われなくなってしまいます。
本記事では、BtoB の問い合わせ管理を前提に、 ステータスとタグの役割分担と、実務でよく採用される設計パターンを整理します。
まずは、ステータスとタグの役割を明確に分けて考えることが重要です。
ステータスは時間の経過とともに変化していきますが、タグは基本的に不変、または追加されていく情報です。 この違いを意識せずに設計すると、ステータスに “内容分類” を混ぜてしまい、 運用が複雑化します。
ステータスは、問い合わせの進捗を把握するための「最小限の区切り」を作るイメージで設計します。 よく使われる基本パターンは次のとおりです。
ここに、個別プロジェクト向けの中間ステータスを追加するケースもありますが、 最初から細かくしすぎると、担当者が「どれを選べば良いかわからない」状況に陥ります。 まずはこのレベルから始め、運用上どうしても必要な場合のみ段階的に増やしていくのが安全です。
タグは、問い合わせの「何について」「どのような理由で」発生したかを表します。 分析・改善の軸になるため、ステータスとは別に、ある程度の粒度で整理しておくと有効です。
タグは「問い合わせを後から見返したときに、改善アクションを検討しやすい粒度」にするのがポイントです。 同じ内容でも、「どの観点で改善したいか」によってタグ設計が変わってきます。
ステータスとタグの役割が明確になったら、実際の運用フローの中でどのように組み合わせるかを設計します。
このように分けることで、「何が来ているか」と「なぜ発生したか」を別々に分析できるようになります。 前者はチャネル別・商品別の問い合わせ傾向分析に、後者はサービス・プロダクト改善の優先度付けに役立ちます。
例えば、不具合・障害に関する問い合わせでは、完了前に必ず「原因タグ」を付ける、 契約・請求関連の問い合わせでは、「どのプラン・契約種別に関するものか」をタグで残す、といったルールを決めておくと、 レポートの精度が安定します。
タグ運用が破綻する典型例は、「運用の中でなんとなく増やし続けた結果、誰も使いこなせなくなる」ケースです。 これを防ぐためには、次のような工夫が有効です。
インテンスでも、タグマスタの編集を限定された管理者だけが行えるようにしつつ、 現場からの要望を踏まえて定期的に棚卸しする運用を採用することが多くなっています。
コンサルティング会社や専門サービス業では、問い合わせの内容が多岐にわたり、 「どのテーマの相談が増えているか」「どの業種・規模の企業からの相談が多いか」を把握することが重要になります。 この場合、ステータスは比較的シンプルに保ちつつ、タグでテーマ・業種・顧客属性を整理することで、 営業活動やコンテンツ企画に直結するデータが得られます。
こうした「問い合わせ・資料請求・セミナー申込」などをまとめて管理し、 どのような業務をシステム化できるかのイメージを掴むための参考として、 コンサル向けWebシステム活用アイデア のような業種別活用例ページを活用するケースもあります。 問い合わせ管理と周辺業務をどこまで一体で設計するか検討する際のヒントになります。
問い合わせ管理におけるステータス・タグ設計では、 「進捗を表すステータス」と「内容・原因を表すタグ」の役割分担を明確にすることが出発点です。 ステータスはシンプルに保ち、タグ側で分析や改善に必要な軸を整理することで、 現場の運用負荷を増やさずに、後から活用できるデータを蓄積していくことができます。
自社の業種・サービス特性に合わせて、受付時タグ・対応後タグ・原因タグなどの階層を検討し、 問い合わせ管理ダッシュボードやレポート画面と合わせて設計していくことが重要です。