ACQUA JOURNAL
ホームページの問い合わせ導線チェックリスト|画面点検から修正依頼まで

ホームページの問い合わせ導線を見直すときは、まず一つの入口ページから、サービスの内容を理解し、比較に必要な情報を探し、連絡方法を選ぶところまで実際にたどります。ボタンの数や色だけを見ると、費用の条件が分からない、事例から元のサービスへ戻れない、といった途中の困りごとを見落とします。
この記事では、経営者やWeb担当者が制作会社と一緒に使える、画面点検の進め方をまとめます。英国政府の公開設計資料とW3Cの解説を参照し、手順・観察メモ・修正依頼の例を示します。説明に登場する設備点検会社と利用者の行動は架空の例で、Acquaの顧客実績や改善効果の報告ではありません。
アクセスの数え方や問い合わせが来ない原因全体を調べたい場合は、計測・内容・導線・受付を分ける診断ガイドから確認してください。本記事では、画面のどこで判断や操作が止まるかを、修正できる形で記録することに集中します。
1. 点検する人と、達成してほしい課題を決める
「問い合わせボタンを押す」を課題にしない
最初に「誰が、何を知りたい状態で訪れ、何が分かれば次に進めるか」を一文にします。例えば架空の設備点検会社なら、「店舗の空調点検を頼みたい担当者が、対応地域と費用の決まり方を調べ、見積もり相談の方法を選べる」が課題です。「右上のボタンを押してください」では、案内を自力で発見できるかを確かめられません。
会社側が期待する経路は、観察用の別メモに書いておきます。参加者には経路やメニュー名を教えず、達成したいことを伝えます。正解の順番を再現させる試験にすると、迷わせている見出しや、別の場所にあると思われている情報が見えなくなります。購入や相談をしないという判断にも、理由が分かれば価値があります。

サイトに詳しくない人にも触ってもらう
担当者自身の点検は、リンク切れや表記の食い違いを探すのに役立ちます。一方、どこに何があるかを知っていると、初めて来た人の迷いは再現しにくくなります。可能なら実際の相談者に近い人へ協力を依頼します。社内で試す場合も、制作や営業に直接関わっていない人を含め、誰に確認したかを残してください。
GOV.UKのユーザビリティテストの説明では、中立的な課題を伝え、操作中に考えたことを話してもらい、進行役は主に観察する方法を案内しています。「サイトを確認するのであって、あなたを評価するのではない」と最初に説明すると、分からない箇所も話してもらいやすくなります。
試す範囲と、送信してよい環境を共有する
開始前に、入口URL、端末、ブラウザ、確認する課題、記録の方法、終了地点を決めます。連絡方法が見つかるかだけを見るなら、送信ボタンを押す必要はありません。送受信まで確かめる場合は、担当者と時刻・宛先・テスト内容を合意し、実際の相談や予約として処理されない環境を用意します。
録画する場合は目的と扱いを説明し、同意を得ます。通知や個人のメールが映り込まないようにし、架空の入力情報で十分な点検には実在顧客の情報を使いません。また、協力者一人の操作から「訪問者全員が迷う」とは言えません。問題を発見する観察と、その問題がどれほど広く起きているかの推定は分けて扱います。
2. トップページ以外の入口からも、次の案内を探す
入口ごとに、訪問時の疑問を書き出す
トップページ、検索から読まれる記事、個別サービス、制作事例、紹介時に送っているURLを候補にします。アクセス解析があれば実際の入口を選べますが、数値だけで目的までは確定できません。営業でよく送るページや、問い合わせ前に読んでほしいページも含め、入口と想定する疑問を対応させます。
架空の設備点検会社であれば、点検頻度の記事から来た人は「自社の設備も対象か」、会社名を聞いて来た人は「どんな会社か」、サービスページを紹介された人は「この条件で依頼できるか」を知りたいかもしれません。同じ「お問い合わせ」へのリンクでも、その前に必要な説明が違います。入口を変えて同じ課題を試すと、説明の抜けを比較できます。
| 入口 | 利用者の課題 | 画面で確かめること |
|---|---|---|
| 解説記事 | 自社も点検を依頼できるか知りたい | 対応サービスと対象条件へ進めるか |
| サービスページ | 予算を考える材料を集めたい | 費用の条件と見積もり方法が分かるか |
| 事例ページ | 似た依頼を相談できるか判断したい | 担当範囲と関連サービスが結び付くか |
| 会社概要 | 紹介された会社の相談窓口を知りたい | 連絡先と相談後の流れを見つけられるか |

最初の画面で、ページの役割が伝わるかを見る
入口を開いたら、見出しや冒頭を読んで「何についてのページだと思いますか」と聞きます。意図と違う説明が返ってきたら、すぐ正解を教えず、どの言葉や写真からそう思ったかを確かめます。「法人向け」と小さく書いてあるのに個人向けと受け取られたなら、文字の有無だけでは説明できない配置の問題が考えられます。
読み込み途中の表示も確認します。大きな写真や動く見出しを待っている間に必要な説明が見えない、画面が動いて押したいリンクがずれる、といった状態は完成後の静止画では分かりません。ただし、自分の端末で遅かったことだけで全員の環境を代表させず、回線・端末・再現条件を記録して制作担当へ渡します。
記事を読み終えた後の選択肢を用意する
解説記事を読んだ人が、必ずすぐ相談したいとは限りません。「サービスの範囲を確かめる」「類似事例を見る」「準備物を確認する」など、その記事を読んだ後に生まれる疑問を考えます。必要な次の情報が別ページにあるなら、本文の話題がつながる場所から、リンク先の内容が分かる言葉で案内します。
点検では「この会社に相談するとしたら、次に何を調べますか」と聞き、その情報を探せるかを見ます。記事末尾まで読んだ人が最も相談意欲が高い、と決め付ける必要はありません。途中で判断材料が足りなくなり、別ページを探す人もいます。リンクは読み終えた位置だけでなく、疑問が生まれる箇所でも確認してください。
3. サービスページで、依頼できる条件を理解できるか確かめる
対応範囲と対象外を探してもらう
「どんな悩みを解決するか」だけでは、実際に頼めるかが分からないことがあります。設備点検の例なら、対象機器、建物の種類、地域、営業時間、緊急対応の有無などが判断材料です。全部を目立たせるのではなく、課題に必要な条件へ見出しやリンクから進めるかを観察します。
「この設備は対象だと思いますか。どこを見てそう判断しましたか」と聞くと、読めた事実と推測を分けやすくなります。会社側が対応しない仕事まで期待される場合は、強みの表現を足すより対象外や個別確認の条件を補う方が適切なこともあります。誤解を減らすための説明は、件数だけでなく相談内容の適合性にも関わります。

価格だけでなく、金額が決まる条件を見る
価格表があっても、何が含まれるか、追加費用が発生する条件、見積もり前に必要な情報が見つからなければ比較しづらくなります。点検では「費用を確認して、社内の担当者へ説明してください」と依頼します。金額だけ読み上げられるのか、条件まで説明できるのかで、補うべき内容が変わります。
個別見積もりのサービスなら、無理に一律の価格を作らず、金額に影響する条件と相談時の準備物を案内します。例えば「台数・現場写真・希望時期を確認して見積もる」という説明です。料金の記載を変えるときは実際の営業条件と照合し、文章だけで新しい約束を作らないようにします。見積もりの比較項目はホームページ制作の見積もり確認ガイドでも整理しています。
相談後の進み方と、決定が必要な時点を確認する
問い合わせの前に、相談したら契約になるのか、見積もりまでに打ち合わせが必要か、どの段階で費用が発生するかを気にする人もいます。利用者に「今送ると、次は何が起きると思いますか」と聞いてください。説明したつもりでも、ボタンに「お申し込み」とあるため即契約と受け取られるなど、本文と操作の言葉が食い違う場合があります。
無料相談、資料請求、見積もり依頼などは、実際の対応に合う名称を選びます。気軽さを演出するために、実際には有料の工程を無料と受け取れる表現にしないことも大切です。点検時には、利用者の理解と社内の受付手順を並べて照合し、どちらの資料を更新する必要があるかまで決めます。
4. 事例・会社情報・FAQを行き来して比較できるようにする
事例の存在と、判断に使えることを分ける
事例ページへ進めても、写真と会社名しかなければ、何を担当したかや自社との共通点が伝わらないかもしれません。「この事例から、今回の相談に役立つことを一つ挙げてください」と聞き、依頼内容・担当範囲・条件を読み取れるかを確認します。成果数値がなくても、実際に制作したものと担当工程を示せば判断材料になります。
一方、公開許可のない顧客名や、根拠を確認できない成果を補ってはいけません。担当した仕事と、顧客側の運用で生じた結果も区別します。点検の結果「似た業種が見つからない」と分かった場合、架空の実績を増やすのではなく、相談できる範囲や実際の進め方を説明する方法を考えます。

必要な会社情報やFAQに戻れるかを確かめる
比較中には、サービスから会社概要、事例から料金、FAQからサービスへと移動が起きます。会社の住所や担当窓口を見つけた後に、検討していたサービスをもう一度開けるかも点検します。ページが独立していることと、検討が続けられることは同じではありません。行き先に関連サービスへの案内があるか、メニューから迷わず復帰できるかを見ます。
FAQは件数よりも、実際の判断に必要な質問が見つかるかが大切です。「対応地域」「追加費用」「公開後の修正」のように疑問が異なる場合は、関係する説明の近くから該当回答へ進めると確認しやすくなります。答えを読むために複数ページを何度も往復していたら、その画面と探していた言葉を記録します。
公開事例から、リンクの往復による迷いを学ぶ
GOV.UKの段階別ナビゲーションの公開資料には、開発中に障害のある人などを含めて8回の調査を行ったことと、別の案内へ移動してから元の案内へ戻るループで利用者が不満を感じるという課題が記載されています。これは英国政府の案内設計の記録で、企業サイトの問い合わせ率を示す結果ではありません。
企業サイトの点検に応用できるのは、関連リンクを置いた後、実際に一連の課題を達成できるか確かめる視点です。例えば料金からFAQへ進み、FAQが再び料金の冒頭を案内するだけなら、知りたい追加費用の答えに着かないかもしれません。移動回数の少なさより、移動した先で新しい判断材料が得られるかを見てください。
5. メニュー・リンク・戻り道をスマートフォンでも操作する
リンク先を予想できる言葉にする
「詳しくはこちら」が並んでいる場合は、どの情報を開くリンクかを周囲の説明と合わせて確かめます。W3Cのリンク目的の解説では、リンクの文字や、プログラムで関連付けられた文脈から目的を理解できることを説明しています。見た目で近くに文字があるだけで、読み上げでも同じ関係が伝わるとは限りません。
「料金と追加費用を確認する」「点検の担当範囲を見る」など、目的を具体的に表すと点検もしやすくなります。押す前の予想と、開いたページの見出しが一致するかを確認してください。リンク名を説明的にした結果スマートフォンで不自然に折り返す場合は、文字を曖昧に戻す前に、配置と余白を調整する選択肢があります。

共通メニューと戻る操作の一貫性を見る
W3Cの一貫したナビゲーションの解説は、複数ページで繰り返される案内の相対的な順序を保つ考え方を示しています。ページを変えるたびに「事例」と「料金」の並びが入れ替わると、再び探す負担が生じます。下層ページ固有の案内を追加することと、共通メニューの順序が変わることは区別して点検します。
GOV.UKの戻るリンクは、複数画面の手続きで元のページの状態へ戻すことを説明しています。企業サイトでも、フォームから条件を見直して戻ったときに入力が消える、メニューを閉じた後に読んでいた位置が変わるなどを確認します。ただし、政府サービスの配置ルールを全ページへそのまま適用する必要はありません。
固定ボタンが内容や操作を隠さないか確かめる
スマートフォンでは、メニューを開く、閉じる、文章を拡大する、画面を横にする、入力欄を選んでキーボードを出す、といった状態を試します。画面下の固定ボタンが説明文や送信ボタンに重ならないかも見ます。PCの幅を狭くした表示だけでは、端末のキーボードやブラウザの操作領域との重なりを十分に再現できない場合があります。
キーボード操作でもTabキーで進み、どこに移動したかを追います。W3Cのフォーカスが隠れないことの解説は、操作対象が制作者の重ねた内容で完全に隠れないことをAAの基準として示しています。文字の拡大や読み上げを含む詳しい点検は、企業サイトのアクセシビリティ改善も参考にしてください。
6. 連絡前の準備から、送信後の案内までをつなぐ
状況に合う連絡方法を選べるかを見る
フォーム、電話、メール、予約などを設けている場合、それぞれ何に使う窓口かを確認します。すべてを同じ強さで並べると、急ぎの相談をフォームへ送るべきか、電話してよい時間かで迷うこともあります。実際に対応できる時間・相談内容・連絡手段を示し、利用者の状況に合う方法を選べるようにします。
架空の点検会社なら「来月の定期点検を相談したい」と「今すぐ故障の対応を頼みたい」では適した案内が異なります。緊急対応をしていないなら、常時対応できるような電話ボタンの文言にしません。点検では、利用者が選んだ方法と選んだ理由を記録し、会社が想定した使い分けと照合します。

入力前に必要な情報と、分からないときの扱いを示す
フォームを開いた後に初めて、図面や機器番号が必須と分かると、その場で続けられないかもしれません。問い合わせ前の案内と必須項目を並べ、事前に用意するものが伝わっているか確認します。手元にない情報について「不明」を選べるか、後から確認できるかは、実際の受付業務と合わせて判断してください。
項目を減らすだけが解決策とは限りません。見積もりに欠かせない情報を削れば、受付後の確認が増える場合があります。まず、何のために必要か、初回で必須か、入力方法が理解できるかを見ます。入力欄やエラー表示そのものの改善は、問い合わせフォームの点検ガイドへ分けて依頼すると、作業範囲が明確になります。
完了したことと、次に起きることを区別して伝える
送信後は「送れたか」「いつ、どう連絡が来るか」「連絡がない場合はどうするか」を確かめます。GOV.UKの完了ページの設計資料は、次の対応と時期、連絡先などを案内する考え方を示しています。企業サイトでも、実際の対応時間に合う説明があると、その後の行動を判断しやすくなります。
完了画面が出ることと、担当者が受信したことは別です。合意したテスト環境では、送信画面、受信、返信の記録を照合します。自動返信を使う場合も、画面とメールの案内が食い違わないかを確認します。内容や運用の確認項目は問い合わせ自動返信メールのガイドで詳しく整理しています。
7. 点検結果を、修正できる記録と優先順位に変える
「分かりにくい」を画面と行動に分解する
点検メモには、課題、入口、端末、開いた順番、止まった画面、本人の発言、進行役が助けた内容を残します。「使いにくい」だけでは、文章を変えるのか、リンクを追加するのか、動作を直すのか決められません。「料金の条件を探してFAQを開き、料金ページに戻っても対象機器が分からなかった」のように観察事実を具体化します。
その隣に「対象機器の説明へ届く案内が不足しているかもしれない」と仮説を書きます。事実と解釈を同じ欄に混ぜると、別の原因を検討しにくくなります。操作が止まった時間も参考になりますが、じっくり比較していた時間を迷いと決め付けず、何を考えていたかを本人に確認してください。
| 記録する内容 | 記入例 |
|---|---|
| 課題・環境 | 対象機器と見積もり方法を調べる。スマートフォン、サービス詳細から開始 |
| 観察した事実 | 料金→FAQ→料金と移動し、対象機器の説明を見つけられなかった |
| 利用者の発言 | この設備でも頼めるのかが分からない |
| 仮説 | 条件の説明が別ページにあり、料金からの案内が不足している可能性 |
| 修正候補 | 料金の条件の近くに対象機器の説明と関連リンクを置く |
| 確認条件 | 補助説明なしで対象条件を見つけ、見積もり相談の方法を選べること |

操作できない問題と、説明の改善を分けて並べる
優先順位は、利用者が達成できなくなる程度、起きる範囲、誤解した場合の影響、修正に必要な条件で考えます。送信できない、連絡先が誤っている、メニューが閉じられないなどは、相談の成立に直接関わります。一方、ボタンの表現をより分かりやすくする改善は、同じ緊急度とは限りません。
小さな変更なら必ず先、フォームなら必ず最優先、と固定しないことが大切です。価格の誤表示があれば、ボタンの配置より早く直す判断もあります。確認できた問題と、まだ推測にとどまる問題を分け、担当者・期限・確認方法を付けます。調査が必要な項目は、解決案を決め打ちせず、次に何を確認するかを作業として登録します。
依頼は、修正箇所と完了条件をセットにする
制作会社への依頼には、URL、対象箇所の見出し、再現操作、期待する状態、確認した端末を添えます。スクリーンショットに印を付ける場合も、画像だけではリンク先や入力状態が伝わらないため、操作手順を文章で補います。「問い合わせを増やしたい」という目的に加え、今回どの障害を取り除くかを明確にします。
修正文言、リンク先、共通メニューへの影響、公開時期、元に戻す条件まで合意できれば、確認漏れを減らせます。複数ページの料金や対応範囲を直す場合は、該当ページの一覧も必要です。依頼後の追加変更を混ぜずに管理する方法は、ホームページの修正依頼ガイドにまとめています。
8. 修正後に同じ課題を試し、次の改善へ引き継ぐ
修正した部品だけでなく、一連の流れを再確認する
リンクを追加したら、表示だけで完了にせず、元の入口から同じ課題をやり直します。行き先が正しくても、そのページから相談へ戻れなくなっていないか、スマートフォンでメニューが隠れていないかを確かめます。共通部品の変更なら、別のサービスや記事にも影響が及ぶため、代表ページを選んで再確認します。
同じ協力者は前回の操作を覚えている可能性があります。改善後に早くできた理由が修正なのか慣れなのかは区別が必要です。可能なら初めて触る人にも課題を試してもらいます。参加条件が違う結果を単純に比べて改善率を出さず、どの困りごとが再現しなくなり、何がまだ残るかを具体的に記録します。

画面の改善確認と、問い合わせの成果を分ける
点検で「対応地域を見つけられた」「戻っても入力が保たれた」と確認できても、問い合わせ件数の増加が証明されたわけではありません。公開後は、同じ定義で計測した入口・相談への移動・受付件数や相談内容を見ます。営業メールや既存顧客からの連絡を、新規案件の相談と同じ成果としてまとめないようにします。
アクセス数、広告、季節、サービス条件が変われば、問い合わせも影響を受けます。短期間の小さな増減だけで修正の成功・失敗を決めず、変更日と同時に変えたことを記録します。データが少ない間は、観察で確認した不便の解消を根拠にしながら、相談内容に合う情報が届いているかを継続して確かめます。
次回も使える点検表を残す
最後に、次回の担当者が同じ条件で確認できるよう、入口URL・課題・確認日・端末・修正内容・残る問題を一か所へまとめます。新サービスの追加、料金の変更、フォームの変更、メニューの入れ替えなどがあったときに、どの課題を再確認するかも決めておきます。点検は公開時に一度実施して終えるものではありません。
| 段階 | 確認すること | 残す記録 |
|---|---|---|
| 入口 | ページの対象と次の情報が分かる | 入口URL・最初の理解・探した情報 |
| 比較 | 範囲・費用条件・事例を確認できる | 足りない説明・往復したページ |
| 操作 | メニュー・リンク・戻る操作が使える | 端末・操作手順・重なった箇所 |
| 相談 | 方法・準備物・送信後の流れが分かる | 利用者の理解と実際の受付手順 |
| 修正後 | 同じ課題を補助なしで進められる | 確認日・残る問題・次の担当 |
まずは実際によく案内する一つのページから始め、利用者が判断できない箇所を一つ具体化してください。その記録があれば、相談を増やすために何を直すかを、制作会社と同じ画面を見ながら話せます。Acquaへの相談でも、点検したURLと困った操作が分かると、ホームページの制作・改善で必要な対応範囲を整理しやすくなります。