問い合わせフォームにカテゴリを用意しているのに、「その他」が多い。担当者が内容を読み直して、別の部署へ送り直している。そんな場合は、選択肢を増やす前に、利用者の用件と社内の分類基準が一致しているかを確認します。
たとえば「製品について」と「導入前相談」が並んでいると、購入前に仕様を確認したい人はどちらも選べます。一方、社内では製品別の件数と購入検討段階の両方を集計したいかもしれません。この場合、製品名と相談目的を別の項目として管理する方法があります。
この記事では、実際の問い合わせを使った分類の見直しから、カテゴリ名・業種別の項目例、段階的な選択肢、担当振り分け、FAQ連携、過去データを残す運用まで解説します。利用者が選ぶ用件と、社内で追加する分類・タグの役割を分けて考えます。
カテゴリを考え直すとき、最初から理想の分類表を作ろうとすると、社内都合の案になりやすくなります。 先に見るべきなのは、実際の問い合わせデータです。
この段階で、すでに多くの問題が見えてきます。 たとえば、「製品について」と「サービスについて」の違いが曖昧で、担当者によって選び方が変わっている。 「契約について」と「料金について」が分かれているものの、実際には同じ部署が対応している。 「その他」が多すぎて、レポート上は何が起きているか分からない。 こうした状態を先に把握しておくと、カテゴリの統合・分割を判断しやすくなります。
管理画面 カテゴリ利用状況の棚卸しイメージ
| カテゴリ | 件数 | 主な内容 | 状態 | 見直し案 |
|---|---|---|---|---|
| 料金・見積 | 92 | 費用感、見積依頼、プラン確認 | 継続 | 名称はそのまま。自動返信文を見直す。 |
| サービスについて | 76 | 内容が幅広く、担当部署が分かれる | 要分割 | 導入相談／機能確認／資料請求へ分ける。 |
| その他 | 133 | 採用、取材、既存顧客、営業メールが混在 | 要整理 | その他を最後に残し、選択前の案内文を追加。 |
「その他」が多い場合は、カテゴリ名が分かりにくい、選択肢が足りない、または社内向けの分類をユーザーに見せている可能性があります。
問い合わせ分類で混乱しやすい理由は、ユーザー向けの分類と社内向けの分類を同じものとして扱ってしまうことです。
ユーザーは「自分が何をしたいか」で選びます。 一方、社内では「どの部署が対応するか」「どのSLAで扱うか」「どのレポートに入れるか」で分類したくなります。 この2つを無理に1つのプルダウンに押し込むと、どちらにも使いにくいカテゴリになります。
設計例 表示カテゴリと内部ルーティングを分ける
フォーム上はユーザーが選びやすい言葉にし、裏側で担当部署や通知先へ変換すると運用しやすくなります。
カテゴリ名が社内部署名や専門用語になっていると、ユーザーは選びにくくなります。 たとえば「営業一課」「技術推進部」「CS企画」などは、社内では意味があっても、外部のユーザーには判断材料になりません。
カテゴリ名は、ユーザーの目的や状況が分かる表現にします。
Before / After カテゴリ名の見直し例
カテゴリ名は短くても構いませんが、ユーザーが「自分の用件はこれだ」と判断できる表現にすることが重要です。
また、「その他」は完全になくす必要はありません。 ただし、「その他」が多く選ばれる状態は問題です。 選択肢を見ても当てはまるものがない、または似た選択肢が多くて判断できない可能性があります。
「何について」「何をしたい」「誰から」のどれを尋ねているかを分けると、選択肢の重複を確認できます。たとえば「製品A」「見積依頼」「既存のお客様」を同じ欄に並べると、製品Aの追加購入を相談する既存顧客は、三つとも該当します。
以下は設計例です。名称をそのまま採用する前に、実際の受付担当と、回答に必要な情報を確認してください。
カテゴリ数だけで良し悪しを判断せず、実際に届いた問い合わせを分類案に当てはめてみます。「複数の候補に該当する」「どれにも該当しない」「利用者には判断できない」用件を記録すると、名称を変えるのか、選択肢を分けるのか、社内項目にするのかを検討できます。
以下は、複数の窓口を一つのフォームで受け付ける場合の候補です。必要な項目数を示すものではありません。採用フォームが独立している、資料請求が自動で完結するなど、別の受付経路がある場合は重複して設ける必要があるか確認します。
細かい分類が必要でも、すべてを最初の選択欄に並べる必要はありません。ただし、分類を階層化すれば必ず分かりやすくなるわけでもありません。追加で尋ねる情報が、受付先や回答内容の判断に必要かを確認します。
たとえば「利用中の不具合」を選んだときだけ対象製品を尋ね、社内で調査した後に「認証」「データ登録」「帳票出力」などの原因・機能タグを付ける方法があります。利用者が原因を特定できない段階で、小分類まで必須にすると推測の回答が混ざります。
ユーザーに見せるカテゴリを分かりやすくすると、社内側では「担当部署」「優先度」「レポート区分」などが足りないことがあります。 その場合は、フォームの見た目に出すのではなく、内部項目として持たせます。
選択されたカテゴリに応じて、通知先や担当グループを自動設定します。
障害、契約、見積など、対応順に影響するものは内部フラグとして管理します。
FAQ改善やレポートに使うため、問い合わせ内容に応じてタグを追加します。
このように、ユーザーが選ぶカテゴリと、社内で使う分類を分けることで、フォームを複雑にせずに運用の精度を上げられます。
担当者がカテゴリを修正する場合、利用者の選択値を上書きするだけでは、どの項目が誤解されたかを後から調べられません。「受付時のカテゴリ」と「確認後のカテゴリ」を別に保存し、変更日時・変更者・理由を記録する構成を検討します。
たとえば「その他」で受け付けた相談が、確認後は「契約・請求」だったとします。同じ変更が続くなら、契約更新に関する補足を選択肢に追加する判断材料になります。担当部署、対応状況、原因タグはそれぞれ別の情報として持ち、担当者の異動や対応完了によって問い合わせの用件が変わらないようにします。
問い合わせカテゴリは、管理画面の分類だけでなく、FAQや自動返信とも連動できます。 たとえば「料金・見積」を選んだ人には、送信完了後に料金の考え方や導入事例を案内する。 「利用中サービスの不具合」を選んだ人には、受付番号や緊急時の連絡先を明記する。 このようにカテゴリごとに次の案内を変えると、問い合わせ体験全体が自然になります。
連携例 カテゴリをFAQ・自動返信・レポートへ使う
ユーザーが「料金・見積」など目的に近い項目を選ぶ。
内部ルールで営業部やサポート窓口へ通知する。
カテゴリに合った文面やFAQリンクを返す。
月次で件数・傾向・FAQ化候補を確認する。
カテゴリは「選ばせるための項目」だけではなく、送信後の処理や改善活動にも使えます。
FAQとの連動では、「問い合わせが多いカテゴリ」から優先的に記事を増やす方法が有効です。 分類が整っていれば、どのカテゴリに問い合わせが集まっているかが分かり、FAQやヘルプページの改善対象を決めやすくなります。
カテゴリ設計では、次のような状態を避けたいところです。
カテゴリは増やすほど精密になるわけではありません。 むしろ、増やしすぎると選択ミスが増え、レポートも信用しづらくなります。 迷うカテゴリは統合し、必要な補足はタグや内部項目で扱う方が、長く運用しやすくなります。
カテゴリは、一度作って終わりではありません。 サービス内容、顧客層、問い合わせ内容が変われば、分類も見直す必要があります。 ただし、思いつきで追加・削除を繰り返すと、過去データとの比較が難しくなります。
運用開始前に、次のルールを決めておくと管理しやすくなります。
表示名の変更と、分類の意味の変更を区別します。名称だけの修正なら同じカテゴリIDを使う方法がありますが、二つのカテゴリを一つに統合する場合は、旧IDと新IDの対応関係、適用開始日を管理します。廃止したカテゴリは新規受付の候補から外し、過去の問い合わせからは参照できる状態を残します。
レポートには「受付当時の分類で集計する」方法と、「現在の分類へ換算して集計する」方法があります。どちらを使った数字かを明記し、途中で混在させないことが必要です。また、「その他の割合」「担当者が再分類した割合」「別部署への転送件数」を同じ対象期間・集計条件で比較し、件数が少ない場合は実際の問い合わせ内容も確認します。
問い合わせ分類（カテゴリ）は、フォームの小さな選択項目に見えます。 しかし実際には、担当振り分け、対応速度、FAQ改善、レポート分析に影響する重要な設計要素です。
まずは実データを確認し、「その他」が多すぎないか、使われていないカテゴリがないか、似た分類が並んでいないかを見直します。 そのうえで、ユーザーに見せるカテゴリは目的ベースにし、社内で使う担当部署・優先度・分析タグは内部項目として持たせる。 この分け方にすると、フォームは分かりやすく、管理側では必要な情報を扱いやすくなります。
カテゴリは細かく作るほど良いものではありません。 選ぶ人が迷わず、対応する人が判断でき、あとから分析に使える。 その状態を目標に、まずは現在の問い合わせデータの棚卸しから始めるのが現実的です。