問い合わせフォームが届かないときの確認順送信完了と受信を切り分ける

お客様から「送ったのに返事がない」と言われたら、公開中の問い合わせ窓口を確保してから、テスト送信を一件だけ行います。画面の完了表示、フォーム側の記録、事業者が受け取る通知、お客様側の自動返信を別々に追うと、誰に何を確認すればよいかが分かります。テストは運用者の許可を取り、顧客情報の代わりに識別番号と受信管理できるテスト宛先を使います。

問い合わせを受けられる経路を一時的に確保する

返信を待つお客様が次に取れる行動を、フォームの手前に掲示します。電話で受けられる場合は、連絡先と受付時間、休日の扱いを一緒に載せます。別の窓口を使うときは、そちらで受付から返信まで担当できることを事前に確かめます。窓口を増やしすぎると同じ用件が重複するので、受付側で照合する担当を一人決めておきます。

案内文の例は「現在、フォームからのご連絡を確認できない場合があります。お急ぎの場合は平日の受付時間内にお電話ください。すでに送信済みの場合は、送信日とご用件の種類をお知らせください」です。相談の詳しい内容や添付書類を再送してもらう前に、受信記録を検索します。臨時の案内を出した時刻と掲載したページを控えると、復旧後に撤去漏れを防げます。

受付メールが一人の個人アドレスに届く構成なら、担当者不在で見落とした可能性も先に確認します。共用受信箱へ切り替えるときは、担当範囲と閲覧権限をそろえ、私物のメールへ広く転送する運用は避けます。

引き継ぐ担当が別の場所で作業する場合は、復旧報告を受け取る方法も決めておきます。障害中のフォームを社内の報告先として使うと、同じ箇所で連絡が止まります。電話や内部チャットなど、正常に届く手段を一つ使い、保留中の問い合わせ件数、次の確認時刻、判断をする人を共有します。案内を掲示した人と撤去する人が同じでない場合は、どちらも復旧の結果を読める場所に置きます。

テスト送信の通過点を記録する

ブラウザーで公開ページを開き、件名や本文に「確認 T01」のような一意の印を付けます。送信前後に同じ時間帯の記録を見られるよう、時刻、タイムゾーン、ページURL、端末、識別番号をメモします。再送するたびに新しい番号を使えば、後から到着した最初の通知を二回目の成功と取り違えにくくなります。添付の有無を試すなら、内容に個人情報を含まない小さい検証用ファイルを用意します。

確認地点	見るもの	残す結果
入力と送信	ボタンの動きと入力エラー	送信操作が成立したか
完了表示	画面文言と表示時刻	画面が報告した状態
受付記録	保存機能がある場合の一覧	同じ識別番号が存在するか
担当者通知	指定の受信箱や隔離領域	到着先と時刻
利用者返信	テスト送信者の受信箱	返信の有無と内容

受付記録を保存する機能がない仕組みでは、その欄に「利用できない」と書き、管理者が見られる送信処理の記録やテスト通知で代用します。受付一覧がある場合も、保存と通知は別の状態として扱います。公開サービスの管理権限を持たない人は、手元の時刻と番号を運用者に渡し、設定画面へのアクセスは担当者に任せます。

ブラウザーで架空のフォームを試したところ、T01は受付エラーで記録も通知も残らず、T02は完了表示と受付記録があって通知だけが欠け、T03は両方の記録が残りました。通知と自動返信は検証用の記録で、実際のメール配送には接続していません。実際のフォームを確認する場合は、同じ項目に自分で観測できた結果を入れ、参照できない項目は未確認のまま残してください。

問い合わせが送信画面から事業者に届くまでの確認経路 — ブラウザーと検証用の記録で確認した3ケースです。各項目は本文でも確認できます。

受信できない場所に合わせて確認する

受付側に記録が見つからない場合

入力が完了した端末で、必須欄、添付の種類・容量、送信時のエラー表示を確認します。以前使えたフォームなら、ページ公開、URL変更、外部フォームの埋め込み更新、スパム対策の変更と発生時刻を照合します。失敗時に入力が失われる場合は、原因調査と並行して代替窓口へ案内します。開発者向けの記録が必要なら、運用担当者が時刻と識別番号を基に取得します。

受付側の記録がある場合

事業者宛と送信者宛の通知先を分けて確認します。事業者宛であれば、宛先のタイプミス、受信ルール、迷惑メール、隔離、転送、共用受信箱の容量を順に見ます。お客様への返信だけが届かないなら、入力されたアドレス、返信設定の有効状態、受付メールに表示する返答予定を確認します。個別の受信先で起きる場合は、メール管理者が配送や拒否の記録を照合します。画面に表示された利用者名やメッセージ本文を、そのままサポート窓口へ渡す必要はありません。

端末を替えると症状が消える場合は、元の端末で開いていたURLやブラウザーを記録します。時間帯や操作をそろえずに別の端末で成功すると、問題が直った時刻と発生条件を混同します。外部の受付へ移動する仕組みでは、公開ページにある埋め込みやリンクの先と、受付側の契約・設定をそれぞれ確認します。

設定値を確認しサポートに伝える

フォームを提供する仕組みの公式手順を開き、「担当者への通知」「送信者への返信」「メールの差出人と返信先」の設定を別々に読みます。例えば Contact Form 7 の公式解説には、通常の通知用メールと追加のメール設定が別に記載されています。SIRIUS2でフォームを使う場合は、利用中のフォーム機能とサーバーに必要な環境を公式マニュアルの該当箇所で照合してください。サービスごとに記録の保存、送信方式、操作権限が変わります。

問い合わせ文は「日本時間の○時○分、対象ページのテスト番号 T02。画面は受付完了、受付一覧にT02あり。担当者通知は未着。直前に通知先を変更。テスト宛先は担当者側で確認済み」のように、観測できた事実と変更履歴を短く書きます。送信ドメイン認証の設定に進む場合は、ドメインとメールの管理担当へ引き継ぎます。既存のDNS設定や認証情報を、根拠の確認なしに差し替えると他の連絡経路にも影響します。

調査を依頼したあとは、元の設定と変更後の値が分かる記録を残します。例えば通知先を変える場合、既存の宛先を消す前に新しい担当が受信できることを確認し、両方に送られる間は受付番号で照合します。設定を一度に複数変えると、改善の原因も、別の症状が起きたときに戻す箇所も分かりにくくなります。

修正後に入口から受信まで再試験する

変更を反映したら、最初に失敗した公開ページで正常送信を再試験します。別番号を使い、スマホとPCで入力、完了表示、担当者への到着、送信者への自動返信を照合します。意図的に必須欄を空にしたときのエラーと、修正後に続けて送れることも確認します。二度押しや再読み込みで通知が重複しないかは、テスト先で確認できる場合に追加します。

復旧後は一時窓口の案内を外し、受付先の担当へテストの記録と再発時の確認先を渡します。調査用のテストデータは、保存の必要性と閲覧できる人を運用ルールに沿って決めます。送信後の案内文に返信予定や連絡先を置くと、次回の行き違いに備えられます。問い合わせページの案内文と入力例の見直しは、公開側の受付が落ち着いてから進めると変更が混ざりません。

最後に、問い合わせの取りこぼしが疑われる期間を記録し、照会が来たときに誰が確認するかを共有します。未着の連絡が残っている可能性がある場合は、保存済みの受付と返信の状況を照合します。過去のすべての送信を復元できるとは限らないので、参照できた期間と情報の範囲を担当者間でそろえておきます。