お問い合わせフォームの種別の決め方｜選択肢と担当者への振り分け設計
お問い合わせ種別の選択肢を利用者の目的から設計。ラジオボタンとプルダウン、追加項目の条件分岐、担当者への振り分け、選択変更時のテストを具体例で紹介します。
お問い合わせ種別は、利用者が相談の目的を伝え、運営側が対応を始めるための項目です。「営業部」「管理部」のような社内組織だけで分けるより、「サービスの相談」「利用中の質問」など、利用者が判断できる言葉を使います。
選択肢を増やす前に、回答によって何が変わるかを決めましょう。振り分けや必要項目に違いがないなら、種別そのものが不要な場合もあります。
部署名ではなく、問い合わせの目的から分ける
| 表示する選択肢 | 運営側で行うこと |
|---|---|
| 導入・制作の相談 | 新しい依頼として内容を確認 |
| 利用中のサービスについて | 既存利用者の対応担当へ確認 |
| 取材・協業の相談 | 該当する担当者へ共有 |
| その他・どれに当てはまるか分からない | 窓口担当が内容から判断 |
この表は設計例です。実際にはサイトで使っているサービス名称と揃えます。「その他」を選ぶ人が多い場合は、その相談内容を見て分類の不足や分かりにくさを見直します。
一つだけ選ぶか、複数選べるかを先に決める
担当者を一つ決める目的なら、単一選択のラジオボタンやプルダウンが候補になります。複数選択を許すと、二つの担当へ送るのか、代表の担当が確認するのかという運用が必要です。
少数の短い選択肢なら、一覧で読めるラジオボタンを検討できます。選択肢が多い場合はプルダウンも使えますが、そもそも分類を細かくしすぎていないか確認します。初期状態で先頭を自動選択すると、利用者が選ばずに送ってしまう可能性があるため、選択必須なら未選択の扱いも決めます。
種別による追加項目は、必要な場合だけ見せる
利用中の質問なら製品名、新しい見積もりなら依頼内容など、種別によって必要な情報が変わる場合があります。条件付きで表示するなら、サーバー側の必須条件も同じにします。非表示になった項目をエラーとして要求すると、利用者が修正できなくなります。
種別を変更したときに、古い入力を残すか消すかも決めましょう。値を保持する場合でも、最終的な選択に関係ない情報を通知へ混ぜないようにします。メール・郵送で分岐する資料請求も、この考え方を使う例です。
選択肢とメールの送信先を直接結び付けない
ブラウザーから送信先のメールアドレスを受け取り、そのまま宛先として使う設計は避けます。種別ごとの識別子をサーバー側で検証し、許可された送信先へ対応付ける方法を検討します。想定外の値を受けたときの扱いも必要です。
担当者への自動振り分けを行わず、共通窓口へ通知し、種別を読んで人が振り分ける運用もあります。通知先を複数登録できる機能と、種別によって通知先が変わる機能は別なので、テンプレートの仕様を確認してください。
全選択肢と、途中で変更する操作を試す
- すべての種別が確認画面とメールに正しく表示されるか。
- 未選択や想定外の値を適切に扱うか。
- 追加項目の表示と必須条件が一致するか。
- 種別を変更して戻っても、古い担当へ通知されないか。
- 担当者の不在時に、共通窓口で確認できるか。
自動振り分けを実装する場合は、テスト用の通知先で対応表を確認します。件名に種別を付けるだけでも分類の助けになりますが、問い合わせ本文を読まずに自動で処理できるとは限りません。
標準機能と追加実装の境界を確認する
FreelanceFormの入力チェック・管理者通知を確認し、種別ごとの条件や宛先変更が必要なら追加要件として整理します。種別別の自動振り分けが標準で使えるという意味ではありません。
まずはヒアリングの仕様表に、選択肢と担当者を一対ずつ書いてみましょう。利用者が迷わず選べて、担当者が次に動ける分類になっていれば、種別を設ける目的を果たせます。
