表紙に対象企業のロゴを置き、最初の一文に社名を入れました。しかし本文は、どの企業にも送る紹介資料と同じです。購買部門が確認する条件、現場のworkflow、セキュリティ確認の根拠も同じ順序のままです。見た目は変わっても、検討の進め方は変わっていません。
ABM文書のパーソナライズは、相手を知っているように見せる装飾ではありません。そのアカウントが今決める問い、確認済みの根拠と残った空欄、次の対話の担当者を変える編集作業です。
社名ではなく意思決定の文脈を個別化する
アカウント別の文書を作る前に、どの判断を助ける文書かを一文で書きます。最初の対話で課題を確認する段階、複数案を比較する段階、運用範囲とリスクを確認する段階では、必要な内容が異なります。
「御社の成長を支援します」のように誰にでも使える文は、アカウントの文脈を作りません。以前の対話で確認した課題、依頼された資料、検討期限、まだ答えていない問いを使います。
社名が入っているかではなく、このアカウントが今この文書を読む理由を説明できるかが基準です。
アカウント仮説を事実と空欄に分ける
ABM文書は仮説から始められますが、仮説を事実のように書くと根拠が弱くなります。作成前に情報を三つに分けます。
- 確認済みの事実: 顧客が直接述べた目標、公開された組織情報、依頼された条件
- 確認する仮説: 事実をもとに、次の対話で確かめる可能性
- 未確認の空欄: 答えを得る前に文書の主張にしない問い
「地域チームごとに異なる会社案内を使っている」と確認できても、「版の混乱が最大の問題」とは書きません。確認できた配布状況を示し、「地域ごとに変える情報と共通に保つ情報は何か」を次の問いにします。
仮説には根拠と確認方法を添え、答えが得られたら文書のどこを変えるかも決めます。
確認できた関係者にだけ検討経路を作る
一つのアカウントでも、役割によって見る問いは異なります。ただし現場、購買、情報セキュリティが常に同じ順序で参加するとは考えません。実際の対話で確認できた役割と問いだけを経路に反映します。
最初の画面に検討目的と主要な問いを置き、必要な区間へ移動できるようにします。現場は業務の流れと変更負担、購買は範囲と条件、セキュリティ担当は確認可能な方針と例外経路を尋ねるかもしれません。役割が未確認なら、組織図を推測して専用区間を作らず、共通の問いとして残します。
CTAも一律にする必要はありません。既知の担当者への質問集約、技術確認の依頼、次回ミーティングの準備など、現在の段階で可能な行動をつなぎます。
共通モジュールとアカウント根拠の境界を示す
会社紹介、製品原則、確認済みの機能は共通モジュールで管理します。アカウントの状況、選んだ根拠、適用範囲、次の問いはアカウント別モジュールに分けます。
個別内容には出典と確認日を残します。公開資料ならURLと基準日を、対話で確認した情報ならミーティング記録をつなぎます。根拠のない効果予測や業界数値で空欄を埋めません。
共通内容を更新したときは、個別の仮説や例外が古い前提に残っていないかを確認します。この境界は、別のアカウントの仮定が混ざることを防ぐためにあります。
個別の例外を別アカウントへコピーしない
アカウントの要望で価格条件、日程、適用範囲、表現を変えた場合は、依頼者、変更内容、有効期限を記録します。
一つのアカウントで承認された例外を、別の文書へコピーしてはいけません。古いロゴ以上に、期限切れの条件や別の顧客の仮定が残ることに注意します。
送付前に共通モジュール、個別例外、受信者、問い合わせ担当者を照合します。改訂版を送った場合は、どの差分を伝えたかも記録します。
閲覧記録は次のアカウント質問を準備するために使う
FeatPaperのリンクでアカウント別文書を共有すると、文書アクセス、ページ閲覧と滞在、再閲覧、リンククリックなどを確認できます。この文書では、アカウント別資料やロゴ、メッセージを自動生成する機能は前提にしません。
再び開かれた区間があっても、関心、承認、購買段階を示すとは限りません。技術範囲のページが再閲覧されたなら、説明不足か、社内共有に必要か、他案との比較中かを次の対話で確かめます。
ABM文書の完成度は、ロゴの正確さだけでは測れません。分かっていることと分からないことを分け、確認済みの関係者が必要な根拠を見つけ、次の対話で空欄を答えに変えられる状態を作ります。
