サイトから問い合わせが来ないのはなぜ？

ページではなく、経路を順番にたどる

何も届かないとき、人はページを書き直したくなります。見出しを変え、ボタンを大きくし、フォームの横に推薦文を置く。しかしそれは最後に変えるべきものです。完全な沈黙を生む故障はほとんどが機械的なもので、こちら側から見ると機械的な故障と説得の失敗はまったく同じ姿、つまり空の受信箱をしているからです。違いは形に出ます。説得が下手なページでも、問い合わせはときどき届きます。フォームがどこにも送信していないページは、文章がどれほど良くなろうと、永遠にちょうどゼロです。

1. フォームはどこかに送信しているか ローカルのプレビューやエディタのプレビュー枠ではなく、公開済みのURLを開き、ブラウザのネットワークパネルを開いたままフォームを送信してください。探しているのは、ページから出ていき成功ステータスで戻ってくるリクエストが一つあることです。何も出ていかないなら、そのフォームは飾りです。生成されたページでは十分によくあることなので、確認の一番目に置く価値があります。この種の欠陥の残りはAIでサイトを作るべきかにまとめてあります。
2. 送信内容に項目名は乗っているか フォームは正常に送信され、それでも空で届くことがあります。送っている入力欄に名前が付いていないからです。自分で見分けのつく文面を入力して送信し、何かが届いたかではなく、実際に何が届いたかを見てください。項目が空白の通知はマークアップの問題であって受信箱の問題ではなく、一通読むまで気づけません。
3. メールは実際に送られたか ここが飛ばされる段です。両側から見えないからです。サイトは受け渡しに成功したと信じており、あなたは不達通知を一度も見ません。メール事業者自身の送信ログを開き、テストの時刻を探してください。そこに行が一つもなければ、何も送られていません。迷惑メールフォルダをめぐる推理はすべて無駄になります。
4. それは着信したか、どこに落ちたか サイトの送信元とは別の事業者のアドレス宛てに送り、迷惑メール、プロモーション、そして何年も前に設定して忘れた振り分け規則や共通受信箱を確認してください。自ドメインから自ドメインへのメールには独特の壊れ方があるため、その経路だけを試すと、他の全員が踏んでいる問題を覆い隠せてしまいます。
5. 訪問者は本当に人間か 誰も関心がないと結論づける前に、来ているのが人間かどうかを確かめてください。ボット、リンクプレビュー、死活監視はいずれもセッションとして記録され、そのどれもフォームを埋めることはありません。だからページは賑わって見えて中身が空になり得ます。その数字を誠実に読む方法はサイトにアクセスが来ないのはなぜかにあります。

サンクスページは受領証ではない

完了画面はUIの状態にすぎません。多くの実装では、それはブラウザがリクエストを終えたから表示されるのであって、何かが保存されたり送信されたりしたからではありません。つまり問い合わせがすでに失われていても、その画面は出ます。これはテストで回避するより設計で消すべき隙間です。最も確実に欺かれるのは訪問者本人だからです。連絡したと信じて再挑戦をやめ、あなたは試みがあったことすら知りません。

私たちは顧客が公開するページを自社でホストしているので、問い合わせを書き込めなかったときに自社のエンドポイントが何を返すかを決める必要がありました。エラーを返します。保存できなかったメッセージに対して確認画面は出しません。偽の確認は、目に見える失敗より悪いからです。目に見える失敗なら、訪問者には代わりにメールを送るという選択肢が残ります。自分でバックエンドを持っているなら同じ判断をして、書き込みが成功したあとにだけお礼を言ってください。ホスト型のフォームサービスを使っているなら、テストを送り、ページが切り替わったことではなく、管理画面に記録が現れることを確認してください。

誰も見ない段：メールはそもそも出ていない

これについて最も鋭い例は、顧客のサイトではなく私たち自身のサイトにありました。1日100通という上限のメールプランを使っていて、ようやく確認した日、カウンタは99を指していました。それを超える分は事業者側で拒否されていました。不達通知は一つも出ません。不達通知は、メールがいったん受理されて送信されたことを前提とするからです。これらは受理すらされていないので、読むべき不達通知もなければ、誰かの迷惑メールフォルダに見つかるものもありませんでした。

ここから盗む価値のある細部が二つあります。拒否は403として返ってきました。認証情報が壊れていると読む種類のステータスであって、流量制限で予想する429ではありません。つまりステータスコードだけで切り分けると、間違った原因を追いかけます。さらに悪いのはこちらです。私たちの一部の経路は、見知らぬ相手が送信失敗を手がかりにどのメールアドレスが登録済みかを探れないよう、意図的に送信エラーを飲み込みます。その経路は、一度も送られていないメールについて「受信箱を確認してください」という明るいページを返し続けました。二つの細部が教えることは同じです。アプリケーションの成功メッセージは、あなたのコードが試みたことを説明しているのであって、事業者が実際に何をしたかではありません。事業者の返答を誰も見張っていなければ、両者は何日でも食い違い続けます。この件の前は送信失敗の通知がありませんでしたが、今はあります。

仕組みは動いていて、それでも静かなとき

テストの問い合わせが最後まで通るのを見届けたあとに残る説明は、ごく普通のものばかりです。そして扱いはずっと簡単になります。返ってくる反応をようやく信頼できるからです。最も多いのは、適切な人がまだ十分に来ていないというもの。公開1か月、外部リンクなしのページの読者はゼロで、フォームをいくら直しても変わりません。次に多いのは頼み方そのものです。「お問い合わせ」は、この先何が起きるか分からないまま見知らぬ相手に自由回答の会話を始めさせる行為で、見た目より大きな要求です。代わりに具体的なもの、たとえば特定の質問、価格帯、時間の選択肢を差し出すと、たいてい項目一つ分の手間で、デザイン刷新よりも数字が動きます。その先の話は訪問者を登録に変えるにはにあります。

覚えておく価値があるのは順番です。配送を検証し、次にトラフィックを読み、最後にオファーを変える。どこにも送信しないフォームの上で見出しを書き直す1時間は、原理的に成果を生みようがないからです。この順序は、私たちがAgentCeres — agentceres.comのAIグロース責任者 — を作っている考え方そのものでもあります。専門家のチームがページや投稿や連絡文を起草し、外に出るものはすべて人が承認し、顧客のメッセージを運ぶ部分は大丈夫だと決めつけずシステムが点検します。