BtoB SaaSのLPでフォーム項目をどう作るか｜先に整えること

なお、TimeValue株式会社では、広告運用・クリエイティブ制作・LP改善・データ分析・AI導入までを一括で引き受けるWebマーケティング支援「KAIZEN」を提供しています。

現在、オンラインの無料マーケティング診断を毎月10社限定で実施中です。いまの数字を見ながら、どこから直すのが早いかを一緒に整理します。

今月の無料診断は残り4社です

無料マーケ診断を申し込む

広告からLPまで、まとめて見ます。オンラインで30分から対応しています。

BtoB SaaSのLPでフォーム項目を決める前に何を整理すべきですか

BtoB SaaSのLPでは、フォーム項目の数を減らせばよいとは限りません。
逆に、営業に必要そうな情報をすべて入力させればよいわけでもありません。

フォーム項目を決める前に確認したいのは、フォーム送信後に社内で何が起きるかです。
営業担当者が電話するのか、インサイドセールスが確認するのか、自動メールだけを送るのかによって、取得すべき情報は変わります。

営業が実際に使っている情報を確認する

まず営業担当者に、初回接触前に何を知りたいかを確認します。
ここで注意したいのは、あると便利な情報と、なければ対応できない情報を分けることです。

たとえば会社名や氏名、メールアドレスは、多くの商談対応で必要になります。
一方で、従業員数、導入予定時期、現在利用している仕組み、予算などは、サービスによって必要性が異なります。

営業から要望された項目をそのまま必須項目にすると、フォームが長くなります。
そのため、各項目についてこの情報がなければ送信後に何ができなくなるのかを確認します。

送信後の電話で聞ける情報であれば、LPのフォームで必須取得する必要がない場合もあります。

フォーム単体ではなく送信後まで含めて設計する

LP改善では、フォーム到達率やフォーム完了率だけを見て項目数を決めることがあります。
しかしBtoB SaaSでは、その後の商談化まで含めて考える必要があります。

フォームを短くして送信数が増えても、営業が誰に連絡すべきか判断できなければ、対応工数が増えます。
一方で、入力項目を増やしすぎると、検討度の高いユーザーまで離脱する可能性があります。

そのため、フォーム項目はCVRを高めるための画面要素ではなく、見込み顧客を社内の営業プロセスにつなぐための情報設計として考えます。

フォーム項目を決める前に確認する社内情報

フォームを作り始める前にこの情報を整理しておけば、後から項目を追加したり、CRM側でデータを修正したりする作業を減らせます。

営業が必要とする情報はどこまでフォームで取得すべきですか

営業部門にフォーム項目の要望を聞くと、多くの情報が挙がることがあります。
部署、役職、会社規模、課題、導入時期、予算、利用人数、現在利用中のサービスなどです。

これらが営業活動に役立つこと自体は間違いではありません。
ただし、役立つ情報だからといって、すべてLPで取得する必要はありません。

送信直後に使う情報から残す

取得候補となった項目ごとに、いつ使うのかを確認すると整理しやすくなります。

フォーム送信直後の担当者決定に使うのであれば、フォームで取得する意味があります。
営業担当者が初回電話で確認すれば足りる内容であれば、必須入力から外せる可能性があります。

たとえば、提供エリアや企業規模によって担当営業が異なる場合、所在地や従業員規模をフォームで取得する理由があります。
一方で、細かな運用課題を営業ヒアリングで把握する体制なら、自由記述欄で詳しく書かせる必要性は下がります。

営業の希望をそのまま必須条件にしない

営業が欲しい情報と、ユーザーが入力しやすい情報には差があります。

会社名やメールアドレスは比較的入力しやすい情報です。
一方で、具体的な予算や社内の導入時期は、検討初期では答えられないユーザーもいます。

まだ社内で予算化されていない段階で予算を必須にすると、正確な情報を取得できるとは限りません。
入力を完了するために、ユーザーが近そうな選択肢を選ぶこともあります。

この状態では項目数だけ増え、営業判断に使えるデータの精度が上がらない可能性があります。

自由記述欄は目的を決めてから置く

お問い合わせ内容などの自由記述欄は、多くのフォームで使われています。
ただし、何を書けばよいか分からない状態で必須にすると、ユーザーの負担になります。

営業側が問い合わせ内容を事前に知る必要があるなら設置する意味があります。
資料請求のように、まず資料を受け取ることが主目的であれば、自由記述を任意にする選択もあります。

入力項目の判断では、営業側の情報量を最大化するのではなく、送信時点で本当に必要な情報だけを取得することが基本になります。

フォーム項目とリード判定基準はどう対応させればよいですか

BtoB SaaSでは、すべてのフォーム送信者を同じ優先度で営業へ渡すとは限りません。
会社規模、部署、役職、導入時期、問い合わせ内容などを使い、対応優先度を分ける場合があります。

この判定基準とフォーム項目がつながっていないと、フォームから情報を集めても営業プロセスで活用されません。

先に判定基準を文章にする

フォーム項目より先に、どのようなリードなら誰が対応するかを文章にします。

たとえば説明のための仮の条件として、従業員数100名以上なら営業担当へ即時通知し、それ未満ならインサイドセールスが確認するという運用を考えます。
この場合、従業員数をフォームで取得する理由は明確です。

反対に、従業員数によって営業対応が何も変わらないのであれば、取得する意味を改めて確認する必要があります。

リード判定に使う項目は、社内の処理と一対一で対応している状態が理想です。

選択肢は営業の分類単位にそろえる

フォームでは入力しやすさを考えて選択式を使うことがあります。
この選択肢も、営業やCRMの分類方法とそろえる必要があります。

たとえばフォームでは1名から49名、50名から99名、100名から299名と分類しているのに、CRMでは100名未満と100名以上で管理していると、データ変換が必要になります。

分類方法が部署ごとに異なると、レポート集計でもズレが生じます。

そのため、フォームを制作する前にマーケティング、営業、営業企画などで分類単位を確認します。

判定できない項目を無理に増やさない

フォームを充実させようとして、業種、役職、課題、予算、利用人数などを追加すると、データは増えます。
しかし判定ロジックが決まっていなければ、営業担当者が毎回フォーム内容を読んで判断することになります。

自動化したいのであれば、フォーム項目を増やす前に判定ルールを決める必要があります。

リード判定とフォーム項目の対応例

ここで挙げた項目をすべて取得する必要はありません。
自社の判定ルールで使う項目だけを選びます。

CRMの項目設計とLPのフォームはどうそろえるべきですか

LP制作とCRM設計を別々に進めると、フォーム公開後にデータ連携の問題が起きることがあります。

フォームでは取得できているのにCRMの保存先がない、フォームとCRMで選択肢が違う、1つの入力欄を複数のCRM項目へ分ける必要がある、といった状態です。

既存のCRM項目を最初に確認する

LP側から新しい項目を作る前に、すでにCRMで使っている項目を確認します。

会社名、部署、役職、電話番号、業種、会社規模など、既存項目で保存できる情報であれば、それに合わせてフォームを設計します。

マーケティング側だけで分かりやすい名称を付けると、営業側の呼び方と異なることがあります。
画面上の表示名はユーザー向けに分かりやすくしても、内部で保存する項目との対応関係は明確にしておきます。

選択肢を追加するときは既存データとの連続性を見る

フォーム改善で選択肢を変更すると、変更前後でデータ分類が変わることがあります。

たとえば従業員規模の区切りを変更すると、過去リードと新規リードを同じ条件で比較できなくなる可能性があります。
集計に利用している項目ほど、LPだけの判断で変更しないことが大切です。

営業レポートや経営会議で使われている分類であれば、その用途まで確認したうえで変更します。

連携エラーが起きた場合の扱いも決める

フォーム送信は成功しても、CRMへの登録に失敗することがあります。

入力文字数の制限、想定外の値、必須項目の不一致などが原因になることがあります。
フォーム公開前には、正常な入力だけでなく、長い会社名や特殊な文字を入力したケースなども確認します。

また、CRM登録に失敗した場合でも問い合わせそのものを失わないよう、通知メールや別の記録方法を用意しておくと運用しやすくなります。

フォームはLP上だけで完結する機能ではありません。
入力、送信、CRM保存、営業利用までを一本のデータフローとして設計する必要があります。

資料請求とデモ依頼ではフォーム項目を分けるべきですか

BtoB SaaSのLPでは、資料請求、問い合わせ、デモ依頼、相談予約など、複数のコンバージョン導線を設けることがあります。

これらを同じフォームにまとめると管理は簡単になります。
ただし、ユーザーが求めていることと社内の対応方法が異なる場合、一つのフォームですべてを処理しようとすると項目が増えやすくなります。

資料請求では受け取りやすさを考える

資料請求をするユーザーは、必ずしも営業との会話を希望しているとは限りません。
比較検討の初期段階で情報収集している場合もあります。

そのため、営業との面談を前提とした詳細な質問を大量に置くと、ユーザーの目的とフォームの負担が合わなくなります。

資料を送付し、後から属性や閲覧状況を見ながら対応する運用であれば、最初のフォーム項目を絞る設計ができます。

デモ依頼では日程調整や準備に必要な情報を取得する

デモ依頼は、資料請求より営業対応に近い行動です。

担当者が事前に企業情報や利用目的を把握したほうが、有意義なデモを準備できる場合があります。
そのため、資料請求より項目数が増えても、ユーザーにとって入力理由を理解しやすくなります。

たとえば利用目的や想定利用人数がデモ内容を変えるのであれば、事前取得する意味があります。
反対に、デモ内容が全ユーザーで同じなら、入力させる必要性は下がります。

問い合わせ種別だけで一つのフォームにまとめる方法もある

運用上、フォームを複数管理することが難しい場合は、最初に問い合わせ種別を選択してもらい、その内容に応じて表示項目を変える方法もあります。

この場合でも、すべてのユーザーに全項目を見せるのではなく、目的に応じて必要な項目だけを表示する設計が適しています。

CV種別によるフォーム設計の考え方

同じLP内であっても、CVの種類ごとにユーザーの心理状態は異なります。
ボタンの文言だけを変えて同じフォームへ送るのではなく、その後の対応まで含めて項目を検討します。

必須項目と任意項目はどのように決めればよいですか

フォーム設計では、何項目までならよいかという議論になりやすいですが、単純な項目数だけでは判断できません。

会社名を入力する1項目と、社内予算を選ぶ1項目では、ユーザーが感じる負担が異なります。
入力項目の数だけでなく、答えやすさまで考える必要があります。

必須にする理由を一項目ずつ確認する

それぞれの項目について、未入力だった場合に何が困るかを考えます。

メールアドレスがなければ資料を送れないのであれば、必須にする理由があります。
会社規模がなくても営業対応できるのであれば、任意にできる可能性があります。

この確認をすると、昔からフォームにあるから、営業から欲しいと言われたからという理由だけで残っている項目を見つけやすくなります。

答えにくい情報ほど必須設定を慎重にする

導入時期や予算などは、BtoB SaaSの営業判断で使いやすい情報です。
一方、検討初期ではまだ決まっていないことがあります。

選択肢に未定や情報収集中を設ければ回答しやすくなりますが、そもそもフォームで取得する必要があるかも検討します。

無理に選ばせると、データとして保存されても実態を反映していない可能性があります。

入力補助で負担を下げる

削除できない項目については、入力補助を使って負担を減らします。

入力例を表示する、郵便番号から住所入力を補助する、電話番号の形式違いを柔軟に受け付けるなど、細かな設計でも入力しやすさは変わります。

エラー表示も重要です。
送信ボタンを押したあとに初めて複数のエラーが表示されるより、入力中に原因が分かるほうが修正しやすくなります。

選択式にできる項目を自由入力にすると、ユーザーの負担だけでなく、CRM側のデータもばらつきます。
業種や会社規模など、後から分類に使う項目は選択式との相性がよいです。

ただし、選択肢が細かすぎると自分がどこに当てはまるか分からなくなります。
社内で必要な分類粒度と、ユーザーが迷わず選べる粒度の両方を確認します。

個人情報の取り扱いと送信後の対応はどこまで設計すべきですか

BtoB SaaSのフォームでは、氏名、会社名、メールアドレス、電話番号などを取得します。
場合によっては部署や役職、相談内容なども取得します。

そのため、フォーム項目の検討と個人情報の取り扱いは切り離せません。

取得目的と利用方法を合わせる

フォームで取得した情報を、資料送付だけに使うのか、営業連絡にも使うのかによって、ユーザーへの案内内容は変わります。

資料請求をしたユーザーに後日営業担当者が連絡する運用なら、その前提が社内で共有されている必要があります。

また、取得した情報をメール配信にも利用する場合は、その運用を含めて確認します。

具体的な記載内容については、自社のプライバシーポリシーや法務方針に沿って判断する必要があります。
LP制作担当者だけで文章を決めず、社内の管理ルールと一致させます。

送信後の自動返信を先に作る

フォーム公開時には、自動返信メールもセットで準備します。

資料請求であれば資料の受け取り方法、問い合わせであれば回答までの流れ、デモ依頼であれば今後の日程調整方法などを案内します。

フォーム送信後に画面上で完了表示が出ても、ユーザー側では本当に送れたのか不安になることがあります。
自動返信メールが届けば、受付が完了したことを確認できます。

自動返信には、問い合わせ内容そのものを含めるかどうかも確認します。
入力内容に機密情報が含まれる可能性がある場合は、メール本文への転載範囲を社内ルールに合わせます。

担当者の割り振りまで決める

フォームが送信されたあと、通知メールを全営業担当者へ送るだけでは、誰が対応するのか曖昧になることがあります。

地域、企業規模、サービス種別などで担当を分けるなら、フォーム項目と割り振りルールを対応させます。

自動で担当者を設定する場合でも、条件に当てはまらないリードの処理方法が必要です。

また、担当者が休暇中の場合や、通知先が変更された場合など、通常ルート以外の運用も決めておくと放置を防ぎやすくなります。

フォーム改善は画面上のCVRだけを見る作業ではありません。
送信後のレスポンス速度や対応漏れも、LPから発生した商談数に影響します。

フォーム送信後の計測はどのように設計すべきですか

フォームを公開したあとに改善するためには、入力項目と同時に計測方法も決めておく必要があります。

LPへの訪問数とフォーム送信数だけでは、どこで離脱しているのか判断しにくいためです。

送信成功をコンバージョンとして計測する

送信ボタンのクリックをコンバージョンにすると、入力エラーや通信エラーによって送信できなかったケースまで計測されることがあります。

可能であれば、送信成功後の完了画面や送信成功イベントを使って計測します。

資料請求とデモ依頼がある場合は、同じフォームCVとして集約するだけでなく、種類を区別できる状態にします。

資料請求100件とデモ依頼100件では、営業への影響が同じとは限りません。
広告やLPを評価するときにも、CV種別を分けて確認できる設計が必要です。

フォーム到達と送信の間を見る

フォーム改善では、ページ全体のCVRだけでなく、フォームを表示したユーザーのうち何人が入力を始め、何人が送信したかを見ると原因を切り分けやすくなります。

たとえば説明のための仮の数字として、LP訪問者1,000人、フォーム到達者300人、入力開始者200人、送信者100人だったとします。

この場合、LPからフォームへの導線だけでなく、入力開始から送信までにも離脱があります。

項目を変更したときは、最終CVRだけでなく、この途中の変化も確認します。

フォーム項目の改善を商談数までつなげる

項目を減らした結果、フォームCVRが上がることはあります。
しかしBtoB SaaSでは、それだけで改善成功とは判断できません。

商談対象外のリードが大幅に増え、営業工数だけが増えている可能性もあります。

反対に、企業規模などの項目を一つ追加したことでCVRがわずかに下がっても、営業が優先順位を付けやすくなり、商談化数が維持されるケースも考えられます。

そのため、フォーム変更前後では、送信数、リード判定結果、営業接触率、商談化率など、自社で追える範囲まで確認します。

フォーム項目の設計は一度決めて終わりではありません。
営業フローやCRM、商品構成が変われば、必要な情報も変わります。

定期的に、この項目は現在も使われているか、この選択肢で分類できているかを営業側と確認し、不要になった項目を削除していく運用が必要です。

よくある質問

まとめ