代理店向けの再現可能なSaaSウェブサイトシステム

概要

SaaSウェブサイトに関するアドバイスの多くは、きれいなスクリーンショットのギャラリーにすぎません。2人目のクライアントに直面すると通用しません。このフレームワークは、インスピレーションを反復可能なプロセスに置き換えます。クライアントを段階分けし、各ページに1つの役割を割り当て、ahaモーメントから機能を構築し、価格設定を意思決定の助けにし、APIドキュメントに売らせます。また、実際の会話からFAQを掘り起こし、デザインをコピーせずに成果物を標準化する方法も学べます。多様なクライアントに品質を届けなければならないエージェンシー向けに設計されたこのガイドは、すべてのエンゲージメントで実行できるシステムを提供します。これを使って、より速く出荷し、品質を一定に保ち、画一的な罠を回避してください。

SaaSウェブサイトに関するアドバイスの多くは、博物館のツアーのようなものです。美しい価格ページがあります。賢いコピーを鑑賞しましょう。FAQレイアウトを研究しましょう。さあ、あなたのクライアントのためにそれをやりましょう。2つ目のエンゲージメントで失敗します。なぜなら、その美しさは企業の段階、市場、コンテンツの深さの産物であり、コピーできるレイアウトではないからです。あなたのエージェンシーにはその逆が必要です。つまり、どんなクライアントにも合い、一貫した品質を生み出し、すべてのサイトを同じ3つのユニコーンブランドの神社に変えない反復可能なシステムです。スクリーンショットのコピーをやめて、プロセスを実行しましょう。

1. スケッチを始める前にクライアントを段階分けする

ワイヤーフレームを開く前に、すべてのクライアントをシード、スケール、エンタープライズのいずれかに分類します。3つのシグナルを使います。チーム規模、顧客数、そして現実的に作成できるコンテンツ量です。顧客10人でロゴグリッドもないシード製品は、エンタープライズサイトではありません。営業サイクルが6か月のエンタープライズ製品は、デモファームのランディングページではありません。コンバージョンするウェブサイトは、クライアントが実際に持つ会社のために構築されるものであって、そうあってほしいと願う会社のためではありません。これは、どんなデザイントレンドよりも重要です。

最初のコールで段階を設定します。誰が買うのか、何人が買ったのか、どのようなコンテンツ資産が存在するのかを尋ねます。先月のサポート量やオンボーディング時間があれば、それも尋ねます。その答えによって、コアの仕事が「証明」「差別化」「統合」のどれであるかがわかります。次に、この表を使ってサイトのコアジョブを選択します。

クライアント段階	サイトの主要な役割	最初に構築するもの
シード	問題解決の適合性を証明	説明ホームページ、デモ動画、1つのCTA
スケール	差別化しトライアルを促進	機能紹介、比較表、トライアルフロー
エンタープライズ	営業の摩擦を取り除く	詳細なAPIドキュメント、セキュリティページ、価格FAQ、営業窓口

シード製品にエンタープライズレイアウトを要求するクライアントには、押し返します。率直に言いましょう。あなたが構築する機能紹介は、訪問者が製品の機能をすでに知っていることを前提としています。シードの訪問者はそうではありません。彼らは10秒以内に問題とメリットを必要とします。代わりにそれを構築しましょう。

実際には、これは段階に合ったページ構造を選択することを意味します。シードのクライアントには単一のCTAを持つ長い説明を、スケールのクライアントには比較表付きの機能グリッドを、エンタープライズのクライアントにはドキュメントへのディープリンクとセキュリティページを提供します。クライアントが実際に持っているものに基づいて調整します。

見栄えがするという理由で「プレミアム」に戻らないように、戦略概要に段階を記録します。あなたは流されるでしょう。創業者はアニメーションを求めるでしょう。営業リードはより派手な機能セクションを求めるでしょう。段階分類があなたのアンカーです。

2. すべてのページに単一の役割を与える

何かを書く前に、構築予定のすべてのページをリストアップし、それぞれに正確に1つの役割を書き出します。そして、正当化できないページは削除します。機能紹介はユーザーエクスペリエンスを示します。価格ページは価値を伝え、購入の意思決定を導きます。FAQセクションはよくある質問に答え、サポート負荷を減らし、信頼を構築します。これらは明確に異なる役割です。それらを曖昧にすると、ホームページが機能を列挙し、価格ページが製品を説明し、FAQが価格を正当化するという、何もコンバージョンしない状態になります。

役割は目標ではなく指示として書きます。「シード段階の訪問者に、製品が10秒で問題を解決することを納得させる」は役割です。「モダンに見せる」は願望です。各ページには1つの主要なアクションがあります。サインアップ、デモのリクエスト、APIの呼び出し、ドキュメントの閲覧などです。ページには補助的なアクションがあっても構いませんが、核心は単一です。

スケール段階のプロジェクト管理クライアントの場合、役割リストは次のようになります。ホームページ — 訪問者に製品が現在のツールを置き換えることを納得させる。機能 — ワークロードビューが時間を節約することを証明する。価格 — チームプランを明白な選択肢にする。ドキュメント/FAQ — 統合の不安を取り除く。採用情報 — 削除、役割なし。会社概要 — 削除、役割なし。これがあなたの契約です。

この役割リストは契約です。スコープクリープを防ぎます。創業者のいとこが属するべきだと思ったからといって、コンバージョンサイトに「会社概要」ページを追加するのを防ぎます。ページに役割がなければ、構築されません。2つの役割があれば、分割されます。ストーリーの中心となるフレームワークは、機能ページがミッションに集中し続けるのに役立ちます。

デザインの前に、役割リストをクライアントに確認させます。彼らは議論するでしょう。させておきます。リストは提案ではなく、プロジェクトの定義です。削除したページごとに予算が節約されます。残したページごとに存在理由があります。役割を明確にできないなら、そのページは必要ありません。

例外が1つあります。ホームページは、「適切な訪問者を適切なページに送る」という2つ目の役割を持てます。しかし、3つの役割を擁護しているなら、ページを削除してください。

3. ahaモーメントから逆算する

機能の棚卸しをやめましょう。ユーザーが製品から初めて実際の価値を得る瞬間から始めます。その瞬間があなたのアンカーです。機能紹介にはビジュアル（スクリーンショット、GIF、動画）が必要ですが、それらのビジュアルが重要でない瞬間に結びついている場合に限ります。設定パネルのスクリーンショットは何も証明しません。ユーザーが最初のプロジェクトを作成し、チームメイトを招待するGIFは価値を証明します。

その瞬間を見つけるには、実際のユーザーを観察します。セールスデモに頼らないでください。画面録画を頼むか、新規顧客に5分間のインタビューを行います。質問します。最初の10分で何をしましたか？「これは使える」と思ったのはいつですか？その答えがアンカーです。

プロジェクト管理クライアントを例に挙げます。彼らのahaモーメントは「ガントチャートがある」ではありません。ユーザーが締め切りを設定し、タイムラインが埋まるのを見て、すぐに過負荷のチームメイトに気づく最初の瞬間です。そのワークフローがハイライトされます。それを支える3つの機能（一括タスク入力、ビジュアルタイムライン、負荷インジケーター）がスクリーンショットを取得します。他の37の機能は、さらに下の検索可能なテーブルに入ります。

ahaモーメントは、どの機能を紹介するかを決定します。シードのクライアントにとって、その瞬間は多くの場合、オンボーディングフロー自体です。サインアップ、データのインポート、価値の確認です。エンタープライズでは、1日1時間を節約するワークフローかもしれません。原則は同じです。その瞬間を支える3つまたは4つの機能を選び、ビジュアルを提供します。それ以外はすべて、検索可能なリストの下に置きます。

エージェンシーは、機能リストを求める方が簡単なので、これをスキップすることがよくあります。やめてください。機能リストは競合他社が持っているものです。ahaモーメントはクライアントが持っているものです。瞬間を捉え、その周りに紹介を構成します。

ahaモーメントをゲートにします。クライアントが製品ウォークスルーへのアクセスを提供できない場合、または実際のユーザーを録画できない場合は、機能ページは推測になると伝えます。ほとんどの場合は誰かを見つけます。見つけない人は、自社製品を理解していない人であり、エンゲージメント全体の警告サインです。

4. 価格設定を意思決定の助けにする

価格ページを「どのプランにする？」という会話を短縮するようにデザインします。つまり、価格のリストだけでなく、比較表と価格FAQが必要です。価格ページは、機能比較表がその価値を発揮する場所です。テーブルはすべての機能を表示する必要はありません。見込み客が実際に比較検討している2つのプランの違いを表示する必要があります。違いがシート数やAIクレジットであれば、それを表示します。選んでほしいプランを強調します。

まずプランの境界から始めます。クライアントに、プランBをプランAより選ぶ理由は何かと尋ねます。通常は、使用制限、チームサイズ、または高度な機能です。それらの違いを、「推奨」プランを視覚的にマークした表にリストアップします。すべての機能を含めるのではなく、決定に関係する機能を含めます。40行のグリッドは研究論文であり、意思決定の助けではありません。

価格FAQは意思決定の助けの一部です。ここに反対意見を置きます。「制限に達したらどうなりますか？」「後でプランを変更できますか？」「無料トライアルはありますか？」これらは購入を妨げる質問です。ページ上で回答し、見込み客が営業電話で立ち止まらないようにします。ステップ6のFAQループを使ってこのセクションを埋めます。

エージェンシーへの警告：プランの違いを発明しないでください。クライアントのプランが価格以外は同一である場合、それは製品の問題であり、ページの問題ではありません。それを暴露することはできます（価格の横に機能比較を置く）が、デザインで消し去ることはできません。構築する前に押し返します。価格ページは交渉ツールであり、クライアントがプラン間の違いを明確にできない場合、ページは罠のように見えます。

エンタープライズの場合、クライアントが公開できるなら、「営業に問い合わせ」の背後に価格を隠さないでください。ページの役割は、価格が公開か非公開かにかかわらず、買い手を賢くすることです。非公開の場合は、エンタープライズに何が含まれ、電話で何をカバーするかを説明します。強力な価格ページフレームワークは、クライアント間で構造を一貫させます。

比較表は、各プランにチェックマークを表示するときに最も効果的です。緑のチェックマークを使って推奨オプションを強調します。その単一の視覚的手がかりが目を導き、意思決定を短縮します。

5. APIドキュメントに売らせる

APIドキュメントをサポートマニュアルではなく、コンバージョン資産として扱います。開発者向け製品の場合、ドキュメントは製品そのものです。Stripe、GitHub、Twilioなどの企業が基準を打ち立てています。技術的な買い手が最初に読むページはホームページではなく「はじめに」かもしれないと彼らは知っているからです。クライアントが開発者向け製品を持っているなら、ドキュメントはセールスページです。

テストを実行します。ドキュメントに従って10分以内にAPIを呼び出してみてください。できない場合、クライアントは多くの技術的な買い手を失います。ドキュメントには、機能するクイックスタート、明確な認証フロー、複数言語のコードサンプルが必要です。クライアントにドキュメントがない場合は、まずクイックスタートガイドを作成します。コンバージョンに完全なリファレンスは必要ありません。ゼロから最初の成功した呼び出しへのパスが必要です。

サイトでは、機能紹介、価格比較、フッターからドキュメントにリンクします。製品がAPIファーストである場合は、メインナビゲーションに「Build」リンクを置きます。これは低労力で高シグナルの作業ですが、技術的なのでほとんどのエージェンシーはスキップします。それがあなたの強みです。APIドキュメントガイドは、コンバージョンに焦点を当てたドキュメントセットに必要な正確なセクションを説明しています。

1つ注意点：可能であれば、ドキュメントを別のドメインに置かないでください。ブランドを維持し、分析を可能にするサブドメインに置きます。どのドキュメントページがサインアップにつながるかを見たいはずです。ドキュメントからトライアルへの経路を追跡できないなら、盲目的に飛んでいるようなものです。

クライアントの製品がAPIファーストでない場合でも、統合に関する質問にはドキュメントが重要です。小さな統合ガイドでさえ、サインアップとチャーンの違いを生む可能性があります。

6. 実際の会話からFAQを掘り起こす

FAQを頭から書かないでください。サポートチケット、営業電話、オンボーディングメールから掘り起こします。調査によると、HubSpot、Slack、Zendeskなどの例では、コンテンツを整理し、検索を追加し、回答を簡潔に保っています。それは、実際の質問に答えているから機能します。最良の情報源は、クライアント自身の会話です。

シンプルなループを設定します。クライアントに先月のサポートチケットのトップ10を依頼します。それらを分類します。反対意見への対応（営業）、使用方法（サポート）、価格（請求）、信頼（セキュリティ、コンプライアンス）です。価格と反対意見のFAQは価格ページに置きます。使用方法と信頼のFAQは、一般的なFAQまたはリソースセクションに置きます。回答は50語以内にします。より深い情報が必要な場合は、完全な回答にリンクします。

各回答を顧客の言葉で書きます。「Googleシートからデータをインポートするにはどうすればいいですか？」と尋ねられたら、「一括インポート機能により移行が可能になります」と書かないでください。「設定に移動し、インポートを選択し、シートを選んでください」と書きます。簡潔で文字通りの方が勝ちます。

これは一度きりの作業ではありません。毎月のレビューを計画します。新しいチケットは新しいFAQになり、古いものはアーカイブされます。ループはFAQページを生きた状態に保ち、サポート負荷を減らします。決して変わらない静的なFAQページは、昨年の問題の記念碑です。

検索機能は譲れません。FAQが10項目を超える場合は、検索ボックスが必要です。検索がなければ、ページはサポート負荷を減らすという役割を果たせません。

エージェンシーはこのループをすべてのクライアントに標準化する必要があります。これはデザインの才能を必要としない反復可能なプロセスです。クライアントにとっては明確な成果物です。あなたにとっては、ローンチ後に連絡を取り合う理由です。

7. 成果物を標準化し、美学は標準化しない

1ページの戦略概要、ページマトリックス、レビューチェックリストという、標準的な成果物パッケージを構築します。すべてのクライアントにこれらを使わせます。ビジュアルデザインはブランドに任せます。エージェンシーの問題はプロセスが少なすぎることではなく、模倣が多すぎることです。テンプレートレイアウトをあるクライアントから次のクライアントにコピーすると、すべてあなたが作ったように見える均質なサイトになります。思考を標準化し、テーマは標準化しないでください。

戦略概要は、段階、ページの役割、ahaモーメントを1ページにまとめます。デザインの前に共有します。ページマトリックスは、各ページ、その役割、そして機能したかどうかを示す1つの指標をリストアップします。マトリックスを使ってスコープを管理します。レビューチェックリストは、よくある間違い（欠落したaltテキスト、整列していない比較表、ファーストビューにCTAがない、検索のないFAQ）を検出します。

成果物を具体的にします。戦略概要は1ページです。それ以上長い場合は、核心を見つけていないことになります。ページマトリックスは毎週更新するスプレッドシートです。レビューチェックリストは、印刷してチェックする文字通りのリストです。これらにはデザインの労力はかかりません。規律がかかります。

このパッケージをすべてのエンゲージメントで実行します。思考が一度で完了するため、チームはより速くなります。チェックリストが同じであるため、品質は一貫します。ブランドのビジュアルアイデンティティが差別化を行うため、クライアントは依然としてユニークなサイトを得られます。

巧妙なトリックは、標準的な成果物を最終デザインから見えないようにすることです。戦略概要は内部ツールです。ページマトリックスは計画ツールです。チェックリストは品質ゲートです。どれも創造性を制約しません。混沌を制約します。

ページマトリックスはまた、リテンションツールになります。ローンチ後、どのページがパフォーマンス低下しているかをクライアントに示し、マトリックスを使って何を修正するかを決定できます。それにより、一度きりの構築が継続的な関係に変わります。

結論

優れたSaaSウェブサイトのギャラリーは、指示ではなくインスピレーションに役立ちます。エージェンシーにはシステムが必要です。クライアントを段階分けする。ページに役割を割り当てる。ahaモーメントから始める。価格設定を意思決定の助けにする。ドキュメントに売らせる。FAQを掘り起こす。成果物を標準化する。それを次のクライアントで実行し、その次も実行します。デザインは毎回異なります。プロセスは同じです。それが、きれいなスクリーンショットのポートフォリオを反復可能なエージェンシーサービスに変える方法です。