顧客インタビューを終えると、「業務が効率化した」「顧客の理解が早まった」「フォローしやすくなった」といった、記事に使いたくなる言葉が集まります。目を引く数値もあれば、初稿はたちまち説得力のある記事に見えます。

しかし、公開前に確認すべきなのは別の点です。何を基準に測ったのか。製品を実際にどう使ったのか。顧客が確認した内容なのか、それとも自社側の解釈なのか。引用や数値が多くても、根拠とのつながりが見えなければ、信頼できる事例にはなりません。

「成功」という結論より、変化の順序を書く

導入事例に大がかりな構成は必要ありません。導入前の状況から始め、解決したかった課題を絞り、顧客が実際に使った機能と運用方法を説明します。そのうえで、観察された変化、顧客の評価、今も残る条件を分けます。

「提案書の運用を改善した」だけでは、状況が分かりません。「複数の担当者が同じ紹介資料を繰り返し送り、送付後に実際の確認状況を把握しにくかった」と書けば、出発点が見えます。続いて、どの資料をどう変えて配布し、どの期間のどの記録を比べたのかを示します。

この順序なら、読者は成功を信じるよう求められるのではなく、課題から施策、結果までを自分でたどれます。

原稿を5種類の記述に分ける

公開前の編集では、各文を次のいずれかに分類します。根拠のない表現や強すぎる表現が見つけやすくなります。

  • 製品に関する事実: 当時提供され、顧客が実際に使った機能
  • 一般的な助言: ほかの場面にも応用できるが、この顧客の成果ではない編集上の提案
  • 顧客の発言: インタビューや確認プロセスで顧客担当者が認めた評価
  • 成果に関する主張: 数値や観察記録で確認できる変化
  • 法務・比較表現: 「業界初」「唯一」「完全」など、別途確認が必要な断定表現

「顧客が理解しやすくなった」という文も、出所によって種類が変わります。顧客がインタビューで話したなら顧客の発言です。閲覧時間が延びた記録から編集者が推測したなら解釈です。同じ事実として扱うことはできません。

カレンダー、定規、グラフ、承認印が入った根拠のトレーと、雲の形をした解釈のトレーを分けて置いたシンプルな静物スケッチ

数値には測定条件も添える

成果指標には、期間、比較対象、対象範囲、指標の定義が必要です。導入前後を比べたなら、どの版と期間を使ったのか。平均値なら、どの資料・閲覧データを含めたのか。一部ページの変化を、文書全体の成果として広げていないかを確認します。

複数の変更を同時に行った場合は、原因を一つに決められません。文書構成を変え、デモ動画を加え、問い合わせリンクも設置した後に変化が表れたとしても、確認できるのは 複数の変更後に観察された結果 です。動画やCTAだけの効果は、別の検証なしには分かりません。

十分な数値がない場合は、定性的な事例としてまとめても構いません。どのような課題があり、何を変え、現場の会話がどう変わったのかを正確に書くほうが、測定条件の曖昧な割合を大きく掲げるより有用です。

FeatPaperでは、根拠と次の質問をつなぐ

確認を終えた導入事例は、FeatPaperのリンクで共有できます。Figmaプラグインで制作する資料では、確認済みの範囲で動画や外部フォーム、日程調整ウィジェットをつなぎ、製品の利用プロセスや次のアクションを関連する説明の近くに配置できます。

ただし、インタラクションは根拠の代わりにはなりません。動画を載せても顧客発言の公開許可が得られるわけではなく、閲覧時間が長くても事例の主張が証明されるわけではありません。訪問数、ページごとの閲覧時間、再閲覧したページ、リンククリックは、読まれ方を示す観察記録です。

特定の章が繰り返し読まれていても、「特に説得力があった」と結論づけるのは早計です。重要だったのか、説明が分かりにくかったのかを次の対話で確かめます。閲覧データは相手を評価する点数ではなく、質問を具体化する補助材料として使います。

公開承認は、文面だけでなく公開範囲まで確認する

最終確認では、顧客名とロゴ、担当者の氏名と役職、直接引用、成果指標、製品画面をそれぞれ確認します。匿名事例でも、社名を消すだけでは顧客が特定される可能性があります。業種、規模、地域、プロジェクト名などの手掛かりも見直します。

指標の算出方法と承認者も記録します。事例がどの時点の製品と運用を扱うのか基準日を残し、機能や顧客の状況が変わったときに再確認する項目を決めます。承認とは原稿全体への一度きりの許可ではなく、公開する要素と根拠の範囲を一つずつ合わせる作業です。

公開前の確認事項

  • 課題、施策、観察された変化が時系列でつながっているか
  • 製品の事実、顧客の発言、成果の主張、編集側の解釈を分けているか
  • すべての数値に期間、比較対象、対象範囲、指標の定義があるか
  • 複数の変更後の結果を、一つの機能の効果として書いていないか
  • 氏名、ロゴ、引用、数値、画面の公開範囲を個別に確認したか
  • 閲覧データを成果の証明ではなく、次の質問の手掛かりにしているか

良い導入事例は、すべての空欄を成功談で埋めません。確認できた事実と顧客の評価、観察された結果と自社側の解釈、適用条件と限界を分けて示します。読者に「自社でも同じ結果が出る」と思わせるのではなく、自社の状況と何が同じで何が違うかを判断してもらう。それが長く使えるBtoB導入事例の条件です。