事例を公開して営業へURLを知らせても、必要な人に届くとは限りません。相手が何に困っているか分からないまま「事例ができました」と送っても、読むきっかけが作れないためです。紹介するときは、その事例のどの話が相手に関係するかを添えます。
Web、メール、商談資料で、同じ文章をそのまま使う必要はありません。本文の意味と掲載条件を保ちながら、受け取る場面に合わせて入口を変えます。

目次
Webでは、必要な事例へたどり着く手がかりを作る
事例一覧が企業名と製品名だけだと、初めて見る人には違いが分からないことがあります。業種、対象業務、課題、導入後の変化を短く示すと、本文を開く前に自分に近い話を選べます。
分類を増やしすぎると、一つの分類に記事が一つしかない状態にもなります。まず、読者からよく聞かれる条件で整理します。「小規模チームでの運用」「既存システムと併用」「多拠点へ展開」など、会社の業種だけでは見えない違いも手がかりになります。
製品説明ページから関連する事例へ進めるようにする方法もあります。ただし、同じ製品の事例をすべて並べるより、そのページで説明している業務や機能と関係するものを選び、なぜ参考になるかを一文添えます。
メールでは、読む理由を相手の課題から書く
商談後に送る紹介文の例
先日ご相談いただいた「各拠点で運用が揃わない」という点に関連して、段階的に利用部門を広げた企業の事例をお送りします。最初の対象部門をどう決め、問い合わせ対応をどのように分担したかが紹介されています。特に「運用を広げた際の工夫」の箇所が参考になると思います。
会社の属性が似ているという理由だけで、同じ成果が出ると示さないようにします。関連する条件を説明し、違いがある部分も必要なら補足します。成果を大きく見せる言葉より、相手の疑問と記事の内容がつながっていることが読む理由になります。
まだ接点のない相手へ広く配信する場合と、相談を受けた相手へ個別に送る場合では、前提が異なります。個別の相談内容を知っているような書き方をせず、対象業務と記事の主題を端的に伝えます。配信の方法は、自社の許諾や配信ルールにも従います。
展示会やセミナーのあとには、会話とつなげる
会場で聞いた課題を記録していなければ、後から適切な事例を選べません。営業が使う記録には、興味を持った機能だけでなく、相手が何を心配していたかを残します。現場への定着、既存環境との連携、社内の承認など、紹介する話の選び方が変わるためです。
たとえば、セミナーで製品の全体像を説明したあとなら、導入までの準備や運用体制が分かる事例を案内できます。すでに具体的な比較をしている相手には、選定理由や制約の近い事例を選びます。
記事のどの部分を読んでほしいかまで書けば、相手が長い本文を最初から探す負担を減らせます。本文の見出しに直接案内できる場合も、リンク先の表示と内容が意図した箇所か確かめてから送ります。
配信する前に、抜粋と媒体の条件を見る
Webで公開済みだからと、顧客の顔写真やコメントをどの媒体へも自由に使えるとは限りません。メールへの画像掲載、広告への転用、別の冊子への転載など、予定する使い方が承認範囲に入るかを確認します。
抜粋では、意味を支える条件を削らないようにします。「一部門の試験運用で確認した成果」を、紹介文で「全社で実現した成果」に変えてしまうと、元の記事とは違う説明になります。短い文ほど、対象や時点を点検します。
画像の説明も同じです。業務のイメージ図を取材先の実際の画面だと受け取られる書き方にしたり、別の写真を導入後の現場写真として扱ったりしません。本文、画像、紹介文を一つのまとまりで見ます。
届けたあとの反応を、次の選び方へ返す
送付した件数だけでは、記事が役に立ったかは分かりません。営業には、どの疑問に対してどの事例を送り、その後どんな質問が出たかを残してもらいます。全文が読まれたかまで分からなくても、次の会話で使われた箇所があれば材料になります。
反応が乏しいときは、記事の内容、紹介文、送るタイミングを分けて見直します。内容がよくても、相手がまだ製品の必要性を考えている段階なら、細かい運用の話は早すぎるかもしれません。届かなかった理由を一つに決めず、実際の会話から確かめます。
外部への依頼を検討している方は、導入事例制作のサービス内容をご覧ください。