事例集を読み終えた人には、提案書を見せるべきでしょうか。それとも料金案内を先に見せるべきでしょうか。多くのチームは、この問いをボタン文言の問題に置き換えます。「詳しく見る」より「見積もりを依頼」のほうがよいか、と考えるのです。しかし、クリック後の資料が読者に残った問いと合っていなければ、文言が明確でも検討は続きません。
資料の終わりは、行動を急がせる場所ではありません。ここまでに答えた問いと、まだ残っている問いをつなぐ場所です。次の資料は、営業段階の順番ではなく、読者が判断を続けるために必要な根拠で決めます。
今の資料で答えた問いから書き出す
事例集は「似た組織でもこの課題を解決できるか」に答えるのに向いています。提案書は「自社の状況には、どの範囲と進め方が合うか」を扱い、料金案内は「検討できる費用構造か」を確かめる資料です。同じ名称の資料でも、実際の役割はチームによって異なります。
経路を設計する前に、今の資料を一文で要約します。「この資料は、読者のどの判断を助けるのか」。答えが曖昧なら、次の資料も選びにくくなります。一つの資料が事例、実行方法、料金を浅く扱っているなら、読者が必要としているのは追加の要約ではなく、どれか一つの深い根拠かもしれません。
残った問いを一つ選び、行き先を決める
実務で使いやすい基準は、「この資料を読んだあとに残る最も大きな問いは何か」です。事例集の次に必ず提案書が来るわけではありません。導入負担が心配なら運用手順や技術案内が先かもしれません。予算範囲が論点なら料金案内が自然です。社内説明が必要なら、より具体的な事例が適しています。
したがって、「事例集 → 提案書 → 料金案内」は一例であって標準経路ではありません。同じ事例集でも、初回商談後に営業担当者が送ったのか、Webサイトの訪問者が自分で見つけたのかで残る問いは変わります。流入の文脈ごとに代表的な経路だけを用意し、実際の出発点から選びます。
選択肢を絞り、移動する理由を明確にする
事例集の最後に、提案書、料金表、会社案内、ニュースレター、相談予約をすべて置くと、読者は優先順位をもう一度計算しなければなりません。基本経路は一つにします。性質の異なる直接行動が本当に必要なときだけ、補助の選択肢を分けます。
「提案書を見る」は行き先を示しますが、移動する理由までは説明しません。「自社に適用する範囲を確認する」と書けば、次の資料が答える問いが見えます。料金案内も「料金を見る」より「予算検討に必要な範囲を確認する」のほうが、今の判断につながります。文言は強く説得する装置ではなく、行き先で分かることを約束する標識です。
クリック直後にその約束が守られているかも確認します。次の資料のタイトルと冒頭がまったく別の問いを扱っていれば、移動の途中で文脈が失われます。これは一つの資料内を案内する目次とは異なり、別々の二つの資料が同じ判断を続けているかを見る作業です。
経路ごとに運用の一文を残す
複雑なフロー図より、四つの欄があれば十分です。今の資料、答えた問い、残った問い、次の行き先です。担当者と再確認の条件も加えると、資料が変わったときに誰へ聞くかが分かります。
たとえば、「製造業の事例集 / 類似組織での適用可能性 / 自社の範囲と日程は何か / 提案範囲の案内 / 担当：営業オペレーション」と記録できます。提案範囲が変わったり、新しい事例が追加されたりしたら、担当者が接続の妥当性を見直します。リンクが開くことと、経路が今も有効であることは同じではありません。
行き先の資料が廃止されたり役割が変わったりしたら、接続も直します。新しい資料ができるたびに追加するのではなく、残った問いにより正確に答えるかを比べ、必要なら一つを置き換えます。この記録はリンク一覧ではなく、読者の判断が続く理由を残すものです。
移動は意向ではなく、次の会話の文脈である
資料間の移動を購入意向と断定してはいけません。クリックや閲覧は次の資料が必要だった可能性を示す観察信号にすぎず、予算、権限、契約可能性の証拠ではありません。フォローアップする経路なら、担当者はまず何の問いが残ったのかを確かめて会話を始めます。
最後に残すべきなのは強いCTAではなく、一行の接続です。「この資料はこの問いに答え、次の資料はまだ残っているあの問いに答える」。この文が自然なら、読者は売り手が決めた順番ではなく、自分の検討を続けられます。
