事業が複数ある会社のサイトで、問い合わせフォームの最初に「営業部」「技術部」「運用部」から担当部署を選ばせていないでしょうか。社内で担当が明確でも、初めて相談する人には境界が見えません。設備の不具合から更新の相談へ進む、導入前の質問と既存契約の確認が重なるなど、複数部門にまたがる相談もあります。選択を間違えると返信が遅れるのでは、と利用者が入力をためらうこともあります。
問い合わせフォームでは、何について相談したいかを利用者の言葉で聞きます。相談目的、必要な入力、最初に受ける窓口、担当を確認する人を対応させれば、利用者は分かる範囲で送信できます。この記事では会社の部署や責任を再編する話は扱いません。現行のサービスページと受付体制を照合し、フォームと通知の改修範囲を決めます。
部署選択と引継ぎを点検する
現行のフォームへサービスページから進み、最初の選択肢を読みます。「製品事業部」「ソリューション推進部」など社内名称だけが並ぶ場合、利用者は自分の相談がどの部署の仕事か推測しなければなりません。複数の部署が担当する内容なら、正解が一つに決まらないこともあります。選択後の入力項目と完了画面まで進み、間違えたと気付いた人が戻れるかを確認します。
受信側では、選んだ部署に通知が届いても、適切な担当者へ引き継げるかを確認します。窓口担当が別部門へ転送した際、フォームに書かれた目的と添付情報が伝わるか。担当が不在なら誰が受け取るか。複数部門にまたがる相談では、誰が最初の返信をするか。問い合わせ履歴の中で聞き直しや転送が起きた場面を数件選び、発生した理由を見ます。個人情報や企業名を記事用に持ち出さず、分類と手順だけを記録します。
事業内容のページでは、対応範囲や関連するサービスを説明します。そのページから進む問い合わせフォームは、分かる目的から入力し、社内の一次受付へ渡る流れを作ります。対象の複数事業・サービスの整理ページも、組織図と顧客が探す順番は一致しないこと、担当が分からない相談の入口を残すことを案内しています。
相談目的と通知先の対応表
最初に、現行の問い合わせの種類を利用者の言葉へ置き換えます。表は設計例です。実際の目的、受信先、担当の権限は各社の受付資料と部門責任者で確定します。
表は左右にスクロールして確認できます。
| 利用者が選ぶ目的 | 最初に聞く項目 | 一次通知先 | 担当確認の方法 |
|---|---|---|---|
| 新しいサービスを相談したい | 相談したいこと、対象、希望時期 | 共通受付または営業の一次窓口 | 受付担当が対象サービスを確認し主担当へ渡す |
| 利用中のサービスについて聞きたい | 利用中のサービス、困っていること、連絡先 | 既存顧客の一次窓口 | 契約・運用情報を権限のある担当が照合する |
| 複数のサービスを組み合わせたい | 実現したい目的、関係するサービスの候補 | 共通受付 | 主担当を一人決め、必要な部門へ確認を依頼する |
| どれに当たるか分からない | 相談内容の短い説明、希望する連絡方法 | 共通受付 | 一次受付が確認し、適切な担当を選ぶ |
この表の列を埋める順番は「目的→何を聞くか→最初に受ける人→次に確認する人」です。先に部署名の一覧から作ると、利用者の選択肢が社内構造の写しになりがちです。目的の例は、現在の問い合わせ履歴とサービスページを見て調整します。「見積もり」「資料請求」など行動名だけで分けると、同じ行動が複数事業にまたがる場合があります。必要なら「何について」と「何をしたい」を分けて聞き、両方を受信側へ渡します。
対応表を作る際には、各行に実際の入力画面の名前と通知設定の場所も書き添えます。例えば「利用中のサービスについて」を選んでも、管理画面では単に「その他」と表示されるなら、担当が目的を読み直す必要があります。ページのボタン文言、選択肢の値、受信メールの件名、管理画面の分類名を照合し、同じ意味の言葉へそろえます。目的の名称を直すときは、表示と通知ルールをあわせて更新します。表示だけを変えて、通知ルールが古いまま残ることを防ぐためです。
一つの相談が二つの目的に当てはまる場合は、利用者に両方の部署を選ばせるのではなく、最も近い目的と説明欄で受ける案があります。例えば導入済みの設備に不具合があり、その更新も検討したいなら、最初の受付は現在の利用状況を確認できる窓口にする。そこから更新を扱う担当へつなぐかどうかを社内で判断します。ただし、この振分けは例示です。現行の契約と緊急受付の仕組みを確認し、一般フォームでは受けられない内容は別の案内へ分けます。
英国政府のサービス設計指針は、フォームの各質問について、なぜ必要か、誰が答えるか、どう使うかを先に決めるよう勧めています。これは日本の会社へそのまま適用する規則ではありませんが、部署の都合で項目を増やす前に用途を確かめる考え方として使えます。氏名や連絡先を含む入力項目は、一次返信に必要な範囲から検討し、関係部門へ一斉に全文を送る前に閲覧範囲を決めます。
目的を選び、必要な項目を聞く
入口では「何についてのご相談ですか」と問い、サービスを選べる人にはサービス名から進む道も残します。例えば「新規導入を相談」「利用中のサービスについて」「複数のサービスをまとめて相談」「まだ分からない」といった目的を示せます。これは選択肢の設計例であり、実際に受けられない相談を入口だけ用意しないよう、受信体制と合わせて決めます。
目的を選んだ後は、その相談に必要な項目だけを出します。新規相談なら現状と希望時期、既存の問い合わせなら利用中のサービスと困りごと、複合相談なら一緒に扱いたい課題の概要、という分け方です。どの経路でも長い部門別フォームを一画面へ詰め込む必要はありません。英国政府の同指針は、関連する質問を分け、必要な人にだけ分岐質問を見せる設計を紹介しています。実際のページ数と入力負担は利用者の状況を見て決めます。
選択肢のラベルには、部署名だけでなく利用者が自分の状況と照合できる説明を付けます。「技術部への質問」より「設備が動かない・操作で困っている」の方が目的は伝わりやすいかもしれません。ただし、障害受付や緊急連絡に別の窓口が必要なら、一般フォームへ誘導せず、適切な連絡方法を案内します。受付時間や返答の目安を載せる場合は、実際の運用と一致させます。
目的を選び直せることも重要です。詳細ページから「修理を相談する」を押した人は、その目的を初期値にしてもよいでしょう。ただし、フォーム上で「別の相談」を選んだ後に元の選択へ戻されないか、必須項目が切り替わるかを確かめます。ページの経路を示す値と本人が選んだ値を混同すると、受信メールの分類だけが古いままになります。テストではサービスページ、トップの共通相談、検索からの直接訪問の三つの入口を通し、同じ目的なら同じ受付結果になるか比較します。
ラジオボタンなど複数の選択肢は、「相談したい内容」というグループ名と各項目のラベルを対応させます。W3Cのフォーム解説では、関連する選択肢を視覚面とコード面でグループ化し、入力欄へ分かるラベルを付ける方法が示されています。色や位置だけで分類を伝えず、キーボードで選択しても内容が分かるかを確認します。「その他」には短い自由記述欄を添え、分類できない相談を無理に既存部門へ押し込まないようにします。
一次受付と主担当を分ける
目的を選択した瞬間に最終担当まで自動確定しようとすると、複数部門にまたがる相談を、適切な担当へ渡せないことがあります。まず受信を確認する一次窓口を決め、内容を見て主担当を確定する手順を作ります。新規の見積相談は営業が受ける、利用中の不具合は既存顧客窓口が受ける、複合相談と担当不明は共通受付へ入れるなど、経路は会社の現行運用に合わせます。フォームが担うのは「送る先の候補を整理する」ことで、会社の責任分担を自動で決めることではありません。
通知メールには、相談目的、選んだサービス、送信日時、連絡方法、一次受付先が見える件名と本文を用意します。管理画面では未確認、担当確認中、主担当が決定、返信済みなど、実際に使う状態を区別します。主担当を変えたときに、誰が最初の返信をするかが曖昧にならないよう、受付記録へ残します。複数部門へ通知する必要がある場合も、全員に同じ個人情報を配る前に、閲覧権限と転送の範囲を確かめます。
担当部門が休みの場合、メールが届かない場合、選択肢にない相談が来た場合の対応を、あらかじめ決めます。一次通知先が一人の個人アドレスだけなら、休暇中に止まる可能性があります。共有の受付箱、代理担当、管理画面の未対応一覧など、現在使える手段から選び、誰が毎日確認するかを明確にします。ここで約束する返信時期は、営業日や受付時間の実態が確認できた範囲だけを掲載します。
自動通知だけで振分けが完了したと見なさず、未対応を見つける方法も決めます。件名の分類が正しくてもメールが迷惑メールへ入る、担当が転送した後に返信者が決まらない、といった可能性があります。管理画面で受付状態を見られるなら、一定期間、未対応のまま残った相談を誰が確認するかを決め、メールだけの運用なら確認記録を残せる別の方法を検討します。特定の返答時間を記事から押し付けず、自社の対応体制から決めます。
送信結果と次の連絡を伝える
入力の最後には、利用者が選んだ目的と連絡先を確認できる画面を設けます。送信後は「受け付けました」だけで終えず、何を受け取り、次にどのような連絡があるかを現行体制に沿って説明します。担当部署をまだ確認していないのに「技術部が対応します」と確約しないことも大切です。W3Cのフォーム通知の解説は、送信の成功・失敗と、修正すべき入力欄を分かりやすく示すことを勧めています。
エラー時には「入力できませんでした」だけでなく、どの項目をどう直すかを示し、入力済みの内容を保持します。目的を変えたとき、非表示になった項目の値が誤って送信されないかも確認します。確認画面と完了メールでは、相談目的が同じ言葉で表示されるかを読み戻します。フォームの選択肢を更新した際に、通知側の分類名だけ古いまま残らないようにします。
画面と通知を担当者で確認する
改修範囲はフォーム単体ではありません。トップやサービス一覧の相談ボタン、詳細ページの案内文、フォームの選択肢、確認・完了画面、通知メール、受信後の管理画面が連動します。サービスの名称が変わったときは、どの画面と通知ルールを修正するかを対応表で管理します。ページ上では「担当不明でも相談可」と書きながら、フォームで部署を必須選択にしていないかも確認します。
サイト担当はページと入力欄を設計し、事業責任者は受けられる相談と対応範囲を、受付担当は通知先と引継ぎ手順を確認します。技術担当は、入力内容の保存・転送・閲覧権限と、選択肢を変えた際の動作を検証します。この分担を一枚の確認票に残すと、原稿だけ承認済みで通知が未設定という状態を避けられます。組織変更そのものはこの記事の範囲外ですが、窓口が変わった場合に更新する場所と承認者は決めておきます。
公開前のテストでは、表の四つの目的で実際に送信し、1440、768、390ピクセル程度の画面で選択、入力、エラー、確認、完了をたどります。キーボードでも選択肢と送信ボタンへ進めるか、スマートフォンで選択肢が切れないかを見ます。受信側は通知先、件名、入力内容、代理担当の動きを確認します。公開後は、担当不明として届いた件数と転送が発生した理由を記録し、選択肢を増減する根拠にします。数値改善を事前に約束せず、現状との比較から判断します。
参考資料
- GOV.UK Service Manual「Structuring forms」（各質問の用途と分岐の考え方を確認）
- W3C WAI「Grouping Controls」（関連する選択肢のグループ化を確認）
- W3C WAI「User Notification」（送信結果と入力エラーの通知を確認）
