ホームページの問い合わせフォーム、公開前に分ける5つの確認

ホームページの問い合わせフォームは、送信完了の画面が出るだけでは確認が終わりません。入力、エラー案内、完了表示、受信記録、対応担当を分けて見ます。次の5欄の確認票を使うと、制作側へ確かめたいことを具体的に渡せます。

問い合わせフォームは5つの段階を分けて確認する

公開前の確認では、どこまで実際に試したかを残します。たとえば入力欄が表示されることを見ても、送った内容が受信先へ届くことまでは分かりません。以下は自社で記入するための整理案です。特定のサービスの仕様や、問い合わせ数が増える効果を示すものではありません。

各欄には、確認した日、担当、結果を記入します。試していない条件は合格にせず、確認する相手と範囲を決めます。顧客の氏名や相談文を、確認用の票へ写す必要はありません。

入力欄とエラー案内は何を確かめるか

入力欄では、何を入れるのか、どの項目が必須かを画面から読み取れるか確かめます。入力例と、実際に入力する値の欄が紛らわしくないかも確認します。項目名を変える場合は、受け取る担当が必要としている情報と照合してください。

W3Cの入力検証の解説は、入力内容の検証によって利用者が誤りを避けられるようにする方法を示しています。必須の入力が欠けている場合や形式が合わない場合など、何が問題かを案内する参考になります。ここでW3Cの解説を使った確認だけで、すべての基準に適合したと判定するものではありません。

エラー表示を試す時も、実際の顧客情報を入力しないようにします。試す値と操作は制作担当と決め、入力だけでデータが保存される仕組みがあるか分からない場合は、先に確認してください。試しながら実在する人の連絡先を探したり、他社のフォームへ送ったりする必要はありません。

表示だけの確認と操作の確認を分ける

公開ページを読むだけで分かる項目と、テスト環境で入力して確かめる項目を分けます。エラーを起こす操作が本番の送信や通知につながる可能性があるなら、制作担当へ条件を聞いてから進めます。確認票には、どの環境と操作で確かめたかも残してください。

完了表示と受信は同じ確認か

完了表示と、受信先へ情報が届いたことは、別の段階として記録します。「受け付けました」という画面を見ただけで、受信の担当者が内容を確認できたと判断しないためです。

W3Cのフォーム通知の解説は、送信が成功したか、エラーがあったかを利用者へ伝える方法を示しています。自社のフォームでも、操作した後に何が起きたか分かる案内になっているか確認します。返答の時間や受付内容については、実際に対応できる範囲が決まってから表示へ反映します。

上の行は記入方法の架空例です。すでに送信や受信を確かめた実績ではありません。アクセス数、送信ボタンのクリック、受信、実際の相談や契約を、同じ数字として扱わないようにします。

実送信を試す前に何を決めるか

受信までの確認が必要な場合は、実送信を行う前に、テスト環境、入力する情報、受信先、確認担当を決めます。本番を使う必要があるなら、通知先や保存先への影響と実行の許可を揃えてください。許可のない顧客宛ての通知や、予約・購入につながる操作を試す手順にはしません。

• どのページと環境で行うかを決めます。
• 実在しないテスト情報を、担当者と確認します。
• 送信によって届く通知と保存先を確認します。
• 受信した内容を誰が照合するか決めます。
• 実行する範囲と記録方法の許可を受けます。

画面の確認だけでよい作業を、実送信へ広げない進め方です。受信先が不明、担当者と連絡が取れていないなど、条件が揃わない場合は、その不足を制作側へ渡します。検証をしていないことは不具合の証明でもないため、「未確認」と区別して残します。

公開後も、変更した箇所から確認を続ける

公開後に項目、通知先、表示文、担当者などを変えた場合は、どの段階に影響するかを最初の5欄で見直します。確認日だけを更新せず、実際に見た表示と、操作した範囲を記録してください。

たとえば窓口の担当を替える場合、画面上の文章だけでなく、受け取る経路と引き渡しの確認が残ります。この例は変更点を選ぶための整理であり、現在の設定の変更を指示するものではありません。

ページ全体の役割を整理するならLPとホームページの違いを、更新する担当を決めるならホームページの更新体制を参照してください。本稿はフォームの入力から受信後の対応までを分けた確認票として使います。

自社の制作範囲を検討する際は、CRAFTの制作サンプルを確認するから案内をご覧ください。現在のフォームで未確認の段階を整理してから、どの部分を相談するか決められます。