ホームページの「相談・見積もり・予約」はどう分ける？入口と遷移先の整理表
ホームページの入口は、「お問い合わせ」のままでよいのでしょうか。予約ボタンを押した人は、その場で予約が確定したと思わないでしょうか。相談と見積もり依頼を同じフォームへ集めても、受付する側はきちんと分けられるでしょうか。
入口の言葉を決めるとき、短くて目立つ表現を先に探すと、実際の受付方法との食い違いが残ります。「無料相談」と書いたのに無料の範囲が決まっていない、「予約する」と書いたのに送信後は日程確認が必要、といった状態です。反対に、すべてを「お問い合わせ」へまとめた方が、小さな事業の運用に合う場合もあります。
この記事では、Bämの制作実務上の提案として、ページ上からフォーム、電話、チャット、外部予約などの受付先へ移る入口を棚卸しします。フォーム内の「確認」「送信」、入力エラー、送信中、完了表示や、送信後の返信・見積提示・契約までを扱う記事ではありません。
先に決めるのは言葉ではなく、何を受け付ける入口か
「相談」「見積もり」「予約」は、業界共通の固定された意味ではありません。同じ「相談」でも、簡単な質問を受ける事業もあれば、候補日や予算を聞いて個別面談を調整する事業もあります。まず自社で何を受け付け、利用者が最初にどこまで進めるのかを言葉にします。
- 相談：困りごとや希望を伝え、対応できそうか一緒に整理する入口。契約や料金確定とは限りません。
- 見積もり依頼：見積もりに必要な条件を送り、金額や範囲の提示を依頼する入口。送信だけで価格が確定するとは限りません。
- 予約依頼：希望日時を伝える、または空き枠を選ぶ入口。即時確定か、事業者の確認後に確定かを分けます。
- その他：資料請求、取材、採用、既存利用者の連絡など、相談・見積もり・予約とは受付目的や担当が異なるため、同じ窓口へ含めるかを別に判断したい用件です。
この四つは、四つのボタンを置くための分類ではありません。用件が少なく、同じ担当者が同じ手順で受け付けるなら、一つの「お問い合わせ」から選んでもらう方が分かりやすいこともあります。分類は、入口を増やす前に現在の受付実態を確認するための目安です。
受付目的と受付手段を分けて考える
相談・見積もり依頼・予約依頼は「何のために受け付けるか」です。フォーム・電話・チャット・外部予約は「どこで受け付けるか」です。この二つを混ぜると、「電話」と「予約」のどちらをボタン名にすべきかという、比べられない選択になります。
たとえば、相談はフォームと電話で受け、予約依頼は外部予約画面だけで受ける事業があります。反対に、一つのフォームで相談、見積もり依頼、予約依頼を受け、最初の選択肢で用件を分ける方法もあります。どちらが正しいかではなく、表示した入口と実際に処理できる方法が合っているかを確認します。
電話やチャットを置く場合も、それだけで便利になるとは限りません。電話受付の詳細はClick to Callボタンの記事、チャットの個別例は小規模クリニックでのチャット導入例へ譲り、ここでは入口台帳に役割を記録する範囲に留めます。
コピーして使える入口CTA台帳
台帳は、公開画面を見ながら一入口ずつ記入します。以下の十二項目を一入口分として複製し、公開画面と実際の受付方法を照合しながら残します。最初から十二項目を横長の表にすると、スマートフォンで読みにくく、更新もしづらくなります。まず全体を見渡す五列の概要表を作り、各入口の詳しい内容を縦型の確認票へ分けます。
| 設置ページ・位置 | 表示名 | 受付目的 | 遷移先 | 台帳状態 |
|---|---|---|---|---|
| サービスページ上部 | まずは相談する | 質問・相談 | 相談フォーム | 現行 |
| 料金案内の下 | 見積もりを依頼する | 条件確認・見積もり依頼 | 同じ相談フォーム | 未確認 |
| 訪問案内ページ | 訪問日時を予約する | 予約依頼 | 外部予約画面 | 要修正（予約の確定方式が未確認） |
「台帳状態」は、予約の確定状態やフォームの送信状態ではありません。ホームページ上の表示を管理するための状態です。「現行」は表示と受付運用の一致を確認済み、「未確認」はまだ照合していない、「要修正」は不一致が見つかっている、「停止予定」は撤去または受付終了が決まっている状態として使います。
基本9項目
管理3項目
台帳へ管理画面のパスワード、二段階認証コード、顧客情報は書きません。外部予約サービスの画面名や設定箇所を残す場合も、秘密情報は別の安全な方法で管理します。
架空の訪問型サービスで、入口から確定条件までつなぐ
架空の訪問整理サービス「まちの片づけ相談」を例にします。実際の料金や契約条件を示す例ではありません。この事業では、相談入口、見積もり依頼入口、予約入口の三つがあります。相談と見積もり依頼は共通フォームへ、予約依頼は外部予約サービスへ進みます。
以下は、入口ごとの差が表れやすい項目を抜粋した記入例です。実運用では、基本9項目と管理3項目を一入口ごとに残します。
相談入口の確認票
見積もり入口の確認票
予約入口の確認票
外部サービスのボタン名を変更できない場合は、直前の見出しや説明で補います。「外部予約画面へ移動します」「対象は事前相談済みの方です」など、確認済みの事実を短く示します。変更できないことを隠すより、利用者が押す前に予測できるようにします。
入口をまとめるか分けるかは、三つの一致で判断する
文字やURLが同じかどうかだけでは判断できません。次の三つを並べます。
- 受付目的：事業者は何の用件として受け取るか。
- 利用者が最初に得る結果：押した人は最初に何ができるか。
- 確定条件：相談、金額、日時、依頼はどの時点で確定するか。
三つが同じなら、ページごとに「相談する」「話を聞く」「問い合わせる」と名前が揺れていないか確認します。三つが違うのに全部「お問い合わせ」なら、入口付近や到着先で用件を選べるか、必要な説明があるかを確認します。同じURLへ送ること自体が問題なのではなく、入口ごとの期待を到着先で受け止められないことが問題です。
一つの「お問い合わせ」へまとめやすい場合
- 相談・見積もり依頼・予約依頼を同じ担当が確認し、最初の対応もほぼ同じ
- 用件を細かく決められない人が多く、まず相談内容を聞く運用になっている
- フォーム冒頭で用件を選べ、選べない人向けの案内もある
- 入口を分けても遷移先、必要事項、確定条件が実質的に変わらない
入口を分けた方がよい場合
- 相談と予約で対象者、必要な準備、担当、確定条件が大きく違う
- 予約は外部画面、見積もりは専用フォームなど、最初の遷移先が明確に違う
- 既存利用者の連絡と新規相談を、同じ窓口で受けると対応漏れが起きる
- 入口を分けることで、押す前に対象外や必要条件を説明できる
分ける場合も、選択肢を増やしすぎないようにします。「どちらか分からない方はこちら」という相談入口を残す、サービスページごとに関係する入口だけを置くなど、迷った人の逃げ道を用意します。
入口の周囲と最初の遷移先で、約束しすぎない
短いボタン名だけで、対象、費用、必要な準備、確定条件のすべては伝えられません。入口の近くに一、二文の補足を置き、遷移先の見出しと冒頭でも同じ目的を確認できるようにします。
- 相談入口の近く：何を相談できるか、未決定でも送れるか、契約ではないこと
- 見積もり入口の近く：見積もりに必要な条件、送信だけで金額が確定しないこと
- 予約入口の近く：対象者、即時確定か確認後確定か、外部画面へ移るか
- 電話・チャットの近く：受付時間、対象用件、すぐに回答できない内容があるか
対応範囲や対象外業務を詳しく整理する場合は「対応できないこと」の整理表、フォーム項目を見直す場合は問い合わせフォーム項目の整理表へ進みます。この記事では、入口付近に必要な最小限の説明と、最初の遷移先の一致だけを扱います。
同じ機能は一貫して見せ、違う機能は違いを説明する
WCAG 2.2の達成基準3.2.4では、一連のWebページ内で同じ機能を持つ部品を一貫して識別することが示されています。W3Cの解説も、同じ機能のラベルがページごとに異なると利用しにくくなる一方、機能が異なる場合は異なるラベルが必要だと説明しています。一貫とは、必ずしも一字一句の完全一致ではありません。
達成基準2.4.4やデジタル庁デザインシステムのリンクテキストは、リンクの目的を判断できるようにする際の参考になります。ただし、これらは「相談」「見積もり」「予約」の事業上の意味を決める資料ではありません。自社資料と受付担当への確認で定義し、Web上の表示と照合します。
読み上げ名は、達成基準3.2.4と2.4.4の説明だけへ結び付けず、別の確認観点としても点検します。見た目が「相談する」なのに読み上げでは「詳しくはこちら」、同じ機能なのにページごとに異なる名前、といった食い違いを探します。短いスポットチェックだけで、WCAG全体へ適合したとは判断しません。
スマートフォンで台帳と入口を確認する
入口はスマートフォンで押されることも多いため、公開前に390px程度の実画面で、長い日本語ラベル、外部サービス名、補足文の折り返し、横はみ出しを確認します。これは制作時の表示品質検査であり、390pxで見えたことをWCAG適合へ読み替えません。
W3CのReflow解説では、一般的な横書き本文は320 CSS px相当で読み進められること、二次元関係が必要なデータ表には例外があることが示されています。本記事では、全体を比較する概要表はカード化し、各入口の詳細は縦型の確認票にしています。表だけに重要な判断を閉じ込めず、前後の本文にも同じ要点を残します。390pxの実画面確認とは別に、320 CSS px相当でも、例外部分を除いて二方向のスクロールが必要にならないかを確認します。たとえば、1280px幅の表示を400％へ拡大する方法があります。
- 入口文言が途中で欠けず、補足と一緒に読める
- ページ全体に不要な横スクロールが出ない
- 入口を押すと、台帳に記録した最初の遷移先へ移る
- 外部画面へ移る場合、戻り方や対象が分かる
- キーボード操作でフォーカス位置を確認できる
- 読み上げ名が見た目のラベルや実際の機能と食い違わない
制作会社へ渡すのは、CTAに限った6項目
ホームページ全体の事業説明を作り直さなくても、入口の相談は始められます。次の六つを、分かる範囲で渡します。未決定は未決定と書き、推測で埋めません。
- 現在のページURLと、入口がある位置の画面
- 現在表示されているリンク・ボタンの文言
- 実際に受け付けたい用件と、受け付けない用件
- クリック後に開くフォーム、電話、チャット、外部予約の情報
- 送信や選択の時点で確定すること、まだ確定しないこと
- 受付内容を確認する役割と、Web表示を更新できる役割
初回相談の準備メモでは事業や制作全体の準備を扱っていますが、ここで渡すのは入口CTAの差分に限ります。送信後の返信、ヒアリング、見積提示、正式依頼までを案内したい場合は、問い合わせ後の流れの記事と分けて整理します。
よくある質問
入口は一つの「お問い合わせ」へまとめてもよいですか
まとめても構いません。相談、見積もり依頼、予約依頼を同じ担当・同じ手順で受けるなら、一つの入口が運用に合う場合があります。到着先で用件を選べるか、選べない人も送れるか、送信時点で何が確定するかを案内します。
相談と見積もり依頼を同じフォームへ送ってもよいですか
同じフォームでも、到着先の見出しと対象用件が入口ごとの期待を受け止められるなら問題とは限りません。用件選択、入力項目、送信後の案内は、フォーム項目の記事と問い合わせ後の流れの記事で分けて整理します。
「予約する」はどの時点で確定と書けばよいですか
実際の予約運用に合わせます。空き枠を選び決済や必要手続きまで終えると即時確定するのか、希望日時を送り担当者が承認した後に確定するのかを確認します。未確認なら「予約確定」と断定せず、まず台帳を未確認にします。
電話やチャットも台帳へ入れますか
ページ上の入口として使っているなら入れます。受付目的、対象用件、受付時間、利用者が最初に得る結果を記録します。電話やチャットがあるだけで即時回答を約束したことにならないよう、実際の運用を確認します。
この整理表で法令やWCAGへの適合を確認できますか
この表だけでは確認できません。入口の目的、一貫した識別、読み上げ名、スマートフォン表示を点検する助けにはなりますが、法令や規格への適合には対象範囲を定めた別の検査が必要です。必要に応じて専門家へ確認します。
まとめ：入口の言葉を、受付実態と一行ずつつなぐ
「相談」「見積もり」「予約」「お問い合わせ」のどれが正しいかは、言葉だけでは決まりません。まず受付目的と受付手段を分け、表示名、対象、最初の遷移先、利用者が最初に得る結果、確定条件を一行ずつつなぎます。同じ機能なのに名前が揺れていないか、違う機能なのに同じ名前で期待を混ぜていないかを確認します。
一つの「お問い合わせ」へまとめる方が合う事業もあれば、相談と予約を分ける方が合う事業もあります。四区分をそのまま四つのボタンにせず、受付できる体制、対象者、最初の案内、更新担当まで含めて決めます。これなら、見た目の言葉選びではなく、利用者と受付担当の双方が迷いにくい入口を制作会社へ説明できます。
Bämでは、ボタンの言葉だけを先に決めるのではなく、サービス内容、対象者、現在のページ、遷移先、実際の受付方法を聞きながら、入口をまとめるか分けるかを一緒に整理します。正式な料金、無料範囲、予約・契約の確定条件は推測せず、事業者が確認した内容をもとに表示と導線へ反映します。
入口の名前と受付方法が合っているか、一緒に整理できます。現在のURL、入口がある画面、実際に受け付けたい用件を分かる範囲でお知らせください。
