SaaS FAQページは、エージェンシーが見落としているコンバージョンの原動力

まとめ

ほとんどのSaaS FAQページはサポートチケットから構築されています。つまり、すでに購入した人からの質問に答えている一方で、見込み客の購入を妨げる反論を無視しています。この記事は、FAQをローンチ後の後付けから販売資産へと変えます。複数のクライアント向けにサイトを構築するエージェンシー向けに書かれており、繰り返し使えるプロセスを説明しています：営業チームから反論を集め、質問を購入段階ごとにグループ化し、検索を終わらせるのに十分な完全な回答を書き、各反論に具体的な社会的証明を組み合わせ、四半期ごとにページを維持します。神話対現実の形式は、実際に効果のあるものを示し、各セクションに実用的な例があります。その結果、FAQページはサポート負荷を減らし、見込み客がサインアップする可能性を高めます。

SaaS FAQページに関するほとんどのアドバイスは、間違った場所から始まります。それは、FAQをローンチ後のクリーンアップとして扱います—サポートチームが繰り返し説明しなくて済むように、サポートチケットへの回答を置く場所と見なします。その枠組みが、クライアントのFAQページがビジネスにほとんど貢献していない理由です。実際に効果があるのはこれです：FAQページは、見込み客が購入するかもしれないと決めた後に訪れる数少ないページの一つです。それはドキュメントページではなく、意思決定段階のページです。訪問者とサインアップの間に立ちはだかる反論を取り除くために構築されるべきであり、価格設定ページと同じ戦略的な注意を払う価値があります。

もしあなたがエージェンシーにいるなら、問題はさらに深刻です。各クライアントは異なります：異なる製品、異なる購入者、異なるサポート履歴。それでも、毎回ゼロから始めることなく機能するものを生み出さなければなりません。誘惑は、最後に作ったFAQの構造をコピーすることです。それは機能するまで続きますが、フィンテックのクライアントにとって重要な反論は、チームコラボレーションのクライアントにとって重要なものとは異なるため、機能しなくなります。フレームワークは同じでなければならず、コンテンツは異なる必要があります。以下の誤解を解くことが、そのフレームワークです。その根底にあるパターンはシンプルです：FAQに情報を提供するだけでなく販売することを期待します。それによって、質問の集め方、グループ化の仕方、各回答の長さ、そしてその隣に置くものが変わります。

サポートチケットではなく販売から始める

まず、クライアントの営業チームに、最近停滞した5つの取引を尋ねてください。それらの取引を停滞させた質問は、FAQページが最初に答えるべき最初の10の質問です。ほとんどのFAQページはサポートチケットから構築されています—すでに購入した人からの質問です。実際に販売を妨げる質問は、まだ購入していない人から来るもので、移行、セキュリティ、価格設定、トライアル終了後に何が起こるかについてのものが多い傾向があります。

実際にはこうなります。ワークフロー自動化のクライアントが、「パスワードをリセットするにはどうすればよいですか？」や「どのブラウザがサポートされていますか？」といった質問でいっぱいのFAQを持ってきました。そのページは技術的には有用でしたが、商業的には不活発でした。そこで営業チームに、失った取引で何を聞いたか尋ねました。すると、見込み客が、そのツールが現在のスプレッドシートを置き換えられるか、移行にITが必要か、営業担当者の価格表が実際の請求と一致するかどうかを尋ねていたことがわかりました。その3つの反論を中心にFAQを再構築し、それぞれに短い回答と関連ページへのリンクを付けました。パスワードリセットの質問はサポートセンターに移しました。そのページはヘルプデスクではなく、成約ツールになりました。

このインタビューを行うとき、「価格について尋ねる」で満足しないでください。正確な言葉を尋ねてください。「価格はユーザーごとですか、ワークスペースごとですか？」は実行可能です。「価格について尋ねる」はそうではありません。また、競合他社がクライアントが簡単には真似できないことを何をしているかも尋ねてください。それによって、営業チームが聞き飽きている反論が浮き彫りになることがよくあります。それらをページの一番上に置いてください。

これは、SaaSウェブサイトを内側から構築することが報われる場所の一つです：実際の購入者が尋ねる質問から始めて、その周りにサイトを構築します。注意点は、サポートの質問を完全にスキップできないことです。一部の訪問者は既存の顧客です。しかし、ページの主要な場所は購入前の質問に使うべきです。サポートの質問をページに残す必要がある場合は、明確にラベル付けされた「既存のお客様」見出しの下の一番下に移動してください。そうすれば、サポートの質問が支配的になることなく、両方のオーディエンスにサービスを提供できます。インタビューを行う効果的な方法は、営業チームに簡単なプロンプトを送ることです：先月、見込み客から手動で答えなければならなかったすべての質問をリストアップしてください。2つのリストが得られます。判断が必要な質問はFAQの材料であり、リンクで答えられる質問はドキュメントに属します。

長さは網羅性ではない

保持する価値のある原則は、位置による関連性です。無料トライアルを3分間使用している訪問者と、ツールを評価している調達担当者では、質問が異なります。FAQが単一のアルファベット順リストの場合、調達担当者は「アバターを変更するにはどうすればよいですか？」をかき分けて「データの保存場所はどのように扱われますか？」を見つけなければなりません。ほとんどの訪問者はそうしません。彼らは去ってしまいます。

あるクライアント（プロジェクト管理SaaS）のFAQはアルファベット順で数ページにわたっていました。それを「開始する前」（機能、比較）、「トライアル中」（設定、制限）、「購入」（価格、請求、セキュリティレビュー）、「購入後」（請求変更、サポート）の4つのバケットに再グループ化しました。購入バケットを最初に置きました。そこがお金が失われていた場所だからです。語数はあまり変わりませんでしたが、ページはリストからガイド付きパスになりました。

各バケット内では、2つの順序ルールのいずれかを使用します。製品に明確な購入方法がある場合は、重大度で並べます：取引を完全に止める質問を最初にします。製品に明確な順序がない場合は、頻度で並べます—ただし、ページ全体ではなくバケット内でのみです。重要なのは、訪問者がすべてを読まなくても気になる質問を見つけられることです。ページの上部にアンカーリンクを配置して、調達担当者が「購入」に直接ジャンプでき、トライアルユーザーが「トライアル中」にジャンプできるようにします。典型的なSaaSサイトでは、これらは最も多くのサインアップと最も多くの失注を生み出す2つのグループであるため、ページの上部に配置されます。

特に価格設定の質問については、コンバージョン向けに構築された価格設定ページに適用するのと同じロジックがFAQ内にも適用されます：意思決定に関連する詳細を最初に置き、次に根拠、そしてリンクを置きます。訪問者に希望するプランの価格を探させないでください。また、購入バケット内では、順序をもう一度考えてください。セキュリティとコンプライアンスを支払い方法の前に置いてください。セキュリティレビューは、支払いの質問が発生する前に評価を止めるゲートキーパーになることが多いからです。

誤解	現実
FAQは質問に答えるために存在する	FAQは購入の反論を取り除くために存在する
長いFAQはより網羅的である	スキャンしやすくグループ化されたFAQは長いリストより性能が良い
回答は短くあるべき	回答は検索を終わらせるのに十分な完全さを持つべき
社会的証明はホームページだけに属する	反論の隣に置かれた証明はより良くコンバージョンする
FAQはローンチ時の成果物である	FAQはレビューサイクルを持つ生きた文書である

短すぎる回答のコスト

クライアントが「長い」回答に抵抗したときに私たちが使うビフォーアフターをご紹介します。

ビフォー：「SSOをサポートしていますか？はい、サポートしています。」

アフター：「SSOはProプラン以上で利用できます。ワークスペースの所有者であれば、設定 > セキュリティから有効化できます。ステップバイステップガイドはこちらです。OktaまたはAzure ADを使用している場合は、両方ともサポートされています。」

2番目の回答は長いですが、最終的でもあります。訪問者は、回答がフォローアップの質問を予測しているため、検索をやめます。このような書き方は単純に見えますが、フォローアップの質問が実際に何であるかを知る必要があります。それらを見つける最も簡単な方法は、各機能領域の上位サポートチケットを調べて、回答をFAQに組み込むことです。

使用する構造は次のとおりです：直接の回答、文脈の1文、そしてリンク。直接の回答を太字にして、スキマーがすぐに見えるようにします。スクリーンショットがある場合は、文脈の後に置いて、前には置かないでください。機能を説明する段落に回答を埋め込まないでください。これは、StripeやTwilioのような企業のAPIドキュメントが際立つのと同じ原則です：たどり着いて、答えを得て、去ることができます。この基準については、開発者が実際に使うSaaS APIドキュメントの書き方のガイドで詳しく説明しています。注意点は、「完全」が「それ自体のために長い」ことを意味しないことです。テキストの壁は依然としてテキストの壁です。

トーンに関する問題もあります。短すぎる回答はそっけなく、失礼に聞こえる傾向があります。長すぎる回答は防御的に聞こえます。最適なポイントは、有能なサポート担当者がメールで提供する回答です：直接の応答、短い説明、そして次のステップ。クライアントのサポートチームが役立つメールを書いているなら、いくつか頼んでモデルとして使用してください。そうでない場合は、自分でモデルを書いてサポートチームに修正してもらうことができます。それもサポートチームからの賛同を得る良い方法です。なぜなら、FAQが企業の文書ではなく、彼らの最高のメールのように見え始めるからです。

反論とその証明を組み合わせる

クライアントのFAQのすべての反論を取り上げて、一つ質問してください：どの社会的証明がこれを無効にするでしょうか？電子署名のクライアントは、ホームページに強力な推薦文セクションを持っていました。しかし、FAQのセキュリティ質問—「私の文書をどのように安全に保ちますか？」—を見たとき、回答は堅苦しいコンプライアンス用語でした。法務チームからの「コンプライアンスチームは1日以内に承認しました」というホームページの推薦文は、まさにその回答が必要とする安心感でした。

私たちは各反論に証明を組み合わせ始めました：セキュリティ質問にはコンプライアンスの推薦文、価格質問には競合他社から乗り換えた顧客の引用、移行質問にはダウンタイムなしで会社全体を移行した顧客に関する一文。FAQは独立したページではなくなり、ピッチの一部になりました。

ここでの注意点は関連性です。FAQの近くのロゴウォールはほとんど価値を追加しません。反論に直接対処する推薦文は、特にそれを与えた人の役割が述べられている場合、重みを持ちます。クライアントがまだそのような証明を持っていない場合は、反論を生み出すのと同じ営業通話から収集し始めてください。2つの資産は同じソースから来ています。推薦文がある場合は、FAQの質問に一致する節を抽出してください。完全な引用は必要ありません。具体的な一文で十分です。営業チームに、取引が成立したときに、顧客が特定の懸念に言及したかどうかをメモするよう依頼してください。その懸念は将来のFAQの質問であり、顧客自身の言葉がその最良の回答です。

2つ目の、あまり明白ではない種類の証明があります：製品の証拠です。見込み客が「データをエクスポートできますか？」と尋ねた場合、最も強い回答にはエクスポート画面のスクリーンショットが含まれます。「はい」という文だけではありません。「トライアルはどのくらい続きますか？」と尋ねられた場合、最も強い回答には終了時に何が起こるかについての行が含まれます。スクリーンショットと短いGIFは、主張する代わりに見せるため、ここで効果的です。また、ここがFAQと機能紹介をつなぐ場所でもあります：「これはスプレッドシートとどう違うのですか？」のような質問は、比較テキストの壁ではなく、違いを示すサイトのセクションにリンクするべきです。

FAQはプロセスであり、ローンチ時の成果物ではない

エージェンシーにとっての永続的な原則は、FAQページはページではなくプロセスであるということです。クライアントの製品は毎月変わります。新しい反論は、価格変更、新しい競合他社、四半期ごとに現れます。1月にローンチしたページは、3月には推測になります。これを繰り返し可能にするエージェンシーは、エンゲージメントに軽量なメンテナンスサイクルを組み込みます。

ローンチ後、四半期ごとのレビューを設定し、3つの入力を確認します：新しいサポートチケット、営業通話からの質問、製品の変更。レビューを2つのステップに分けます。最初に、もはや重要ではない質問を削除します。次に、過去90日間に現れた質問を追加します。これにはコンテンツストラテジストは必要ありません。習慣が必要です。

私たちはあるクライアントのためにこれを実施しました。サポートリードに、ウェブサイトで答えられた可能性のあるチケットにタグを付けるよう依頼しました。数四半期後、サポートリードは私たちが尋ねる前に、繰り返し発生する質問のリストを送り始めました。FAQは共有プロジェクトになりました。それが関連性を保つ唯一の方法です。複数のエンゲージメントでこの種の仕事を実行しているエージェンシーにとって、FAQを繰り返し可能なSaaSウェブサイトシステムの一部として扱うことが、毎回プロセスを再発明せずに品質を一定に保つ方法です。

レビューは1時間以上かかる必要はありません。サポートチケットに15分、営業の質問に15分、製品の変更に15分、ページの更新に15分。コンテンツ保守を請求する場合、それは継続的な収益ラインになります。そうでない場合でも、ページが古くなるのを防ぎます。数値を付けることができなくても、注目に値するメトリクスが1つあります：サポートチームが同じ質問の数を減らしたと報告するかどうか。サポートチームがFAQに載っている質問に答えなくなったとき、それは勝利であり、通常、ダッシュボードに表示される前にチームのトーンに見えます。サポートチームが新しいFAQエントリを提案し始めたら、メンテナンスプロセスが根付いたことがわかります。

これには再設計や新しいツールは必要ありません。必要なのは、クライアントとのFAQの話し方を変えることです。プロジェクト計画で「FAQ」と呼ぶのをやめて、「反論ページ」と呼び始めてください。その1つの変更が、集める質問から書く回答まで、その後のすべての決定を再形成します。また、ページを維持する必要性を主張するのがずっと簡単になります。なぜなら、反論を先回りして防ぐ必要性に異議を唱えるクライアントはいないからです。