インサイドアウトSaaSウェブサイト: 価格とドキュメントを最優先する理由

まとめ

多くのSaaSサイトはホームページを優先して作られるため、結果的に矛盾してしまいます。この記事では、インサイドアウトで構築することを提唱します。製品の実際の制約が存在する価格ページとAPIドキュメントから始め、そこから他のすべてを導き出します。具体的には、6つのステップからなるフレームワークを紹介します。(1)制約を集める、(2)価格ページを骨格として作る、(3)APIドキュメントを製品の表面として扱う、(4)ワークフローから機能紹介を導き出す、(5)実際の会話からFAQを収穫する、(6)一貫性チェックで締めくくる。このアプローチは、異なるクライアント間で再現可能なプロセスを必要とするエージェンシー向けに作られています。また、フレームワークが過剰になる場合と、クライアントの期待を管理する方法についての注意事項も含まれます。

SaaSウェブサイト構築に関するアドバイスのほとんどは逆です。ホームページ（ヒーロー、見出し、製品スクリーンショット）から始めて、価格、ドキュメント、FAQはデザインが承認されたら埋めるページとして扱うよう言います。すると数週間後、見出しの「すべて無制限」という約束と、価格ページの実際の利用制限を調整しなければならなくなります。また、機能セクションはAPIドキュメントにすら載っていないベータ機能を誇らしげに紹介しているのです。その順序がうまく機能するのは、製品が十分にシンプルで調整が不要な場合だけであり、そんなケースはまれです。実際にうまくいく方法は、特にまったく異なるクライアント向けに繰り返し行う場合、サイトをインサイドアウトで構築することです。最も制約が多く、最も華やかさに欠けるページ（価格とAPIドキュメント）から始めて、ホームページ、機能紹介、FAQをそこから生成させます。そのための6ステップのフレームワークをここに示します。また、説明の途中で、不快になる箇所も指摘します。実際にそうなのですから。

この違いを簡単に示すと次のとおりです。この議論の根拠はここにあります。

	ページ優先（最も一般的）	制約優先（このフレームワーク）
どこから始めるか	ホームページのヒーローとビジュアル	価格ページとAPIドキュメント
コピーを動かすもの	ブランドストーリーとデザイン	製品の実際の制限とワークフロー
機能紹介	製品ができることをすべて列挙	実際のユーザーがたどる経路に従う
FAQ	最後に推測で書かれる	サポートと営業から収穫される
公開時の結果	一貫性のない主張、隠れた矛盾	ページが一つの製品として読める

ステップ1 — 何かを書く前に価格ページを読む。

クライアントが機能リスト、ブランドデッキ、デモリンクを渡して、ホームページを依頼します。最初の電話の終わりには、ヒーローのコピーやカラースキームの話をしているでしょう。そのペースを落としてみてください。価格ページとプラン制限を尋ねてみてください。たとえメモだけのGoogle ドキュメントでも構いません。すると、プロジェクト全体が変わることに気づくはずです。

探しているのはハードな制約です。シート（ユーザー数）の意味、データ使用量の計算方法、各プランで利用できる機能、APIの有無と実際にできること。これらの制約が真実の基準です。後で行うすべてのマーケティング上の主張は、それらと接触しても破綻しないものでなければなりません。

典型的なシナリオを挙げます。クライアントはタイムトラッキングツールです。無料プラン、プロプラン、エンタープライズプランがあります。セールスデッキには「あらゆるチームにスケール」とあります。プロページには「無制限のプロジェクト」とあります。しかし、サポートチームはプロアカウントがワークスペースごとに10個のアクティブプロジェクトに制限されていることを確認しており、APIドキュメントにはプロジェクトのメンバーは最大50人と記載されています。誰かがこの問題を解決するまでホームページは書かれません。「無制限のプロジェクト」はもはやコピー上の問題ではなく、法的な問題だからです。ホームページから始めていたら、ヒーローに「無制限のプロジェクト」と書いて、デザインが承認された2週間後に矛盾を発見していたでしょう。制約から始めれば、矛盾は修正コストがゼロの第1週目に表面化します。

このステップでは具体的に何を集めるべきでしょうか。プラン定義と、プランごとの機能比較表。APIドキュメント、またはAPIができることとできないことのリスト。サポートチームの最も一般的な質問（詳細はステップ5で）。セールスデッキ。ただし、セールスデッキは幻想が住む場所であることに注意してください。そして実際の製品。制限が適用される設定ページが見えるように開いてください。製品自体が最終的な権威だからです。「最大10プロジェクト」と書かれた設定画面は、どんなスプレッドシートよりも優先されます。

このステップは成果物を生み出しません。事実のリスト（制限、定義、例外）を生み出し、それに対して他のすべてのページをチェックします。エージェンシーにとって、これは再現可能な仕事と火災対応を分けるステップでもあります。制約を共有ドキュメントに書き出せば、将来のすべてのページ更新が参照する真実の源を構築したことになります。

ステップ2 — 価格ページをサイト全体の骨格として作る。

価格ページは始める場所という感じがしないかもしれません。数字とプラン名が並ぶ表で、サイト上で最も華やかさに欠けるページです。しかし、これは製品とユーザーとの契約であり、サイト全体の情報アーキテクチャが決まる場所でもあります。サイトの役割が、訪問者がサインアップする準備ができるまで教育することであるなら、価格ページはその教育が収束する場所です。購入決定に重要なすべての機能がそこに名前を連ね、重要なすべての制限が明記されるかリンクされます。

タイムトラッキングツールを例に取りましょう。無料、プロ、エンタープライズの3プランあります。表には、製品が実際にどのようにセグメント化されているかを反映した列が必要です。プロジェクト数、統合、レポートの詳細度などです。各セルには、願望ではなく正直な値が必要です。プロに10個のアクティブプロジェクトが含まれるなら、セルには「10個のアクティブプロジェクト」と書き、「アクティブ」の意味と制限に達したときにどうなるかを説明する価格FAQへのリンクを貼ります。ここでの難しい判断の一つは、訪問者に購入してほしいプランについて何を言うかです。多くの価格ページはアンカープランを明確にします。ハイライトし、「最も人気」バッジを付け、その周囲のコピーで、この訪問者に適している理由を説明します。タイムトラッキングツールでは、プロがアンカーです。統合とレポートの詳細度が実際に始まる場所だからです。そのため、訪問者が表を読んで自分で結論を出してくれると想定するのではなく、その理由をページで明示的に説明すべきです。

ここで、サイト全体で正規となる用語を決めるのもこの段階です。製品が価格ページでグループを「ワークスペース」と呼んでいるのに、マーケティングコピーが「チーム」と言っていたら、後続のすべてのページがその不整合を受け継ぎます。価格ページを最初に書くことで、語彙を選ばざるを得なくなります。そして、製品自体が使っている用語を選ぶべきです。製品とドキュメントがそれに合わせる必要があり、マーケティングサイトの方が柔軟に対応できるからです。

価格ページには独自のFAQも必要です。そこに属する質問は、プランの具体的な仕組みに結びついたものです。シートの数え方、ダウングレードしたらどうなるか、請求が年次か月次か、プロジェクトにおいて「アクティブ」が何を意味するかなどです。コンバージョンのために価格ページを構成する実践は確立されており、その仕組みを学ぶ価値があります。しかし、このフレームワーク内では、価格ページの役割はコンバージョンだけではありません。他のすべてのページが従う事実上の決定を確定することです。より深い仕組みを知りたい場合は、SaaS価格ページを改善するためのガイドで詳しく説明しています。

ステップ3 — APIドキュメントをマニュアルではなく製品の表面として扱う。

ある開発者がタイムトラッキングツールを評価しているとします。彼らの会社はタイムシートを給与システムに自動的に取り込む必要があります。ドキュメントはエンドポイントのアルファベット順に整理されています。/projects、/reports、/timesheets、/users。開発者はどの呼び出しから始めればよいか見当もつかず、「認証」セクションは彼らが持っていない知識を前提にしています。ドキュメントでは、設定ページの「統合」でAPIキーを作成することを説明していません。開発者はタブを閉じ、この製品はきれいに統合できないと確信します。しかし、必要な情報はすべてドキュメントに存在していました。ただ、リファレンスマニュアルが使う順序で整理されていただけで、人間が使う順序ではなかったのです。

ワークフローで整理されたドキュメントはその結果を変えていたでしょう。「クイックスタート」「認証」「タイムシートの取得」「プロジェクトの作成」「Webhookと同期」。各セクションはタスクを先頭に置き、その後にエンドポイントを示します。クイックスタートは5分で完了し、成功するAPI呼び出しを生成するかもしれません。これはドキュメント版の無料トライアルです。デベロッパーファーストの製品にとって、これはサイト上で最も説得力のあるページです。

APIを持つSaaSにとって、ドキュメントは意図的に計画したかどうかに関係なく、ウェブサイトのページです。業界のベンチマークは、Stripe、GitHub、Twilioなどが示すように、製品のように読めるドキュメントです。利用可能なエンドポイントだけでなく、開発者が達成しようとしているタスクを説明します。原則は、APIドキュメントは製品体験の一部であり、サイトの他の部分と同じインサイドアウトの論理に従うべきだということです。開発者が達成できるタスクから始めて、仕組みを明らかにします。

エージェンシーにとってのボーナスは、この方法でドキュメントを書くことで制約リストが表面化しやすくなることです。APIが実際にできること、レート制限の場所、欠落しているエンドポイントなど、マーケティングページに現れる前にそれらの矛盾を発見できます。APIドキュメントがこのクライアントのサイトの主要部分である場合、開発者が実際に使うドキュメントの書き方の詳細ガイドがあります。

ステップ4 — 機能リストではなくワークフローから機能紹介を導き出す。

クライアントが40の機能が載ったスプレッドシートをメールで送り、機能ページを依頼してきます。簡単な対応はグリッドです。40項目それぞれにアイコンとキャプションを付けます。結果は包括的に見えますが、ノイズとしてしか読めません。なぜなら、グリッドにはストーリーがないからです。誰もSaaSウェブサイトを訪れてすべての機能を学ぼうとはしません。訪問するのは、この製品が自分が求めているその一つの仕事をこなせるかどうかを知るためです。したがって、機能紹介は機能リストからではなくワークフローから構築すべきです。

例を具体的に進めます。クライアントのサポートチームによると、タイムトラッキングツールの最も一般的な成功パスは、チームリーダーがサインアップし、同僚3人を招待し、プロジェクトを作成し、週末にレポートを実行するというものです。それがワークフローです。機能紹介はそれに従うべきです。チームの招待（シートとロールに関するセクション）、プロジェクトのセットアップ（テンプレートとプロジェクト設定に関するセクション）、レポートダッシュボード（チャートとエクスポートオプションに関するセクション）。各セクションは、製品内のその正確な瞬間のスクリーンショットを表示します。めったに使われない設定パネルの切り抜きではありません。訪問者は自分の経路を見て、その途中で見える機能が自分にとって重要なものです。

続くワークフローとして、少し異なる訪問者向けに、自分ではツールをまったく使わないエグゼクティブがいます。彼らはタイムシートを承認し、週次レポートを確認します。機能紹介には、その訪問者向けのセクションを「マネージャー向け」として最後に追加できます。ストーリーを壊すことなく追加できます。通常、最初は2つのワークフローで十分です。すべてのペルソナに1つずつ必要というわけではありません。

注意点があります。これは実際の注意点です。ワークフローベースの機能紹介には、一般的なワークフローが実際に何かを知る必要があります。これには、PMだけでなく、サポートや営業と話すことが必要です。クライアントが製品の上位3つの使い方を伝えられないなら、それが最初に修正すべきことです。ウェブサイトはそれ以外では推測することになるからです。このステップでは、製品に明確な主要ワークフローがないことが明らかになることがよくあります。それは製品の問題であり、ウェブサイトの問題ではありません。正直に指摘してください。ウェブサイトは存在しないワークフローを製造することはできません。これらのワークフローを体系的に並べる方法については、コンバージョンのための機能紹介の構成に関するこの記事で意思決定の順序を説明しています。

ステップ5 — 想像力ではなく、サポートと営業からFAQを収穫する。

サイト公開の2日前になってもFAQがまだ空です。直感的には午後で10の質問を書きたくなるでしょう。通常、それは実際の顧客が尋ねる質問ではなく、製品に答えてほしい質問です。それは逆です。FAQには特定の役割があります。訪問者とサインアップの間の最後の疑念を取り除くことです。HubSpot、Slack、Zendeskなどの効果的なFAQページは、実際の質問を中心に構成され、検索可能で簡潔だから機能します。それらは発明ではなく傾聴の産物です。

現実的なシナリオを考えます。あなたは価格ページにいて、タイムトラッキングツールの最大の購入障壁が統合であることを知っています。「QuickBooksと連携できますか？」サポートログのレビューによると、これは最も一般的なプリセールス質問です。この質問とその回答は、価格ページのFAQに載せるべきです。2番目に多いのは、営業電話からの「解約したらタイムシートはどうなりますか？」という質問です。これもFAQに載せるべきです。それぞれの回答が販売サイクルを短縮し、サポート負荷を軽減します。回答を文章で見た訪問者は、質問しなければならない訪問者よりも製品を信頼するからです。

エージェンシー向けのルール：サポートチケット、営業電話のメモ、オンボーディングメールを確認するまで、FAQの回答を1つも書かないこと。実際に繰り返される質問は何ですか？それらを入れます。それ以外は機能ページか、どこにも載せません。サイトが発展するにつれてFAQを見直します。新しい価格変更や機能リリースのたびに新しい質問が生まれ、FAQはそれらを捉えるのに最も安上がりな場所です。

FAQの構造についても考える理由があります。内容だけでなく、長くスクロールする質問リストはスキャンしにくいです。カテゴリ（請求、統合、アカウント管理）でグループ化し、上部に目次を置くと、実際に使いやすくなります。リストが一定のサイズを超えたら、検索機能が役立ちます。ここはデザインがコピーと同じくらい重要なページの部分です。検索できないFAQは読まれないFAQだからです。

もう一つ、不快な部分があります。FAQはサイト上で最も正直なページであることがよくあります。訪問者が尋ねるのを恐れる質問に答える唯一のページだからです。答えるのが不快に感じる質問があるなら、「本当にいつでも解約できますか？」「無料プランには広告が表示されますか？」その不快感は、そこに載せるべき証拠であり、外す理由ではありません。訪問者は、あなたが答えなくてもその質問を持っています。答えなければ、彼らは答えを推測し、推測した答えは真実よりも悪いものになるでしょう。

ステップ6 — クライアントに見せる前に、すべてのページで統一しQAする。

完成したサイトをクライアントに見せようとしています。その前に、価格ページと機能ページを並べて開いてください。すべての機能名をチェックしてください。一致していますか？すべての数字をチェックしてください。価格ページが「10プロジェクト」で、機能ページが「最大10プロジェクト」で、APIリファレンスが「最大10」となっていて、すべて同じですか？すべての約束をチェックしてください。「無制限のプロジェクト」がサイトのどこかにありませんか？もしあれば、それは本当ですか？次に、製品自身の語彙を検索してください。どこでも「ワークスペース」と言っていますか、それとも「チーム」に滑っていませんか？ここで、ホームページが「クレジットカード不要」と言っているのに、サインアップフローが実際には無料トライアルでクレジットカードを要求するという矛盾を発見します。これは信頼を殺すまさにそのクラスの不整合です。

インサイドアウトの順序の恩恵はここで現れます。すべてのページが同じ制約から導き出されたため、一貫性の作業は救助任務ではなく検証パスです。しかし、これを省略しないでください。生き残る矛盾は微妙なものです。価格ページでは「承認」と呼ばれる機能がAPIドキュメントでは「レビューフロー」になっている、ホームページのスクリーンショットに製品が出荷していないダークモードのダッシュボードが表示されている、ブランドデッキから来た「リモートチームに信頼されている」という主張がクライアントの実際の顧客リストと一致しない、などです。

実用的なテクニック：制約リストをQAパスのスクリプトにします。すべてのページを確認し、各事実をリストと照合します。これは、制約リストがページが存在する前の第1週に書かれたため、真に独立した情報源だからうまく機能します。デザインや記憶からQAを始めると、作成中に変わった事実を見逃すでしょう。

この時点で、作業を順序付ける理由が明白になります。ページが異なる情報源から並行して構築された場合、このQAパスは毎回矛盾を見つけ出し、それぞれの矛盾は完成したように見えるページの手直しを意味します。ページが1つの制約リストから順番に構築された場合、QAパスはタイプミスを見つけます。それが再現可能なプロセスと絶え間ない危機の違いです。公開後にサイト全体が一つのストーリーを語り続けるために、新機能、新しいチーム、新しいコピーライターには、同じ規律のメンテナンス版が必要です。そして、SaaSウェブサイトのストーリーをページ間で統一するフレームワークが自然な次のステップです。

このフレームワークを正直に保つための注意点。

このフレームワークが主張しないことが3つあります。まず、APIがなく、単一プランで、明らかなユースケースが1つしかない非常に初期段階のSaaSでは、順序の重要性ははるかに低くなります。そのようなサイトはどの順序で構築しても、調整作業は簡単です。このフレームワークが効果を発揮するのは、実際の複雑さがある場合です。複数のプラン、API、多数の機能、複数のオーディエンスなどです。本質的にサインアップボタン付きのランディングページである製品に、教義として適用しないでください。

第二に、インサイドアウト構築は、最初の目に見える進捗が遅いです。クライアントはホームページを依頼したのに、あなたは価格表と制約ドキュメントを納品しています。彼らは反発するでしょう。ホームページは投資家や自社チームに見せられるものだからです。その期待を管理すること、つまり価格ページの決定が下流のすべてを形作ることを示すことは、仕事の一部であり、失敗ではありません。勢いを維持する一つの方法は、初期に大まかなホームページモックアップを作成し、コンテンツを待つコンテナであると明確にラベル付けすることです。そうすれば、骨格を構築している間にクライアントは目的地を見ることができます。

第三に、制約リストは変化します。価格は変更され、APIは成長し、プランは増えます。このフレームワークは、公開後に制約ドキュメントを最新に保つことを前提としています。ウェブサイトが製品の実際の制限を反映しなくなった瞬間に劣化するからです。これがインサイドアウトアプローチのメンテナンスコストです。真実の源は、誰かがそれを所有している場合にのみ真実であり続けます。

結論。

SaaSウェブサイトプロジェクトで最も一般的な失敗は、弱いコピーや悪いデザインではありません。ページ同士が互いに矛盾していることです。それらが間違った順序で構築されたからです。製品の実際の制約が存在する価格ページとAPIドキュメントから始めてください。実際のワークフローから機能紹介を導き出し、実際の会話からFAQを収穫し、救助ではなく検証する一貫性パスで締めくくってください。これを複数の異なるクライアントで行えば、これが創造的なプロセスというよりも組み立てラインに近いことに気づくでしょう。エージェンシーにとって、それはまさに望ましいことです。創造的な仕事は依然としてそこにあります。ただ、最もレバレッジが効く場所に適用されているだけです。