問い合わせ率を見直すときは、ボタンの色から変える前に「どのページを見た人の、何を問い合わせとして数えるか」を決めます。対象と期間をそろえれば、小さな変更の前後を確かめられます。ただし、率が動いただけで変更の効果が証明されたとは限りません。
この記事の10項目は、成果が出ると決まった施策ではなく、実際の閲覧経路やフォームの不便さに応じて選ぶ点検候補です。問い合わせが少ない理由を広く整理したい場合は、先に問い合わせまでの経路を点検する記事をご覧ください。
最初に、問い合わせ率の分母と分子を決める
たとえば「対象のサービスページを見たセッションのうち、同じセッションでフォーム送信に成功したセッションの割合」と決めます。この定義なら、問い合わせ率は「送信成功セッション数 ÷ 対象ページ閲覧セッション数 × 100」で計算します。仮に閲覧100セッション、送信成功2セッションなら2％という計算例であり、実績値ではありません。閲覧数と送信件数、人数とセッション数など、異なる単位を混ぜないことが大切です。電話やメールを含めるなら別の受付経路として記録し、どこまでを一つの問い合わせとみなすかを社内で合わせます。
| 見る数字 | 数え方の例 | 確認したいこと |
|---|---|---|
| 対象ページの閲覧 | そのページを見たセッション数 | 流入元・端末・対象期間は同じか |
| フォーム到達 | 対象ページ経由でフォームを開いたセッション数 | 途中の案内やリンクで止まっていないか |
| 送信成功 | 受付完了を確認したセッション数 | テスト送信・重複・迷惑投稿を分けたか |
| 対応できる相談 | 受信後に内容を確認した件数 | 単なる送信増と有効な相談を混同していないか |
Google Analyticsの推奨イベント一覧では、フォームや情報提供の依頼を送る行動にgenerate_leadが挙げられています。キーイベントのレポート説明も、重要な行動を計測しているかを確認する方法を示しています。実際の受付が完了した時点で正しく記録されるかを試し、管理画面の数字だけでなく受信・対応記録とも照らしてください。未設定なら「計測できていない」と記録し、値を推測で補いません。
一つのページと一つの問題を選ぶ
対象ページを一つ決め、スマートフォンとPCの両方で「情報を読む→相談先を見つける→フォームを送る」をたどります。お客様から繰り返し聞かれる質問、社内で受け付けた相談、ページ内の案内不足を照らし、最も確かめたい問題を一つ選びます。アクセス数が少ないというだけで文面やデザインを原因と決めつけないため、数字の見方はアクセス数を見直す順番にも分けてあります。
変更前に、対象URL、日付、端末、流入元、対象ページの閲覧、フォーム到達、送信成功、受信した相談を控えます。季節要因、広告、キャンペーン、サイト障害などが同時に変わっていればメモします。極端に少ない件数では比率が大きく動きやすいので、「改善した」と早合点せず、実際の相談内容も見ます。
ページの説明を見直す小さな改善1～4
1．冒頭で「誰の、何の相談か」を明確にする
冒頭が抽象的な理念だけなら、対象者、扱うサービス、相談できる内容を短く示します。「短期で売上を上げる」など確認できない結果は書きません。変更後は対象ページからサービス説明や問い合わせ先へ進んだかを見て、実際の質問が説明と合うか確かめます。
2．問い合わせ前に必要な条件を探しやすくする
対象地域、対応範囲、相談前に用意する情報など、実際に案内できる条件を見つけやすい位置に置きます。価格や納期など確定していない条件を作らず、未定なら相談時に何を確認するかを書きます。読者が同じ質問を何度もする箇所から手を付けます。
3．実在する根拠だけを近くに置く
確認済みの制作例や提供手順があれば、相談ボタンの近くから参照できるようにします。許可のない顧客名、架空の声、未検証の成果数字で補強しません。説明を追加したあとも、関連情報への移動だけでなく問い合わせの中身を確認します。
4．よく聞かれる質問を一つだけ解消する
電話やメールで繰り返し聞かれる質問があれば、ページ内の該当箇所に答えを追加します。FAQを大量に増やす前に、その答えが現行の提供条件と合っているか確認します。質問がなくなっただけで相談が増えるとは限らないので、ほかの相談へ進めているかも見ます。
相談への導線を見直す小さな改善5～7
5．ボタンの文言を行き先に合わせる
「詳しくはこちら」だけでは、次の画面がサービス説明なのかフォームなのか分かりません。実際の行き先に合わせて「制作内容を見る」「相談する」などと書き分けます。色や丸みだけを成果の理由と決めつけず、まず言葉と行き先の一致を確かめます。
6．必要な位置から相談先へ進める
内容を読み終えた地点に相談先がないなら、一つ案内を足します。ページの上下に無条件でボタンを増やさず、説明の切れ目とスマートフォンでの見え方を確かめます。クリックが増えても送信成功が増えない場合は、フォーム側のつまずきも調べます。
7．遅い箇所があれば、その原因だけを直す
実測で読み込みや操作に問題が見つかった場合は、重い画像など影響箇所から対応します。GoogleのCore Web Vitalsの説明は表示、操作への反応、表示の安定性を分けています。表示速度の改善だけで問い合わせ増を保証できません。変更前後の表示と相談経路を両方確かめます。
フォームを見直す小さな改善8～10
8．必須項目が受付に必要か確認する
初回の返答に使わない項目が必須なら、社内の受付担当と必要性を確認します。項目を減らすこと自体を目標にせず、相談の判別に必要な情報は残します。W3Cのフォームの案内も、必要な情報だけを求め、ラベルや入力の説明を備えることを勧めています。
9．入力エラーと完了表示を具体的にする
送信に失敗したときは、どの項目をどう直すかが分かり、入力済みの内容が不要に消えないか試します。送信後には受付できたかを明示します。W3Cの通知の説明は、分かりやすいエラーと成功の案内を扱っています。色だけでエラーを示さず、実際にキーボードやスマートフォンでも確認します。
10．送信後の受信まで試す
完了画面が見えても、担当者が受信できなければ相談を扱えません。テスト用の入力を使い、送信完了、受信先、自動返信、迷惑メール判定、担当者の対応記録を確かめます。定期的な送信・受信の点検はフォームの動作を確認する記事で詳しく扱います。
変更後は、同じ条件で比較して判断する
変更内容と日時を一行で残し、公開画面と送信テストを確かめてから、変更前と同じ対象ページ、期間の長さ、端末・流入元で数字を見ます。フォーム到達と送信成功を別々に見れば、導線の問題か入力の問題かを絞れます。件数が少ないときや広告・季節条件が変わったときは、数値差だけから因果関係を断定しません。
対応できる相談が増えたか、返信の負担が増えすぎていないかも確認します。次の変更はこの結果を記録してから選びます。更新やフォームの保守を継続する範囲はBämの保守・管理で確認できます。どの経路から手を付けるか迷う場合は、対象ページと困っている点を添えてご相談ください。
直す前に、そもそもどの段階で止まっているかを確かめると、手を入れる場所を絞れます。確かめる順番はホームページに問い合わせが来ないとき、最初に見直す場所にまとめました。問い合わせの相談は問い合わせを増やしたい方のページで受けています。
まとめ
問い合わせ率を見直す第一歩は、分母と分子をそろえ、実際の送信と受信が計測できているか確かめることです。そのうえで一つのページの一つのつまずきを選び、10項目から合うものだけを試します。クリックや率の変化は判断材料の一つとし、届いた相談の内容と合わせて次の作業を決めてください。
参考資料
- Google Analytics ヘルプ「Recommended events」（2026年9月25日確認）
- Google Analytics ヘルプ「Report on key events」（2026年9月25日確認）
- W3C WAI「Forms Tutorial」（2026年9月25日確認）
- W3C WAI「User Notification」（2026年9月25日確認）
- Google Search Central「Core Web Vitals」（2026年9月25日確認）
