予約・問い合わせフォームは、送信できるだけでは完成とはいえません。入力ミスを直せること、重複受付を防ぐこと、担当者に内容が届くことまで一続きで確認しましょう。利用者が操作する画面から受付後まで、公開前に確かめたい点を具体例で整理します。
送信できたのに、問い合わせにつながらないのはなぜ？
制作中のフォームに名前とメールアドレスを入れ、送信完了の画面が表示される。これで確認を終えると、受付担当者に通知が来ていないことや、利用者が次の行動を判断できないことを見落とす可能性があります。フォームの目的はボタンを動かすことではなく、予約や相談を受け付け、その後の対応へつなぐことです。
まず、入力する人、通知を受け取る人、内容を管理する人を並べて考えます。同じ人が兼ねていても、確認する画面と目的は異なります。送信内容が管理画面に残るのか、メールだけで受け付けるのかも確認してください。画面上の「完了」と、実際に必要な処理が終わった状態が一致していることが大切です。
予約フォームなら、空き枠の選択から確定、変更やキャンセルの案内までを一続きとして見ます。問い合わせなら、受付の案内と担当者の受信を確かめます。返信までの目安や連絡方法を表示する場合は、実際の運用と一致させてください。対応できない時間を約束したり、用意していない窓口へ案内したりしないよう、文章も含めて確認します。
この記事の例は、特定の企業で起きた不具合の紹介ではなく、公開前の確認項目を考えるための一般的な例です。自社の業務で必要なものを選び、入力から受付後までの完成条件を短く書き出してから試すと、見た目の確認だけで終わりにくくなります。
入力を間違えたときに、利用者が直せるか
最初は正しい内容で送信し、次に間違えた入力で確かめます。必須項目が空欄、メールアドレスの形式が違う、文字数が長いといった条件を、フォームの仕様に合わせて選びます。住所や氏名にはさまざまな表記があるため、全角・半角や記号を一律に拒否して、必要な利用者まで止めていないかも見直します。
エラーが表示されたら、どこをどう直せばよいか、入力した人の立場で読んでみてください。「エラーです」だけでは原因が伝わりません。該当する欄の近くに説明があり、入力例や必要な形式が分かると修正しやすくなります。色だけで間違いを示すのではなく、言葉でも伝えることを基本にします。
W3CのWCAG 2.2には、入力エラーの特定、ラベルや入力方法の説明、キーボード操作などに関する基準があります。こうした観点を参考に、マウスを使わずに欄を移動できるか、入力欄と項目名の対応が分かるかを確かめましょう。基本項目を試すことと、フォーム全体のアクセシビリティへの対応を評価することは分けて考えます。
別の欄を直しただけで、入力済みの長い相談内容が消えると、利用者はやり直しを迫られます。確認画面から戻ったとき、エラーのあと、予約日時を選び直したあとに、必要な入力が保持されるかも試します。個人情報を共有端末に残さないなど、保持しないことが必要な仕様もあるため、残ることだけを正解にしないでください。
送信中・二重操作・メールまで、流れを切らずに見る
通信に時間がかかると、利用者はボタンを押せたか不安になります。処理中と分かる表示があるか、同じ操作を繰り返した場合に意図しない重複受付が起きないかを確かめます。画面上でボタンを押せなくする対応だけでは判断できないこともあるため、受付側に残った件数や内容まで確認することが大切です。
予約の場合は、同じ枠を選んだ人がいたときに、どう案内する仕様なのかを決めておきます。希望を受け付けるだけの仮予約と、その場で確定する予約では、完了画面やメールに必要な言葉が違います。利用者には「確定」と見えるのに、担当者は調整前だと考えている状態を避けるため、受付後の運用も担当者と通してみましょう。
メールでは、利用者への自動返信と担当者への通知を別々に確認します。宛先、件名、日時、入力内容、問い合わせ先の表示が合っているかを見ます。受付メールに不要な個人情報を載せていないか、他の利用者の情報が混ざっていないかも確認対象です。テストは専用のメールアドレスと架空の入力データで行い、実際の顧客へ送らないようにします。
送信に失敗した場合は、受付できていないことが分かるか、再度送る際の案内があるかを確かめます。画面は完了でも通知が届かないなど、画面だけでは切り分けられない問題は、開発担当者に確認を依頼してください。再送を繰り返す前に、管理画面などで受付状況を確認できる仕組みや連絡手順を用意しておくと対応しやすくなります。
スマホの実操作と、修正できる記録を残す
スマートフォンでは、入力中のキーボードが画面の広い範囲を占めます。送信ボタンやエラー説明が隠れないか、日付を選びやすいか、電話番号に合った入力ができるかを、実際の端末で確認します。指で押せる余白や、選択した状態の分かりやすさも見てください。制作画面の縮小表示だけでは、入力時の負担は分かりません。
よく利用される端末とブラウザの組み合わせを決め、縦横の向きや文字の拡大も試します。すべての環境を一度に確認できない場合は、何を優先し、何を未確認としたかを残します。利用者から問い合わせが来たときに、確認済みの条件と比べられるからです。確認範囲を曖昧にしたまま「スマホ対応済み」と判断することは避けましょう。
不具合の記録は、「予約できない」よりも「希望日時を選び、確認画面から戻ると選択が消える」のように、操作と結果を具体的にします。期待した結果、実際の結果、端末、ブラウザをそろえれば、修正する人が状況を理解しやすくなります。画像を添える場合は、入力内容やアドレスなど、共有する必要のない情報を隠します。
修正後は、問題が起きた操作を再度試し、前後の流れも確認します。メール本文だけを直したつもりでも、差し込み項目に影響する場合があります。確認した日と結果を更新し、未解決の項目を担当者と共有してください。完了した項目だけを並べるより、残っている課題と対応方針を一緒に見られる方が公開判断に役立ちます。
外部へ点検を依頼するときは、送信するとメールが届くか、予約枠が減るか、外部サービスへ通知されるかなど、試験の影響も伝えます。テスト用の環境を用意できるなら、実運用とどこが違うかも説明します。用意できない場合は、実施できる操作や時間、送信先を担当者と調整し、通常の受付と混同しないようにします。
確認項目を整理しきれない場合は、Custosの公開前診断の報告書見本も参考になります。自社の予約や問い合わせの仕様を伝え、対象の画面、必要なアカウント、確認する範囲を申し込み前にすり合わせてください。
Custosの公開前診断はWebアプリが対象です。ネイティブアプリ、アクセスを集中させる負荷試験、長期の安定性評価、コードレビュー、修正の代行、WCAG適合判定は対象外です。スマホで操作するWebフォームの確認と、スマホアプリ自体の確認も異なります。フォームの基本的な動作と使いやすさ、安全面の入口を確かめる点検として範囲を確認し、詳しい脆弱性診断が必要な場合は別途相談してください。
まとめ：フォームは、受付後まで確かめて完成へ
予約・問い合わせフォームでは、正常に送信できることに加え、入力ミスを直せること、処理中や失敗が伝わること、担当者まで必要な内容が届くことを確かめます。スマホで実際に入力し、利用者と受付担当者の両方の目で試すと、画面だけを見ていたときに気づけなかった負担を整理できます。
日常の運用では、問い合わせが急に来なくなったときに、需要が減ったのか、フォームが止まっているのかを切り分けられると安心です。担当者が定期的に受付の流れを確かめる、変更のあとにテスト送信するなど、運用に合う確認方法を決めます。テストの履歴を残せば、問題が起きた場合に、いつまでは使えていたかを調べる手掛かりにもなります。
公開の前には、未解決の問題が業務へ与える影響を確認し、対応する人と時期を決めます。公開後も、通知先や予約ルールを変えたときには、関係する流れをもう一度試しましょう。連絡先の変更のような小さな更新でも、受付の目的を果たせなくなる可能性があるためです。
動作確認とあわせて、公開後のWebサイトの脆弱性、つまり攻撃に使われる弱点も点検します。CustosのURL診断を入口に、URLから確認できる範囲と、管理画面や社内の運用など別途確かめる範囲を整理しましょう。フォームが使いやすいことと、情報を適切に扱えることを、両方の観点で確認していくことが大切です。
出典・参考資料
画像は記事の説明用に制作したイメージです。実際の被害企業・診断結果・実績を示すものではありません。