BtoBマーケティングにおいて、導入事例は最も信頼される形式の一つだ。多くの企業が事例記事の制作に力を入れている。取材を依頼し、顧客に時間をもらい、記事を仕上げて公開する。その工程は決して軽くない。
にもかかわらず、営業チームに「最近の事例記事、商談で使っていますか」と聞くと、返ってくるのは沈黙か、「あることは知っているけど、探すのが面倒で」という言葉だ。
事例記事が使われないのは、記事の品質が低いからではない。制作プロセスそのものに、営業が使うための設計が入っていないからだ。
要因1：記事のフォーマットが商談の文脈に合っていない
事例記事の多くは、オウンドメディアの読者を想定して書かれている。SEOを意識したタイトル、導入文、見出し構成。読者が検索経由で辿り着き、課題に共感し、問い合わせに至る——その導線のために最適化されている。
だが営業が商談で使いたいのは、そのフォーマットではない。商談の場で必要なのは「この企業と似た状況の会社が、何をどう変えて、どんな結果を得たか」を30秒で伝えられる情報だ。3000字の記事を商談中に読み上げる営業はいない。
ここに最初のズレがある。マーケが作る事例記事は「読まれるための記事」であり、営業が求めているのは「話すための素材」だ。目的が違うのに、同じ成果物で両方を満たそうとしている。
なぜこのズレが放置されるのか。理由は、事例記事の制作がマーケの業務として完結しているからだ。マーケの成果指標はPVや問い合わせ数であり、営業が商談で使ったかどうかは測定されない。使われなくても、マーケの指標には影響しない。だから改善の動機が生まれない。
要因2：「営業が使う」フローが制作プロセスに存在しない
事例記事の制作プロセスを分解すると、多くの場合こうなる。
- 取材先の選定
- 取材依頼と日程調整
- 取材の実施
- 原稿の作成
- 顧客への確認依頼
- 修正と公開
このプロセスに「営業向けの素材を作る」ステップは入っていない。公開がゴールであり、公開した後に誰がどう使うかは制作プロセスの外側にある。
これは品質の問題ではない。プロセスの設計の問題だ。
取材で得られた情報は、記事にするだけではもったいない。顧客が語った課題の具体性、導入前後の変化、担当者の言葉——これらは営業にとっても価値の高い素材だ。だが記事として整形される過程で、営業が使いやすい粒度の情報は文脈に溶け込み、取り出せなくなる。
取材の段階で「営業が商談で使う」ことを前提に情報を整理すれば、同じ取材から2つの成果物——記事と営業用サマリー——を作ることができる。だが制作プロセスにその前提がなければ、記事しか生まれない。
要因3：事例を「探す」コストが高すぎる
仮に営業が事例を使いたいと思っても、次の壁がある。「どの事例が、いまの商談に使えるか」を探す手段がないのだ。
事例記事はオウンドメディア上に時系列で並んでいる。タグやカテゴリで分類されていることもあるが、営業が必要とする軸——業種、企業規模、課題の種類、導入製品——で絞り込める構造になっていないことが多い。
営業の時間は限られている。商談準備に使える時間は短く、その中で「事例記事を読んで、使えそうなものを選んで、要点を抜き出す」作業をするのは現実的ではない。結果として、営業は事例を使わないのではなく、使えないのだ。
この問題の根は、事例の管理がコンテンツ管理に閉じていることにある。記事として管理されているから、CMS上で時系列に並ぶ。営業が使うためには、コンテンツとしての管理とは別に、営業用の事例データベースとして構造化する必要がある。だがその構造化を誰がやるのかが問題になる。マーケは記事を公開した時点で仕事が終わっており、営業には記事を構造化するスキルも動機もない。
考え方の転換：1つの取材から2つの出口を設計する
3つの要因に共通しているのは、「事例記事は公開するためのものだ」という前提だ。この前提を変える。
事例記事の制作プロセスを「1つの取材から、2つの成果物を作る工程」として再設計する。
1つ目は従来通りの記事。検索経由で読者が辿り着き、課題に共感し、問い合わせにつながるもの。
2つ目は営業用の事例サマリー。業種、課題、導入前の状態、導入後の変化、顧客の一言——これらを定型フォーマットに収めたもの。A4一枚、あるいはスライド1枚に収まる粒度だ。商談の中で30秒で概要を伝えられる形にする。
この2つを同時に作るには、取材の段階で「営業が使う情報」を意識して聞き出す必要がある。具体的には、以下の情報を取材で必ず押さえる。
- 導入前に何に困っていたか（課題の具体性）
- 導入の決め手は何だったか（選定理由）
- 導入後に何が変わったか（変化の具体性）
- 他社に勧めるとしたら何と言うか（推薦の一言）
これらは記事にも使える情報だが、営業用サマリーでは「そのまま引用できる粒度」で抜き出す。記事では文脈の中に埋め込まれる情報を、サマリーでは箇条書きで取り出すのだ。
事例の構造化は制作工程の延長で行う
営業用サマリーを作る工程を加えると、制作コストが増えるように見えるが、実態はそうならない。
記事の制作過程で、取材内容はすでに整理されている。文字起こし、要約、構成——これらの工程で、サマリーに必要な情報はすでに手元にある。記事を書いた後に情報を再抽出するのではなく、記事を書く過程で同時にサマリーのフォーマットに落とし込む。追加工程ではなく、既存工程の出力を1つ増やすだけだ。
事例を業種・課題・規模で引けるようにする構造化も、制作時に行う。公開後に遡って分類するのではなく、制作工程のチェックリストに「属性の記入」を加える。記事のメタ情報として業種・課題・規模を付与すれば、後から検索や絞り込みができるようになる。
「使われない事例」は資産の毀損である
事例記事の制作は、顧客の時間をもらう工程を含む。取材を依頼し、確認を依頼し、承認をもらう。その労力に見合う価値を引き出すには、記事として公開するだけでは足りない。
営業が商談で使い、見込み顧客が「自社と同じ状況の企業が成功した」と実感する——そこまで届けて初めて、事例の価値が実現する。
事例記事の課題を「記事の品質」に求めるのは表層だ。品質を上げても、営業が使うフローがなければ使われない。使われない事例は、どれだけ丁寧に作っても資産として機能しない。
制作プロセスに「営業が使う」設計を組み込むこと。それが事例記事を資産に変える起点になる。
実際に事例記事から営業が商談で使えるサマリーを作る手順は、事例記事を営業が商談で使える形に変えるChatGPT活用法で解説している。
