アクセスはあるのに問い合わせが来ないときの確認手順｜計測・内容・導線・受付

アクセスはあるのに問い合わせが来ないとき、最初からボタンの色や広告費を変えると、原因と関係のない作業に時間を使うことがあります。まず確認したいのは、相談したい人が来ているか、比較に必要な情報を読めるか、問い合わせを送れるか、送った内容が担当者へ届いているかです。

この記事は、企業サイトやサービスサイトの問い合わせを増やしたい経営者・Web担当者に向けた診断ガイドです。Googleの計測資料と英国政府の公開例を参照し、数字と画面と受付記録を組み合わせる手順を説明します。公開事例と、判断の練習に使う架空の会社・数値例は区別して掲載しています。

目指すのは、改善案を大量に出すことではありません。「今確認できる事実」「まだ分からないこと」「次に直す箇所」を分けることです。最後の相談メモまで使えば、制作会社へ調査や修正を頼む際にも、対象と確認方法を具体的に伝えられます。

1. 「問い合わせがない」の意味を、受付と成果に分ける

どの相談を増やしたいかを決める

問い合わせには、新規の見積もり、既存顧客からの連絡、採用への応募、取材、営業メールなどが混在します。すべてを一つの件数にすると、増やしたい相談が増えているか分かりません。まず、今回の改善対象を「対象地域の法人からの見積もり相談」のように定めます。分類が細かすぎて担当者が記録できない場合は、新規相談、既存対応、その他程度から始めても構いません。

次に、フォーム、電話、メール、予約サービスなど、受け付ける窓口を列挙します。フォームの送信だけが少なくても、電話で相談が入っている可能性があります。反対に、フォームの通知は多くても営業や迷惑送信ばかりなら、事業上の成果とは異なります。件数と相談内容を分けて見る準備が必要です。

クリック、送信、受信、商談を区別する

「問い合わせボタンが押された」「完了画面が表示された」「担当者が相談を受け取った」「商談に進んだ」は、それぞれ異なる出来事です。ボタンのクリックを送信完了として数えると、途中で入力をやめた人まで問い合わせに含めてしまいます。送信完了の表示があっても、通知先やメール配信に問題があれば担当者が気づけない場合があります。

受付の確認では、日時、窓口、相談の種別、対応状況などを必要な範囲で記録します。解析画面へ顧客の氏名やメールアドレスを渡して照合するのではなく、受付側の管理記録と、個人を特定しない集計を分けて扱います。商談にならなかった理由も、サイトの問題なのか、条件が合わなかったのかを分けて確認します。

英国政府の公開例から、完了の定義を見直す

英国政府のデザインブログは、2015年の計測方法の見直しで、手続き後の別ページへの移動だけでは完了を適切に測れない問題を紹介しています。また、完了できた人だけに満足度を尋ねると、途中で困った人の意見を取りこぼすことも説明しています。これは当時の政府サービスの公開事例です。

企業サイトへの応用としては、計測しやすいクリックを本来の成果と置き換えないこと、送れなかった人の操作も調べることが挙げられます。同事例は問い合わせが増える倍率を示すものではありません。現在の完了率の手引きも、開始と終了を明確にした手続きを対象にしています。その考え方を参考にしつつ、自社の相談に合う定義を作ります。

2. 改善する前に、計測が何を数えているか確認する

イベント名だけで送信成功を判断しない

GA4の拡張計測機能の公式説明には、フォームの操作開始を表すform_startと、送信時のform_submitがあります。これらは利用状況を調べる手掛かりですが、自社のフォームでどの操作をしたときに記録されるかは確認が必要です。入力エラー、戻る操作、再送信、完了ページの再読み込みなどで、意図しない数え方をしていないか点検します。

Googleは見込み客の獲得を表すgenerate_leadという推奨イベントも定義しています。ただし、名前を付けただけで実際の受付が保証されるわけではありません。自社で決めた成功条件に合わせて記録し、重複がないかを確認します。イベントの発生とメールの受信確認は別に実施します。

割合の分母と対象期間を揃える

問い合わせ率を計算するときは、何で割っているかを書きます。サイトの訪問回数、閲覧した人数、フォームの開始件数では、割合の意味が違います。同じ人が何度も訪問したり、別の日に送信したりすることもあるため、異なる指標を並べた表をそのまま一続きの経路と解釈しないようにします。

GA4のファネル探索の説明では、途中の段階から入れる方式と最初の段階から入る方式が区別され、指定した順序で進んだ利用者が数えられます。単に各ページの閲覧数を引き算したものとは異なります。比較表には期間、段階、順序、対象者の条件を残し、設定を変えた前後の数字は別の条件として扱います。

欠測と社内の操作を確認する

解析に記録される範囲は、タグの設置、利用者の同意状態、ブラウザの設定などの影響を受けます。記録がないことだけで、誰も操作していないとは断定できません。サイト変更の前後でタグが外れていないか、特定のページだけ計測方法が違わないかを確認します。数字が急変した場合は、集客の変化と計測の変化を分けて調べます。

社内からの確認や制作会社の試験も、少ないアクセスのサイトでは数字へ影響します。除外の設定や試験日の記録を確認し、実際の相談と混ぜないようにしましょう。手元の数字に欠測や混在がある場合は、分からない範囲を明記します。推測で件数を埋めるより、以後の計測を揃える方が次の判断に役立ちます。

3. 来ている人と入口ページが、依頼内容に合っているか調べる

検索語と問い合わせたいサービスを見比べる

サイト全体のアクセスが増えていても、増えた理由が採用情報や用語解説なら、新規の見積もりが同じ割合で増えるとは限りません。どの記事が入口になり、どのサービスを探す人が来ているかを確認します。検索語から目的を完全には断定できませんが、自社が受けたい相談との違いを考える材料になります。

Search Consoleの検索パフォーマンスレポートでは、検索語やページなどの切り口でクリックや表示を確認できます。Google検索での表示・クリックの記録と、サイト内の行動を扱うアクセス解析は別の資料です。両者の件数が同じになる前提で比較せず、それぞれの観測範囲を意識して使います。

入口の問いに答えてから、次の案内を置く

説明用の架空例として、業務用設備の点検会社が「設備の異音の原因」を解説しているケースを考えます。読者はまず原因の見分け方を知りたいので、冒頭から契約の申込みだけを勧めても判断材料が足りません。記事で確認できる範囲と専門家への相談が必要な状況を説明し、対応する設備、点検の流れ、相談先へつなぎます。

記事のテーマとサービスが関係していなければ、無理に問い合わせへ誘導する必要はありません。関連する解説を案内する方が自然な場合もあります。入口ページごとに、読者が知りたいこと、読んだ後に残る疑問、それに答えるページを一行ずつ記録すると、追加するリンクを選びやすくなります。

対象外の地域や条件を先に伝える

対応地域、対象業種、最低発注量、受付できる内容などは、比較の早い段階で確認できるようにします。問い合わせの総数を増やすために条件を曖昧にすると、対象外の相談への対応が増える可能性があります。自社が対応できる依頼が届くことと、単にフォームの送信数が増えることを分けて考えます。

条件を読んで問い合わせなかった人を、すべて失敗と数える必要もありません。架空の点検会社が対応外の設備を明記したことで、対象外の相談が減る場合も考えられます。そのときは件数だけでなく、対応可能な相談の割合や、確認のための往復が減ったかを見ます。個別の成果は、実際の受付記録で確かめます。

4. 比較に必要な情報が、サービスページに揃っているか確かめる

対象・作業範囲・料金の決まり方を示す

「丁寧に対応します」「最適な提案をします」だけでは、初めての人は自分の依頼が対象か分かりません。どんな状況の人へ、何を行い、何が成果物として渡されるのかを説明します。固定価格を出せない場合も、金額が変わる条件、見積もりに必要な情報、追加費用が発生する場面を示せます。

架空の設備点検会社なら、点検の対象、訪問前に必要な情報、当日行う作業、報告の形式、修理は別見積もりになるかを整理します。値下げより先に説明不足を調べる理由は、価格が高いのか、含まれる仕事が分からないのかで改善方法が違うためです。問い合わせで繰り返し聞かれる条件は、掲載候補として記録します。

制作・支援事例は、確認できる範囲で載せる

事例には、対象となる仕事、担当した工程、実施内容を具体的に載せます。写真や画面があっても、それが自社の担当部分なのか、公開後に変更されたものなのかが分からなければ比較しにくくなります。成果の数値を載せる場合は、期間、対象、測定方法を確認できる範囲で説明します。

公開できない案件が多い場合も、経歴や成果を作り足す必要はありません。自社の進め方、確認項目、納品物の説明、公開可能な範囲のサンプルを示す方法があります。お客さまの言葉を掲載する場合は、取材・編集・掲載許可の整理方法を参考に、発言と編集した要約を混同しないようにします。

相談した後に何が起きるかを説明する

問い合わせをためらう理由として、すぐに契約を求められそう、何を用意すればよいか分からない、費用がかかるか不明、といった疑問を検討します。実際に対応できる範囲で、初回に確認すること、返信の目安、相談の費用、契約へ進むまでの流れを説明します。自社で守れない短い返信時間を約束することは避けます。

フォームの直前だけでなく、サービスを読んでいる途中でも流れを確認できると、判断材料を探す負担を減らせます。必要な項目を一度に増やすのではなく、受付担当がよく聞かれる質問を挙げ、現在のページで答えが見つかるか確認します。実際の質問がない場合は仮説として扱い、操作の観察や相談内容から見直します。

5. 数字で見えた疑問を、画面と操作で確かめる

入口から相談までを、スマートフォンでたどる

検索や紹介で開かれるページから、対象サービス、事例、費用、相談へ進む道筋を実機でたどります。メニューにリンクがあるかだけでなく、名称から行き先を予想できるか、長い文章の後でも次の行動が分かるかを確認します。画面に固定したボタンや案内が本文・入力欄を隠していないかも見ます。

クリックの回数が少ないだけで使いやすいとは限りません。一つの画面へ情報を詰め込みすぎると、選ぶことが難しくなる場合があります。ページの役割とつながりを整理したい場合は、サイトマップとページ構成の作り方を使い、各ページで答える疑問と次の案内を確認してください。

特定の端末でだけ問題が起きる場合は、端末・ブラウザ、開いたURL、操作の順番、表示されたメッセージを記録します。「スマホで動かない」だけでは、修正担当が同じ状態を再現できないことがあります。個人情報を伏せた画面と再現手順があると、表示崩れ、通信の失敗、入力条件の問題を分けて調べやすくなります。

実際に画面を点検するときは、問い合わせ導線のチェックリストと観察メモを使ってください。入口からサービス・事例・メニュー・連絡先をたどり、迷った操作と修正後に確かめることを記録できます。原因を調べるための計測と、利用者が操作できるかの確認を組み合わせて進めます。

初めて使う人に、答えを教えず操作してもらう

GOV.UKのユーザビリティテストの手引きは、利用者が具体的な課題を進める様子を観察する方法を説明しています。自社サイトなら「この設備が点検対象か調べ、相談前に必要な情報を確認してください」のように、実際の目的に近い課題を用意します。「右上のボタンを押してください」と操作を教えると、見つけられるかを調べられません。

止まった場所、探した情報、言葉の解釈を記録します。参加者の能力を採点するのではなく、ページ側の分かりにくさを見つけるための確認です。少人数の観察で分かった問題を、全訪問者が同じ割合で経験しているとは扱いません。録画や個人情報を扱う場合は、説明と同意、保管方法を先に決めます。

発言・行動・推測を別々に記録する

「料金の説明を探していた」は観察した行動、「高そうなのでやめた」は本人の発言として記録できます。一方、「青いボタンだから押さなかった」は、確認できなければ推測です。アクセス解析やヒートマップで操作位置を見ても、理由まで直接分かるわけではありません。観察記録に事実と仮説の欄を分けます。

6. フォームから受信・返信までを一続きで点検する

必要な入力と、後から聞ける情報を分ける

フォームの項目は、少なければ必ずよいわけではありません。受付や対応可否の確認に必要な情報が不足すれば、何度も聞き返すことになります。各項目について、何の判断に使うか、初回に必要か、担当者とのやり取りで後から聞けるかを整理します。項目数だけを基準にした一律の削減は避けます。

入力例、必須と任意、選択肢の違い、エラーの直し方も点検します。スマートフォンで入力欄が隠れたり、戻る操作で内容が失われたりすると、項目が少なくても負担になります。具体的な画面の確認には、問い合わせフォーム改善のガイドを使い、入力・エラー・受付までの動きを調べます。

完了表示と通知先の受信を別々に確認する

担当者と予定を合わせた試験では、試験だと分かる内容で送信し、完了の表示、管理側の保存、通知メールの受信、受付後の担当を確認します。試験の日時と識別方法を先に決め、実際の問い合わせや営業記録へ混ぜないようにします。管理側へ届くまでのどこで問題が起きたかを切り分けるため、画面と受信箱の両方を確かめます。

届かない場合は、通知先の設定、迷惑メール、管理側の記録などを順に調べます。原因を確認せず、フォームを再作成したり、メール配信設定をまとめて変えたりしない方が調査しやすくなります。送信内容には個人情報が含まれるため、調査を依頼するときは必要な証拠だけを安全な方法で共有します。

自動返信の後に、人が回答できているかを見る

自動返信が届いたことと、担当者が質問へ回答したことは別です。受付後に誰が確認し、誰が回答するか、休業日や担当不在のときはどうするかを決めます。複数の窓口を用意している場合は、同じ相談への重複対応や、担当が決まらない状態を避けるための記録も必要です。

返信の目安や受付文面を整える場合は、自動返信メールの作り方を参照してください。問い合わせの総数が変わらなくても、対応可能な相談に返信できていなかった問題を解消する価値はあります。受付の不具合と集客の不足を、同じ改善案で扱わないことが大切です。

7. 改善の優先順位は、件数・影響・確かさで決める

割合だけで、最も悪い場所を決めない

以下は同じ定義と期間で経路を追えたと仮定する、説明用の架空例です。サービス閲覧者が200人、フォームへ進んだ人が20人、送信した人が4人なら、段階間の割合は10％と20％です。しかし、この二つの割合だけでは、ボタンとフォームのどちらが原因かは分かりません。対象外の読者や、別の窓口へ進んだ人も調べる必要があります。

フォーム到達を30人へ、送信の割合を同じ20％と仮定すれば6人という計算はできます。ただし、増えた10人の性質まで同じとは限らないため、これは改善効果の予測ではありません。数式で作れる仮定と、実際の変更後に観測した結果を区別しましょう。

不具合、説明不足、検証したい案を分ける

送信できない、リンク先が存在しない、古い電話番号が載っているといった確認済みの不具合は、見た目の好みより優先して扱います。次に、対応範囲や費用条件など、意思決定に必要な情報が不足している箇所を整理します。ボタンの表現や配置など複数案を比べたい変更は、仮説として記録します。

改善候補には、困る利用者の範囲、問題の影響、根拠、作業量を添えます。大きな閲覧数のページでも、問題が推測だけなら先に観察する方法があります。逆に、閲覧数が少なくても送信ができない不具合なら、放置せず調査します。数値に一律の点数を付けるより、なぜその順番にしたかを説明できる状態にします。

変更後に比べる条件と見直し日を決める

変更前後を比べる際は、期間の長さ、曜日、広告、キャンペーン、季節、営業状況の違いを記録します。同じ日に料金、原稿、広告、フォームをまとめて変えると、どれが影響したか分かりにくくなります。関連する修正をまとめる必要がある場合も、変更した範囲と理由を残します。

問い合わせが少ないサイトでは、1件増えただけで割合が大きく動きます。一定日数が過ぎたことだけで効果を断定せず、確認できる件数と観測条件を見て判断します。数字の評価を待つ間も、リンクが正しい、説明が読める、試験で送受信できるといった動作の確認はできます。動作確認の合格と集客効果の確定は分けて記録します。

8. 制作会社へ、調査と修正の内容を具体的に伝える

分かっている事実と、調べてほしいことを渡す

「問い合わせを増やしたい」だけでなく、どのサービスの相談を、どの窓口で増やしたいかを伝えます。現在のURL、気になる期間、見ている計測項目、実際の受付件数、よくある質問をまとめます。分からない数字は分からないままで構いません。取得できないデータを埋める作業から必要なのかを相談できます。

調査の納品物と、修正の範囲を決める

調査だけを頼むのか、原稿作成や実装まで頼むのかを分けます。調査結果には、確認した事実、優先順位、その理由、修正案、追加調査が必要な点を求めます。アクセス解析を見た感想だけで終わらず、対象ページのどこをどう確認したかが分かる報告にしましょう。

修正を依頼する場合は、変更前後の内容、公開する担当、確認する人を決めます。作業の指示をまとめる方法は、ホームページの修正依頼ガイドで整理しています。計測の追加や外部サービスの導入が必要な場合は、目的、取得情報、継続費用、運用担当も個別に確認します。

一度の診断を、次の改善につながる記録にする

改善後は、実施した日、変更箇所、動作確認、観測した結果、次に調べることを残します。効果がまだ分からない場合も、確認できた不具合を直したことや、未計測だった段階を把握できたことは記録できます。反対に、問い合わせが増えても広告や営業活動の変化が重なっていれば、サイト修正だけの成果と断定しません。

Acquaへ相談する際は、お問い合わせからサイトのURLと、増やしたい相談、現在困っていることをお知らせください。計測・掲載内容・操作・受付のうち、どこを確認する必要があるかを整理します。調査や修正の範囲は現状を確認して決め、公開後に何を見直すかまで共有します。