ACQUA JOURNAL
BtoBのLP構成を決める方法｜検討する人の疑問と社内説明の材料を整理する
BtoBのLPは、決まった数のセクションを並べれば完成するものではありません。最初に探している人が「自社の問題に合うか」を判断でき、必要なら社内の関係者に説明できる材料をそろえます。そのうえで、資料を読む、条件を確認する、相談するなど、検討の段階に合う次の行動を用意します。
この記事は、企業の経営者・営業担当・Web担当が、自社サービスのLPに何を載せるか決めるためのガイドです。制作会社への依頼にも使える構成表と確認項目を紹介します。例は設計方法を説明するためのもので、実在企業の成果やAcquaの制作実績を示すものではありません。
最初に、誰が何を判断するページか決める
「法人向け」だけでは読者が広すぎます。現場で問題を抱える人、候補を探す人、予算を決める人、導入後に使う人が同じとは限りません。実際の相談や商談で誰が参加し、どんな疑問が出たかを、掲載してよい範囲で整理します。BtoBなら必ず二人で決裁するといった前提は置きません。
読者と検討の段階を一文で書く
たとえば「更新が止まった企業サイトについて、社内の担当と外部への依頼範囲を決めたい人」のように書きます。ここから、更新する内容、保守との違い、必要な資料、見積もりの確認へ話をつなげられます。「Web全般に困るすべての企業」より、最初の疑問を具体的に扱える状態です。
読者が課題を知ったばかりなら、問題の整理と対処の選択肢が必要です。依頼先を比較しているなら、対応範囲・条件・確認可能な事例を先に探せるようにします。相談を決めている人には、準備資料と窓口までの道を短くします。一つのLPですべてを説明しきれない場合は、詳細なサービスページや記事に分けて案内してください。
目的は「問い合わせを増やす」とだけ書かず、「自社で更新できる部分と、実装や保守を依頼する部分を分けて相談できる」など、読後の判断まで決めます。自社で対応できる人には、答えや確認方法をそのまま渡して構いません。
構成表は、質問と答えを対応させて作る
デザインを選ぶ前に、読者の質問、載せる答え、その根拠、未確認の点を一つの表にします。以下は構成を検討するための空欄のひな型です。上からそのまま並べる必須テンプレートではありません。
| 読者の質問 | 掲載する材料 | 社内で確認すること |
|---|---|---|
| 自社の問題を扱えるか | 対象となる困りごとと対象外 | 営業・運用担当が実際に対応できるか |
| 何を依頼できるか | 作業範囲、成果物、担当の分担 | 標準対応と個別見積もりの境界 |
| どんな状態を目指すか | 改善後に確認する状態 | 成果を保証する表現になっていないか |
| 判断を支える根拠はあるか | 許諾済み事例、仕様、公開資料 | 数字の期間・条件と掲載許可 |
| 費用や負担はどう決まるか | 見積もりの前提、準備資料、進め方 | 現在の料金・契約条件との一致 |
| 次に何をすればよいか | 資料、詳細説明、相談の窓口 | 遷移先と受付後の担当 |
答えが社内でも分からない項目は「要確認」と残します。デザイナーが仮の料金や導入数を入れると、後で実績や契約条件に見えてしまうためです。未確定の欄を画像に焼き込んだり、そのまま公開したりしないよう、原稿の確認者を決めてください。
最初の画面には、対象となる悩み、提供する内容、必要なら次に進める窓口を簡潔に置きます。「三秒で必ず理解される」という保証はありません。説明の前提を知らない人が、何のサービスで、自分に関係するか分かるかを確かめます。専門用語を使う場合も、その人が理解するための説明を添えます。
解決策は、作業と支援後の状態で説明する
「効率化できます」「伴走します」だけでは、何を任せられるか分かりません。扱う困りごと、引き受ける作業、企業側で用意するもの、支援後に確かめる状態をつなげて書きます。対象外や前提条件も、比較に必要な情報です。
たとえば掲載情報の更新支援なら、現在の情報を誰が確定するか、文章・画像を誰が準備するか、WordPressへの反映と公開確認を誰がするかを説明します。解決状態は「記事を投稿した」より、「現在の内容が公開ページに反映され、次の変更を依頼する担当と資料が分かる」とする方が、業務上の完了を確認しやすくなります。これは説明の例で、特定の定額サービスにすべて含まれるという意味ではありません。
特徴の数は決めつけず、選ぶ理由になるものを残します。使う技術や機能には、それが読者の問題にどう役立つかを添えます。「引き継ぎ時間がゼロ」「社内負担がなくなる」といった全称は、条件と実証がなければ使いません。社内の確認や承認が必要なら、その役割も明記します。
業種別の内容も、キーワードを差し替えるだけで作らないようにします。製造業なら仕様や問い合わせに必要な図面、SaaSなら利用環境や連携の確認、専門サービスなら対象範囲や依頼資料など、実際に選ぶための条件を自社の提供内容と照合します。確認できない機能を、業種の一般例から追加してはいけません。
実績や数字は、根拠と条件をそろえて掲載する
確認できない数値を、実例に見せない
導入数、満足度、継続率、売上、問い合わせの増加を載せるなら、対象、期間、集計方法、変更前後の条件を確認します。満足度と継続率は別の指標です。割合には何件を分母にしたかを添え、データがなければ空想の数字で埋めません。
数値がない場合は、合意した課題、担当した工程、成果物、確認できた状態を説明できます。顧客名、ロゴ、写真、発言、画面、非公開の業務情報には掲載許可が必要です。許可が得られない事例を、別企業のように書き換えて実績に見せることも避けてください。
前後の比較は、LPだけが原因と断定しません。広告、営業対応、季節、計測方法、サイト全体の変更が同時に変わっている場合があります。説明できる範囲を区切り、「公開表示を確認した」「受付を試験した」と「問い合わせが増えた」を分けます。
読者が社内で説明する材料には、出典、確認日、適用条件を残します。画像だけの比較表は、スマートフォンで細かくなったり、文字を取り出しにくかったりします。要点は本文や表にも記載してください。機密や顧客情報を、説得材料のために過剰に公開する必要はありません。
費用・進め方・依頼前の疑問をまとめる
料金を載せる場合は、現在の正式な条件、含む作業、含まない作業、追加費用が生じる前提を照合します。見積もりが必要なサービスでは、何が費用を変えるかと、見積もりに必要な資料を説明できます。未確定の下限価格、契約期間、無料対応、納期を、読みやすさのために作ってはいけません。
相談から支援開始までの役割を示す
自社の実際の進め方に合わせて、相談内容の整理、現状の確認、作業範囲の提案、見積もりと合意、制作・確認、公開、更新の分担を説明します。工程の数より、誰が何を準備し、どこで判断するかが大切です。確認待ちがある場合や、外部の契約・システムが関係する場合も前提に含めます。
FAQは固定数を埋めず、商談や問い合わせで繰り返し出る疑問を選びます。利用環境、社内の準備、他社制作サイトへの対応、保守、変更、終了時の引き継ぎなどについて、回答をサービス担当に確認します。回答が個別条件で変わるなら、その条件を示してください。「何でも対応」「必ずこの期間で完了」とまとめないようにします。
検討用の資料を用意する場合は、何が載っているかと配布方法を決めます。すぐ読める公開資料と、連絡先を入れる資料請求を同じものとして案内しません。資料ダウンロードの方式を選ぶガイドでは、その判断を別に説明しています。
ボタンの先と受付までを、一つの導線として確認する
ボタンを目立たせるだけでは、行動を完了できません。資料を開く、相談内容を送る、見積もりを依頼するなど、押した先で何が起きるかが分かる言葉にします。「詳しくはこちら」だけより、リンク先の目的を説明できる表現を選びます。これはW3Cのリンク目的の説明にも沿う考え方で、問い合わせ増加を保証するものではありません。W3C：リンクの目的を分かるようにする
すべての訪問者を最初から相談へ送る必要はありません。条件を読みたい人には詳細へ、自分で確認したい人には手順へ、実務を依頼したい人には相談へ進めるようにします。別ページへ進んだあとに、対象サービスや相談窓口を見失わないかも確認します。
フォームでは、受付に必要な入力、ラベル、入力例、エラーの説明、送信結果を確認します。必要以上の情報を求めず、どこを直せばよいかが分かるようにします。W3Cのフォーム解説は、入力の説明と検証、成功・エラーの通知を扱っています。W3C：フォームの作り方
表示確認と、実送信による受付試験は別です。試験では、送信してよい宛先と時刻、担当、テスト内容の扱いを決めてから、受付・通知まで確かめます。「一分で入力」「営業しない」「無料」などの案内は、実際の条件や対応方針が確認できたときだけ掲載します。制作担当の判断で受付後の約束を追加しません。
構成を決めたあと、読者が判断できるか試す
表示と理解と事業成果を分けて見る
PCとスマートフォンで、見出し、表、図、リンク、フォームが読めて操作できるかを確かめます。対象者が内容を説明できるか、疑問の答えを見つけられるか、次の行動を選べるかも、可能な範囲で試します。スクロールやクリックがあっても、意味を理解したとは限りません。
ページの確認には、次のような質問を使えます。「誰のどんな問題を扱っていますか」「依頼できる作業はどこですか」「自社で用意するものは分かりますか」「比較に足りない条件はありますか」。答えに迷った箇所を記録し、文章・順番・リンクのどこに原因があるか調べます。正解を先に教えると迷いを見つけにくくなります。
公開後は、閲覧、資料の操作、ボタンクリック、実際の問い合わせ、適合した相談、受注、支援後の解決、工数と利益を分けて記録します。クリック数を問い合わせ件数に置き換えず、閲覧だけで成功・失敗を決めません。変更日、対象、課題、狙い、比較条件を残し、短期の変動だけで構成を頻繁に変えないようにします。
LPそのものの確認と、広告・受付・計測の公開判断は範囲が違います。必要な場合はLP公開前チェックリストへ進んでください。本稿の構成表だけで全機能の確認が済むわけではありません。
自社で整理する材料と、Acquaへ相談する仕事
まず、対象サービス、読者、相談でよく出る質問、現在のURL、正式な条件、掲載できる事例、希望する完成状態をまとめます。自社で答えを確定できるなら、その内容を使って構成表を作り、足りない情報を埋めてください。問いと根拠がそろえば、見た目の型を先に選ぶ必要はありません。
文章や構成の整理、LPの制作、WordPressへの実装、既存サイトの修正、公開後の更新・保守が必要な場合は、希望する工程をAcquaへ相談できます。どの作業を引き受けるか、成果物、社内の確認者、費用と期間は現状を見て合意します。特定の成果倍率や、未確認の実績数を依頼判断の根拠にはしません。
制作会社からの依頼では、決まったデザイン・原稿、実装対象、対応幅、フォーム仕様、確認環境、公開担当、検収条件を共有してください。構成の決定から相談したい案件と、承認済みの仕様を実装する案件では、必要な役割が異なります。
支援後は、対象者が対応範囲と条件を理解でき、必要な情報や相談先に進めて、社内担当が掲載内容と更新方法を説明できる状態を目指します。その確認と、問い合わせ・受注の結果を分けて見ていきます。
