海外向けWebサイトの納品前に問い合わせフォームを検収する際は、顧客が入力してから営業担当者がフォローできるようになるまで、問い合わせの一連の流れを実際に通して確認する必要があります。画面に送信成功と表示されても、それはフロントエンドで応答が表示されたことを示すにすぎません。メールが届いたか、管理画面に保存されたか、製品情報が揃っているかは、それぞれ個別に確認する必要があります。どこか一つでも途切れていれば、Webサイトは正常に見えても商談機会を逃すおそれがあります。
検収は、公開予定のドメインと本番設定で実施し、主要な問い合わせフォーム、海外からのアクセス環境、モバイル端末を対象にする必要があります。テスト環境での確認は事前の問題発見に役立ちますが、本番環境での検収の代わりにはなりません。ドメインの切り替え、受信者の設定、認証コード、メール送信の設定などが、最終的な結果に影響することがあります。
これら3つの結果はそれぞれ異なる段階に対応しており、相互に代替できるものではありません。送信成功は顧客が画面上で確認する結果、メール通知は営業担当者が速やかに対応するためのもの、管理画面やCRMの記録は保存、割り当て、追跡に使われます。納品前に、Webサイトが提供すると約束した機能を明確にし、合意内容に沿って一つずつ検収する必要があります。
各テストで「検収テストA—製品型番」のように異なる識別用テキストを入力し、画面の応答、通知メール、管理画面の記録を一つずつ照合するとよいでしょう。氏名、メールアドレス、問い合わせ内容、製品名、流入元ページなどの項目は一致している必要があり、特殊文字や改行も欠落してはいけません。
問い合わせをメールのみで受け取る構成では、メールの到達、失敗時の通知、異常の追跡が検収の重点となります。管理画面やCRMを備える構成では、通知に失敗してもリードを確認できるかも検証する必要があります。両者では障害発生時の復旧能力が異なります。メールが唯一の記録となる場合は、送信失敗後の対応方法を納品時に明確にしておく必要があります。

テストメールの受信後、営業担当者が実際に使用するメールアカウントでメールを開き、「返信」をクリックして、返信先が顧客の入力したメールアドレスになっていることを確認します。返信先がWebサイトシステムのアドレスになっていると、通知が時間どおりに届いていても、その後の連絡に支障が出ます。
差出人には、Webサイト運営者が送信権限を持つアドレスを使用し、Reply-Toに顧客の返信先アドレスを設定するのが適切です。訪問者が入力したメールアドレスをそのまま差出人にすると、受信側のメールシステムでの判定に影響する可能性があります。ドメインのメール認証や送信サービスの設定については、サービス提供会社に確認を依頼し、設定記録を残してもらうことができます。
メールの内容から、営業担当者が次の対応を判断できる必要があります。顧客がどの製品について問い合わせているのか、要望の内容、どのページから送信したのか、添付ファイルがあるかなどです。製品詳細ページからの問い合わせで氏名とメールアドレスしか届かない場合、営業担当者は製品について改めて尋ねる必要があり、Webサイトがすでに取得している情報を活用できません。
添付ファイル機能は個別に検証する必要があります。合意した形式とサイズのテストファイルを送信し、受信者が開けることを確認します。上限を超えた場合は、ページ上で理由を明確に説明する必要があります。メールにダウンロードリンクを記載する場合は、問い合わせ対応に必要な権限と有効期間が設定されているかも確認します。
モバイル端末での検収では、実際の入力操作を確認します。キーボード表示時に入力欄が隠れないか、国や地域を選択できるか、送信ボタンに無理なく手が届くか、エラーメッセージが顧客に見える位置に表示されるかを確認します。多言語ページでは、項目名、入力チェックのメッセージ、送信成功のメッセージがそれぞれの言語になっているかも確認する必要があります。
入力項目のルールは、海外の顧客の入力方法に合っている必要があります。電話番号欄では国際電話番号の国番号を入力できるようにし、氏名欄に日本語の氏名規則を当てはめず、住所欄で中国の省・市の入力を必須にしないようにします。必須項目は初期対応に必要なものに絞る必要があります。予算や購入数量などを必須にするかどうかは、営業プロセスに基づいて決めます。
スパム対策では、「異常な送信を防げること」と「正規の顧客が問題なく送信できること」の両方をテストする必要があります。外部の認証コードを使用する場合は、対象市場で利用できるネットワーク環境から、読み込みと認証の流れを確認します。社内オフィスのネットワークで正常に開けるだけでは、海外からのアクセス状況を判断できません。
問い合わせの各導線も、一つだけを抜き取り確認するのでは不十分です。お問い合わせページ、製品ページ、ポップアップ、広告のランディングページでは設定が異なる場合があるため、受信者、製品との関連情報、送信後の遷移先を確認します。広告用ページでは、合意した流入元パラメーターがリード記録に引き継がれ、問い合わせがどのチャネルから来たのかを後から判断できることも確認します。
正常に送信できることを確認した後、必須項目が空の場合、メールアドレスの形式が誤っている場合、入力内容が長すぎる場合、連続してクリックした場合、ネットワークが切断された場合もテストします。失敗時に顧客が状況を把握できるか、入力済みの内容が保持されるか、再送によって判別しにくい重複リードが発生しないかを確認します。
送信ボタンが連続してクリックされた場合は、重複送信を防ぐ処理、または重複を明確に識別する方法が必要です。リクエストの処理中は、ボタンに処理状況を表示する必要があります。タイムアウトが発生した際に、安易に成功と表示してはいけません。メールやCRM連携の失敗については、サービス提供会社に管理された環境での検証を依頼し、該当するテストの記録を提示してもらうことができます。
マーケティングのコンバージョン計測も個別に確認する必要があります。送信ボタンをクリックしただけでは有効な問い合わせが発生したことにはなりません。入力チェックに失敗した場合やインターフェースでエラーが発生した場合に、成功コンバージョンとして計上されないことを確認します。計測イベントは合意した有効な受信結果に対応させ、成功ページの再読み込みや連続クリックによって二重計上されないかも確認します。
最終検収記録には、テストした導線、端末、言語、テスト日時、受信結果、管理画面の記録、異常時の処理結果を明記します。問題を修正した後は、該当する導線を再テストします。特に、送信に失敗したのに成功と表示される、メールが届かず記録も残らない、製品情報が欠落する、主要市場から認証を完了できないといった問題は、解決してから該当項目に合格の署名を行う必要があります。
納品時には、受信者の変更方法、リードの閲覧権限、異常の確認方法、障害対応の連絡先も受け取る必要があります。これにより、営業担当者が一定期間問い合わせがないことに気付いた際、送信記録、通知状況、リードの割り当てを順に確認し、問題の発生箇所を特定できます。
関連記事
関連製品


