サービスの申し込みフォームで離脱されるとき｜項目・エラー・送信後を点検する

こんにちは。バナナデスクです。

申し込みフォームまで来てくれたのに、最後まで送信されない。項目が多いのか、電話番号が必須だからか、ボタンの色が弱いのか。直す候補が多いと、どこから触ればよいか迷います。

まず一度、自分が管理するフォームのテスト環境で、メールアドレスの「@」を抜いた状態で送信してみてください。「入力内容に誤りがあります」とだけ出たら、読者はどの欄へ戻ればよいのでしょうか。入力の負担だけでなく、間違えた後に戻れるかも、フォームの大切な役割です。

この記事では、サービスの申込・相談フォームを、項目選び、入力中、エラー訂正、受付後の四つに分けて点検します。架空の事前相談フォームを一つ作り、表示文言まで具体化します。実サイトの改善率を測った事例ではなく、読者が自分のフォームを直すための設計見本です。

執筆：バナナデスク｜WEBビジネスの設計・集客・改善

離脱の原因を決める前に、止まる場所を探す

フォームを開いて閉じた人が全員、申し込みを決めていたとは限りません。条件を確認しただけの人、後で入力する人もいます。離脱という数字だけで、項目が多いことを原因にしないでください。

一方、入力した文字が消える、エラーの場所が分からない、送信しても結果が出ないといった不具合は、実際の操作で見つけられます。アクセスが少ない時期でも確認できるため、まずはこちらを点検します。

LPの流入から受付記録まで全体を切り分けたい場合は、申し込みがないLPの確認手順を参照してください。ここでは、フォームを開いた人が入力を終えるまでの画面と文言に絞ります。

項目は「今の受付に必要か」で選ぶ

今回は、架空の「オンライン講座づくりに関する事前相談」を例にします。送信は相談の受付で、購入や有料契約、相談日時の確定は行わない設定です。運営側はメールで確認し、日程を調整するものとします。

この条件なら、住所や郵便番号を初回から必須にする理由はありません。ただし、物品配送や対面訪問を含む別サービスなら必要になることもあります。「どのフォームも何項目以内」という決め方より、受付後の仕事に照らして選びましょう。

任意の自由欄へ「詳しく書いてください」とだけ書くと、短くてもよいのか迷います。「まだ整理できていない」を選べるようにしたうえで、自由欄には「例：講座のテーマは決まったが、各回の課題が決まらない」と入力の見本を添えます。

任意欄を大量に残すことも、見た目の負担になります。後で聞けばよい情報は、受付時の項目から外す選択もあります。個人情報の利用目的や取扱いの案内は、実際の運用に合わせて別途整えてください。

入力前から送信までの文言を一続きで作る

以下は、先ほどの架空フォームに置く表示文言の完成見本です。実際に送信できるフォームではありません。

オンライン講座づくりの事前相談

講座の構成や教材づくりについて、相談したい内容をお知らせください。送信後、担当者が内容を確認し、2営業日以内を目安にメールでご連絡します。この送信で料金は発生せず、相談日時も確定しません。

お名前（必須）
返信の際にお呼びするお名前を入力してください。

メールアドレス（必須）
受付案内と日程調整に使用します。入力例：sample@example.com

相談したい内容（必須）
講座の構成／教材づくり／提供後の改善／まだ整理できていない

現在の状況（任意）
例：講座のテーマは決まったが、各回の課題が決まらない。空欄でも送信できます。

関連ページのURL（任意）
公開済みのページがあれば入力してください。未作成の場合は空欄で構いません。

送信ボタンの文言：事前相談を申し込む

2営業日という案内は、この架空例の運用条件です。実際に対応できない期間を、安心感のためだけに書いてはいけません。休日の扱い、確認先、連絡方法も実運用へ合わせます。

入力欄の中に薄く表示する例文だけを、項目名の代わりにしないでください。入力を始めた後も「メールアドレス」などの項目名が残るようにします。W3Cは、入力欄の目的を表すラベルと、欄との適切な関連付けを説明しています。参照：Labeling Controls。

エラーは、項目名と直し方をセットで伝える

「入力エラーです」だけでは、人が直す場所を探す必要があります。画面上部にはエラーの一覧を置き、それぞれの項目へ戻れるようにし、入力欄の近くにも理由を表示する設計が候補になります。

W3Cの通知の解説は、エラーの場所、内容、訂正方法を分かるように示し、成功時も結果を知らせることを扱っています。色だけに依存せず、文章でも内容を伝えます。参照：User Notification。

入力を始めた瞬間から赤字で叱られるような表示も見直してください。例えばメールアドレスを途中まで打っている間は、まだ入力が終わっていません。入力後に欄を離れた時点や送信時点など、適切なタイミングは項目と実装に合わせて確認します。

入力形式の制約自体が過剰でないかも点検します。必要のない全角・半角の制限を増やす前に、受け取れる形式や変換の方法を検討します。また、画面側のチェックだけで受付の安全性が確保されるわけではなく、サーバー側でも確認が必要です。参照：Validating Input。

訂正したら、正しく入力した欄をやり直させない

メールアドレスだけを直したのに、長く書いた相談内容まで消えていたら、それまでの作業を失います。パスワード等、保持に特別な扱いが必要な情報は別ですが、この例の通常の相談フォームでは、訂正が必要な欄へ戻り、他の入力を必要以上に失わない設計を確認します。

実装担当者へは「使いやすくする」ではなく、次のように入力から訂正までの動きで依頼できます。

1. 名前と相談内容を入力し、メールだけ@のない値にする。
2. 送信したとき、メールのエラーと入力例が分かる。
3. エラー一覧からメール欄へ移動できる。
4. 名前、相談内容、任意欄の値は残っている。
5. メールを訂正して送信すると、受付成功が確認できる。

この順は操作の試験条件であり、記事中で特定のフォームをテスト済みとしたものではありません。課金や契約が発生するフォームでは、提供されたテスト環境やテスト方法を使ってください。

送信後は、受付・日程確定・メール配達を分ける

完了画面には、今終わったことと、次の案内を短く示します。この例では相談の受付までなので、予約や契約が成立したようには書きません。

事前相談を受け付けました

受付番号：C001（架空例）

担当者が内容を確認し、2営業日以内を目安にメールでご連絡します。現時点では相談日時は確定していません。受付内容について確認するときは、この受付番号をお知らせください。

「メールを送りました」と「相手にメールが届きました」も違います。送信処理の結果しか分からない場合、配達まで確認できたように表示しないでください。メールが見当たらない場合にどこへ確認するかは、実際に対応できる連絡先とともに案内します。

通信エラーで結果が不明なときに、無条件で「もう一度申し込んでください」と表示するのも注意が必要です。すでに受け付けている可能性があるなら、受付状況を確認できる仕組みを用意し、利用するサービスの再送・重複処理に合わせて案内します。

スマホとキーボードで、同じ訂正を試す

PCで幅が足りていても、スマホで項目名が折り返して見えにくい、入力欄へ進むと説明が隠れる、エラーが画面外に出ることがあります。実際に使う幅で、入力前・入力中・訂正後を確認してください。

確認記録には、端末、ブラウザ、日時、入力した条件、止まった場所を残します。制作側が想定した動きと実際の動きが違う場合は、その差を直し、同じ入力で再確認します。

最初に直すのは、完了を妨げる具体的な不備

フォームが送れない、誤りを訂正できない、入力が消えるなら、その不備を先に直します。正常に操作できることを確認した後で、項目の必要性や説明文を見直します。項目の削減や文言の変更が申し込みを増やしたかは、同じ対象・期間条件の記録を使って後から判断します。

最初の作業は、テスト環境で一つだけ入力ミスを作り、訂正して受付まで進むことです。本番でしか試せない場合は、運営側とテスト用の受付・通知の扱いを決めてから行います。読者がどこを直せばよいか分からない箇所が見つかれば、ボタンの色より具体的な改善対象になります。間違えず入力できることと、間違えても戻れることを、両方整えていきましょう。