問い合わせにつながるWebサイト改善｜計測設計・数値の読み方・30日間の実践手順
発信：BE FREE
アクセス数だけでは、問い合わせが増えない原因を特定できません。訪問から送信完了、商談化までを分けて計測し、改善の優先順位を決める方法を、具体的な数値例と30日間の実践手順で解説します。
最初に「成果」と「途中の行動」を分ける
サイトの成果を問い合わせに置くなら、「問い合わせボタンが押されたこと」と「問い合わせを実際に受け付けたこと」を別々に扱います。クリックが多くても、入力エラーや通信失敗で受付まで進んでいない可能性があります。資料請求、電話、LINEなど複数の窓口がある場合も、それぞれの行動を分けて記録します。
一枚の計測メモに、①事業上の目的、②成果の定義、③発生を確認する場所、④重複の扱い、⑤担当者を記入してください。例えば「新規法人からの相談を増やす／受付システムで受理した相談／成功応答の直後／同一送信は一件／営業責任者が月次確認」という形です。採用応募や営業売り込みは、受け付けた問い合わせの内訳として分けます。
さらに「商談になった相談」を営業側で管理します。Web上の行動が増えたのに商談が減ったなら、集客対象や訴求と提供サービスがずれているかもしれません。ページ内の数字だけで成功を判断せず、問い合わせ内容の質まで確認できる体制を先につくります。
訪問から受付までの流れを計測する
最初は、流入したページ、サービス詳細の閲覧、相談ボタンのクリック、フォーム入力開始、受付成功の五段階を整理します。全ページに多数のイベントを追加するより、「次の行動へ進めない場所」を判断できる最小限の計測から始めます。ボタンの位置を調べる場合は、ヘッダー・本文・フッターなど区別できる名前を付けます。
GA4の拡張計測機能には、入力への最初の操作を表すform_startと、フォーム送信を表すform_submitがあります。ただし、これらの定義だけで自社の受付処理が成功したと判断しないでください。自社フォームの動作を確かめ、サーバーが受付成功を返した段階で別の成果イベントを記録する設計を検討します。
独自にinquiry_acceptedなどの名前を使う場合は、それが自社で定義したイベントであることを計測仕様書に残します。送信ボタンの連打、完了画面の再読込、戻る操作で二重計上しないかも確認します。氏名、メールアドレス、相談本文などの入力内容は解析イベントに載せず、分析に必要な分類だけで設計します。
比率を出す前に、分母と単位をそろえる
「問い合わせ率」という言葉だけでは、人によって計算が変わります。月間セッション数を分母にするのか、サービスページを見た利用者数にするのか、フォーム開始件数にするのかを明記してください。セッションとイベント件数は異なる単位なので、割り算の結果をそのまま「訪問者の何％」とは表現できません。
仮に同じ月に1,000セッション、フォーム開始50件、受付成功20件だったとします。受付成功件数÷セッション数は2％、受付成功件数÷フォーム開始件数は40％です。前者は集客から受付まで、後者はフォーム周辺を評価する指標です。ただし同じ人の複数送信や、開始と送信が別期間にまたがるケースがあるため、厳密な到達率を見たい場合は同じ利用者・同じ流れを追う分析が必要です。
営業確認で20件のうち8件が対象サービスの有効な相談、4件が商談になったなら、その内訳も並べます。2％だけを上げる施策より、対象外の相談を減らして有効相談を増やす方が、事業に役立つ場面もあります。目標値はこの実情を踏まえて決め、他社の平均値を無条件で当てはめないことが大切です。
数字の落ち方から改善箇所を絞る
サービスページの閲覧自体が少なければ、トップページからの案内、記事からの関連リンク、検索で表示されるページなどを確認します。閲覧はあるのに相談ボタンが押されないなら、対象顧客、対応範囲、実績、料金の考え方、相談後の流れが伝わっているかを読み直します。ここで入力欄だけを変えても、主要な原因に届かない可能性があります。
フォーム開始は多いのに受付が少ない場合は、必須項目の多さ、スマートフォンでの入力、エラーの説明、送信後の通信処理を点検します。「任意にすれば入力が楽になる項目」と「受け付けるために必要な項目」を分け、不要な質問を削ります。電話番号が本当に初回受付に必須なのか、といった具体的な判断が必要です。
受付後に商談が進まない場合は、サイトの表現だけでなく、初回返信までの時間、営業担当への引き継ぎ、対象外案件の比率も確認します。Web、フォーム、営業対応を別々の担当者が管理していても、同じ表で結果を振り返ると責任の押し付け合いを避けやすくなります。
計測が正しいか、公開前にテストする
テストは通常送信だけで終わらせず、必須項目の未入力、不正なメール形式、通信失敗、二重クリック、完了画面の再読込、スマートフォンからの送信を試します。それぞれで「受付されるべきか」「成果イベントが出るべきか」を先に書き、実際の受付記録と照合してください。
問い合わせ種別や複数フォームがある場合は、種別ごとのイベント分類も確認します。例えば資料請求と個別相談を同じ成果として合計すると、資料請求キャンペーンの影響で相談が増えたように見えることがあります。テスト送信には社内で判別できる印を付け、営業実績には混ぜない運用を決めます。
解析ツールの値と受付台帳は常に一致するとは限りません。同意状態、計測の遮断、端末やセッションの違いなどを踏まえ、実際の受付件数は受付側の記録でも確認します。差が出たときは数値を無理にそろえるより、どの仕組みが何を数えているかを調べます。
変更は一つの仮説として記録する
改善メモは「観察した事実／原因の仮説／変更内容／見る指標／確認期間」の五項目で十分です。例として「スマホでフォーム開始後の離脱が目立つ／任意情報を必須にしている可能性／初回受付に不要な項目を任意へ変更／受付成功と相談内容の不足／次の一か月」を記録します。
一度に広告、見出し、価格、フォームを全部変えると、何が効いたのか判断しにくくなります。少ないアクセスで厳密な比較が難しい場合は、無理にA/Bテストで勝敗を出さず、利用者の操作確認や営業ヒアリングも合わせて判断します。月2件が4件になっただけで「改善率100％」を強調するより、件数と期間をそのまま示す方が実態を伝えられます。
前後比較では曜日、広告出稿、季節性、キャンペーン、計測変更も記録します。問い合わせが増えても広告費が倍になっているなら、ページの変更だけが理由とは言えません。集客条件をそろえられない場合は、結論を仮説のまま残し、次の確認につなげます。
最初の30日で取り組むこと
1週目は、成果の定義と担当を決め、計測メモを作り、受付台帳との照合方法を整えます。2週目は、フォームの正常・異常動作をテストし、集計の抜けと重複を直します。計測が崩れたままデザイン改善を始めると、変更前後の比較ができなくなります。
3週目は、流入から受付までの数字と実際の相談内容を合わせ、最も影響が大きそうな問題を一つ選びます。4週目は、修正の実施と記録、次回確認日までを決めます。これは作業計画の例であり、30日で十分な問い合わせが集まるという意味ではありません。件数が少ない事業では、観測期間を延ばします。
月次報告は「件数と内訳」「計測上の注意」「今回変えたこと」「次に確かめること」を一枚にまとめます。担当者が忙しくても続けられる粒度に落とし、毎月のアクセス報告で終わらないことが、改善を積み重ねる第一歩です。