SaaSサイトのデモと無料試用を分ける｜確認したいこと別の導線設計

「まず無料で試す」と「デモを予約する」が同じ場所に並んでいても、訪問者はどちらで自社の疑問を解けるか分からないことがあります。画面の操作を自分で確かめたい人、複数部署の要件を担当者へ相談したい人、まだ製品の利用場面を知りたい人では、次に必要な情報が違います。曖昧なボタンは申込数だけの問題ではなく、試用を始めても何を評価するか決まらない状態を作ります。

SaaS・業務用クラウドサービスを提供する会社が自社サイトを見直すなら、デモと無料試用を機能名で分ける前に、検討段階、確認したいこと、次の行動を対応させます。この記事は、販売ページ、専用の案内、フォーム、申込後の画面をどの順で整えるかを示すものです。製品の機能、試用期間、契約条件は事業者ごとに確認し、以下の架空の社内申請サービスの例を実在製品へ当てはめないでください。

「試せる」を書く前に、何を確かめられるかを分ける

みやあじよのSaaS・業務用クラウドサービス向け案内は、画面を見ながら説明を受けるデモと、自分で操作する試用では必要な案内が違うと示しています。試用機能、期間、準備、終了後の扱いまで確認することが、サイト制作の対象です。この方向を個々のページに落とすときは、ボタンの色や文言だけを変えても足りません。訪問者が確認したいことに対し、その入口で返せる答えを用意します。

例えば、架空の社内申請サービスで「承認の流れを見たい」なら、製品担当者と画面を見ながら質問できるデモが合うかもしれません。「自社の担当者で一件作成し、承認まで触ってみたい」なら、試用環境が必要です。ただし、試用で複数人の招待や承認設定が使えない製品なら、試用ページでその期待を作ってはいけません。単に「無料」と言う前に、試せる範囲を製品担当へ確認します。

デモにも録画を視聴するもの、説明会に参加するもの、個別に画面を見せるものがあります。申込が不要な動画を「デモ予約」と呼んだり、営業担当との相談を「今すぐ試す」と呼んだりすると、移動先の内容が予測できません。自社で実際に提供する形式を確かめ、ページの見出しとボタン名をそろえます。フォームの送信後に担当者から日程調整の連絡が来るのか、その場で日時を選ぶのかも、押す前に分かるようにします。

検討段階・確認項目・次の行動を一枚の図にする

次の図は、架空の社内申請サービスのサイトで使う分岐の例です。四つの入口をすべて作るべきという意味ではありません。自社にある資料、デモ、試用、相談窓口だけを残し、それぞれの到着先が本当に用意されているかを確かめます。とくに「デモか試用か迷う人」をどこへ案内するかは、営業や製品担当の受付方法に合わせます。

SaaSの検討段階を、利用場面の把握、担当者によるデモ、自分で試す無料試用、条件相談の四つの次の行動に分ける図 — 検討段階から先に選び、申込前に確認できることを明記する設計例です。

図を自社のページへ変換するときは、各入口に「この行動で確かめられること」と「まだ確かめられないこと」を一つずつ書きます。利用場面のページでは製品が扱う仕事を理解できても、個別の設定可否は判断できないかもしれません。デモでは代表的な操作や質問への回答は得られても、自社のデータがそのまま使える保証にはなりません。試用は操作感を確かめられても、本番の移行や情報管理の全条件を検証できるとは限りません。相談は未確定の条件を整理する場です。入口同士を競わせず、足りない確認へ移れるようにします。

この分岐を販売ページの末尾だけに置くと、機能ページを途中まで読んだ人は見つけられません。機能や利用場面の説明からは「この操作を説明してもらう」「使える範囲を確かめる」へ、料金や導入条件からは「費用と試用条件を確認する」へつなぎます。共通のヘッダーにボタンを二つ並べるだけでなく、読んでいる内容との関係が分かる短い文を添えます。内容が未確認のまま、すべての画面に「無料で始める」を置かないようにします。

デモのページは、見せる内容と参加方法から作る

デモを案内するページには、誰に向くか、どんな画面を見られるか、何を質問できるか、どのような形式かを先に置きます。架空の社内申請サービスなら、「申請者が入力し、承認者が確認する流れを担当者が画面で説明する」という具体的な場面が考えられます。ただし、実際の画面で説明できるか、質問時間を設けるか、録画を渡せるかは運営担当へ確認が必要です。実施していない内容をページ制作側で加えません。

申込フォームで最初から詳細な業務資料を求めるかは慎重に決めます。製品担当者が事前に知りたいのは、見たい業務、参加する役割、現在の検討段階などかもしれません。会社名とメールアドレスだけでは相手の疑問を準備できない一方、デモの可否を判断する前から大量の資料を必須にすると申込が難しくなります。必要な項目を営業担当と照合し、任意で書ける質問欄を設ける方法もあります。

フォーム送信後は、「予約が確定した」のか「日程調整の連絡を待つ」のかを明記します。自動返信、カレンダー招待、担当者からの返信のどれが次の行動か分からないと、訪問者は別のフォームから重複申込をするかもしれません。参加方法、事前準備、日時の変更方法まで確定している場合は案内し、未確定の部分は個別連絡として扱います。デモの終了後に資料を受け取れるか、試用へ進めるかも実際の運用に合わせて示します。

無料試用のページは、始める条件と終わる条件を同じ場所に置く

試用ページには、利用できる機能、人数や容量、期間、準備するアカウントや設定、料金の発生条件を並べます。検討者は「触れるか」だけでなく「自社で評価できる状態を作れるか」を判断したいからです。例えば承認の流れを試すには複数の役割が必要なのに、一人しか試用できないなら、評価できる範囲が変わります。サンプルデータが入っているか、独自データを入れられるかも製品ごとに確認します。

無料試用の終了時も開始前に読めるようにします。アクセスが止まるのか、データを取り出せるのか、有料契約へ自動で変わるのか、終了前に通知するのかは重要な違いです。Microsoftの一般法人向け試用の案内は、同社製品の試用期間、アカウント作成、容量制限、期間後の更新や請求方法を具体的に説明しています。これは他社SaaSにも同じ条件があるという根拠ではなく、「無料」の一語に含まれない条件を自社製品で確認するための例です。

試用を始めるボタンの近くには、対象プラン、必要な準備、支払い情報の要否など、自社で確認済みの条件を短く置き、詳しい試用条件へ進めます。料金表、利用規約、営業資料、試用画面で表現が食い違えば、サイトだけ書き直しても混乱します。条件が変更された際に誰がページを更新するかも決めます。自動更新やデータの保存を扱う記載は、製品・契約担当と整合を確かめてから公開します。

試用を始めた人が最初に確かめる一件を示す

アカウント発行を完了画面のゴールにすると、試用者がログインした後で止まることがあります。販売ページで「何を試せるか」を示したなら、開始直後にも、その確認へ戻れる案内が必要です。架空の社内申請サービスなら、サンプルの申請を一件作り、別の役割で確認するという小さな課題を考えられます。ただし、実際にその環境とサンプルが提供されるかは製品担当が確認します。

「一件を試す」案内には、どの画面から始め、何が表示されたら確かめたといえるかを入れます。多機能な製品でも、最初の画面で全設定を並べるより、申込前のページで約束した確認事項へ進めるようにします。操作が分からないときはヘルプへ、使える範囲が足りないときは相談へ、試用対象外の機能を知りたいときはデモや資料へ行けるようにします。試用者が道に迷った結果を「製品が合わなかった」と誤解しないための案内です。

実データを入れるよう促す場合は、組織の情報管理担当が利用条件を確認できる材料が必要です。ページで安易に「自社データをアップロードしてみましょう」と書くのではなく、サンプルで確認できる範囲と、本番データを使う前に確かめる条件を分けます。データの保存、削除、外部連携、ユーザー招待などは製品の仕様と契約条件に左右されます。Web制作側は、確認先への案内と説明の順番を整え、許可や適合を代わりに判断しません。

フォームと完了画面は、入口ごとに違う約束を返す

デモと試用を一つのフォームへ送るなら、選択した目的が送信内容と担当者の受付に残るようにします。デモ希望者には見たい場面と希望時期が必要かもしれず、試用希望者には利用する部署や管理者の準備状況が必要かもしれません。どちらにも同じ項目を必須にする前に、営業・製品・サポートが実際に使う情報を確認します。まず目的を選ばせ、必要な欄だけ見せる設計もあります。

次は、入口と申込後の案内を対応づける設計例です。必要な入力項目と実際の受付方法は自社の担当者に確かめて置き換えます。

入口	入力・登録時に確認する例	完了後に示す次の一歩
デモ	見たい業務、参加する役割、希望時期	日程調整か予約確定かを明示
無料試用	利用する環境、管理者、対象プラン	初回ログインと最初に試す一件へ
条件相談	未決の費用、移行、情報管理の項目	返答方法と追加資料の案内

ただし、製品から即時にアカウントが発行される試用なら、営業への「申込受付」とは違います。デモ送信後は日程調整、試用登録後は初回ログイン、資料請求後は資料へのアクセスというように、完了画面と通知の次の一歩を変えます。送信完了の文が「お問い合わせありがとうございます」だけだと、訪問者はいつ何が起きるか分かりません。到着先と通知メールを一組で確認し、スマートフォンからも迷わず進めるか試します。

申込後のデータを計測するときも、クリック数をすべて同じ成果に数えないようにします。Google Analyticsの推奨イベントは、情報を請求するフォーム送信の generate_lead と、アカウント登録の sign_up を区別しています。これは自社サイトへ機械的にイベント名を当てる指示ではありません。デモ申込、試用登録、試用内の初回操作、相談への移動を別の行動として定義し、実際に計測できるか検証するための参考です。申込の多寡だけで、試用が役立ったかは判断できません。

デモ後と試用終了前に、次の確認へ戻れるようにする

デモを見た人は、見積や導入相談へ進む前に別の担当者へ説明したいことがあります。試用した人は、操作が合うと分かっても、料金や移行、管理者の設定について質問が残るかもしれません。終了画面やフォローメールには「今まで確認できたこと」「残る条件」「相談先」を分けて置きます。個別の利用状況を推測した決まり文句より、選べる次の行動を分かりやすく示すことが大切です。

先に読んだ導入・運用の記事は、契約後の準備とヘルプの配置を扱います。本稿の境界は、その前に「どの入口で何を確認し、次の検討へ進むか」をWeb上で分かるようにすることです。試用終了をそのまま有料導入と見せず、見積、仕様、契約、データの扱いなど、必要な確認が残る場合はその入口を示します。デモから試用へ進む場合も同じ説明を二度入力させない運用が可能か、営業・製品担当と相談します。

公開前には、現在のサイトで三つの動きをたどってください。「製品を初めて知った人が使う場面を読む」「担当者と画面を見たい人がデモを申し込む」「自分で試したい人が条件を読んで登録する」です。各経路で到着先の見出し、事前条件、フォーム項目、完了後の案内を記録します。申込前に一番重要な条件を見つけられない、送信後に次の行動が分からない箇所が、改修依頼の範囲です。