今回は、「アカウントベースドマーケティング（ABM）の必要性を感じたストーリー」と題し、某A社マーケターMさんの働きかけがきっかけとなり、会社としてABMに本気で取り組むことになったボトムアップストーリーをご紹介します。また、最後にこのストーリーが伝えたかったABMの取り組みに必要不可欠な3つのポイントもまとめています。
アカウントベースドマーケティング（ABM）の必要性を感じたストーリー
マーケターMは、アクセス解析やデータ分析を得意としている入社７年目の女性だ。Mは、最近Webからのお問い合わせの一次受けを任され、各部門に振り分けを行うようになった。なぜなら、お問い合わせ内容を見て、確度が高いと判断した場合、Webの行動ログなどと紐づけ営業に報告している。これが営業から好評であったからだ。
あれは１年ほど前のこと。
そのころはまだ、お問い合わせ情報はメールで一か所に蓄積され、マーケのマネージャーが勘だけで営業に振り分けていた。ある日、マネージャーの留守対応として、Mがその作業を代行することになった。ふと一通のお問い合わせが目に留まる。某大手IT企業からのものだ。
それは、あるミドルクラスのSaaS製品の概算が欲しいという内容であった。Mは、振り分け先を考えながら、こう思った。「これを営業に渡すことは簡単だ。でも受け取った営業は本当にそのまま概算を出すのだろうか？」また、「お客様の実現したいことや、用途を知ることで、単なる概算ではなくもっとソリューション的な提案もできるのでは？」と思ったのだ。
次の瞬間、Mは得意の分析に取り掛かっていた。
マーケが持つ情報をあされば、お問い合わせしてきた人や企業の情報を得られると考えたからだ。すると少し興味深いことが分かった。お問い合わせ者は、半年前からWebをよく閲覧していて、今回概算が欲しいと言っていない他の製品資料を複数、ある一定の時期に集中して落としていることが分かった。これを営業に伝えると、営業は念のため概算見積依頼以外の製品情報も用意して訪問したところ、クロスセルに繋がり大きな受注となったのだ。
その後、
営業からは、「訪問前に分析をして欲しい」という要望が増え、毎日分析に没頭している。Mのおかげで、営業は訪問前にある程度お客様のニーズを察知し、引き出しを用意することができるようになったのだ。
しかし、最近こんなことが起きた。
Mは、某ITベンチャー会社のKさんからこんなお問い合わせを受けた。「あるプロジェクトでPaaSサービスの導入を検討しています。貴社のPaaSサービスについて詳しく聞きたい」という内容であった。プロジェクトがあること、PaaSサービスの導入を検討していることから、それなりに確度が高いと感じた。
いつものように、分析を進める。過去1年分のログを分析したが、Kさんは、いきなりWebに来訪してCVしているだけの情報しか得られなかった。cookieを削除して履歴が残っていないのか、情報収集で各社に説明の依頼をかけているのだろうと思い、深堀せずに営業にお問い合わせ内容を伝えた。
営業のEは、入社9年目のベテランだ。
この手のお問い合わせは、時間がかかる割に、契約に至らない可能性が高いが、注力製品でもあったことから引き受けた。一旦、SFAを使い某社名で誰か他の営業が担当していないか確認したが、某社の情報は登録されてなかったので、自ら某社に連絡してアポイントを取った。
商談の日
テーブルには、キーマンであろう部長B、お問い合わせしてきた課長K、システム部門の責任者Sの3名が出てきた。商談の中で初めて分かったのだが、既にうちの製品のトライアルを行い、他社と比較検討したうえでの問い合わせであった。セキュリティやカスタマイズの深いところまで質問され、かなり検討が進んでいることがわかった。しかし、システムエンジニアを同行させなかったため、営業はいくつか質問を持ち帰ることとなった。そして翌週、質問の回答と本日の内容から概算を提出することになった。
営業Eは、マーケターMに今日の状況を伝え、3人の名刺を渡し分析を依頼した。なぜなら、トライアルを行っていたという情報を営業は一切把握しておらず、分析から何か分かるのではないかと思ったからだ。
トライアル情報は完全にサイロ化されていた。トライアルのフローを回す専用の仕組みを自社で作り込んだからだ。Mは、マーケが保有する分散されたデータとトライアル情報などを一か所に集め、名寄せして可視化を試みた。
すると営業は把握することができない情報がいくつも出てきた。
半年前の自社イベントに、某社から3名参加していることがわかった。その中に、部長Bが含まれていた。メルマガ配信は別のツールを使っている。ログを調べると、某社の登録者は全部で5人いて、今回の商談に出てきたシステム部門の責任者Sが含まれていることもわかった。
マーケターMは、面白くなってきた。まるでパズルを組み立てているかのように。
更にトライアルデータベースの分析を進めると、Sは、3か月前にトライアルをダウンロードしていた。その後も、PaaS製品のテクノロジー系コンテンツを閲覧したり、IaaSまで閲覧していることも分かった。
Mは、営業にすぐに連絡をした。なぜなら、営業が持つ某社の情報が必ずどこかにあると確信したからだ。
集まったのは、営業の引き出しの奥にしまわれていた某社の名刺、紙のままのアンケートと、営業日報…。
こんなにあるじゃないか。とMは思った。それと同時に、でもなぜSFAに登録されていないのか考えた。営業が怠ったのか、それとも…と疑った。
疑惑は当たっていた。
SFAに登録されているアカウントを調べると、某社の社名に似て非なる名で登録された情報を次々と発見できた。住所情報からどうやら同一企業を指していることもわかった。営業Eが商談前にSFAを確認した時に、アカウントがヒットしなかったのはこのせいだった。
「これは、データを登録する際のルールが必要だ」とMは思った。
幸い、商談に出てきた3人の名前が珍しく、活動記録から名前でテキストマイニングすることができた。驚いたことに、漢字、ひらがな、カタカナで検索を試したところ、それぞれでヒットしたのだ。活動記録によると、半年前の自社イベントで集めた名刺をフォローし、某社の確度が低いと判断した事がわる内容があった。そのため案件としてきちんと登録していなかったのだろう。これに付随して、アンケート情報も紙のまま出てきた。これは使えると思った反面、データ化されていないことに落胆した。
「名刺やアンケートなど紙の情報も電子化する仕組みが必要だ」とMは思った。
更に最も有益な情報を営業が隠し持っていた。それは、ある営業が某社の大きなプロジェクトに今現在関わっているという内容であった。その営業は、隠し玉として案件確度が上がるまでSFAに登録せずに自分の懐にしまっていたのだ。ヒアリングを重ね、他のデータと繋いでいく。
はじめは、たった1ピースのお問い合わせであったが、いまマーケMが作り出そうとしているのは、マーケと営業、オンライン／オフラインの情報も含めた壮大なパズルである。
時間がなくコールログまで繋げられなかったのは心残りだが、、マーケターMは、3日かけてなんとかパズルの大枠を作り上げた。
すると、その絵から某社の目的が浮かび上がってきたのだ。
某社の部長Bは、他の営業がSFAに登録せずにこっそり進めている別案件に同席していたのだ。そのプロジェクトには、もう一人の部長Zが存在し、その人が決裁者であることも分かった。つまり、Zが仕切る大きなプロジェクトがあり、そこに関連する別プロジェクトを部長Bが担当し、その部下である課長Kがシステム責任者Sにトライアルさせて、その結果をもってKからお問い合わせが来たのだ。
プロファイル
本部長Z
- 決裁権あり
- イベント、Webなどの接触は一切もたない
- 打合せにもでてこない（営業が名前を聞き出しただけの情報）
- PaaS大規模案件の責任者
部長B
- 決裁権あり
- Webを閲覧しない
- イベントや商談には出てくる
- PaaS中規模案件の責任者
課長K
- 決裁権なし
- Webを閲覧する
- メルマガ登録もする
- イベントや商談に出てくる
- 上司や部下およびお客様やパートナーの総合窓口
- PaaS中規模案件のリーダー的存在
システム責任者S
- 決裁権なし
- Webやメルマガの技術コンテンツを閲覧する
- 技術的な資料やトライアルのダウンロードをする
- イベント、特にハンズオンセミナーに参加する
- 技術情報の収集／比較検討
- 導入前検証の実施／評価担当
分析の結果、Sは、お問い合わせしてきた製品のハンズオンセミナーにも参加していた。その時のアンケートで、プロジェクトは、要件定義レベルで、導入時期は未定と回答していた。また、他の製品ページの閲覧とトライアルダウンロードしていることも判明。更に、他にも某社から複数の人がWebに来訪し、資料ダウンロードしていることも分かった。
Mは、至急営業Eに伝える。
Eは、大きなプロジェクトを担当している別の営業とも話し合った。そして二人でまとめた話はこうだ。
それぞれが求めているPaaSは、将来的にAPI連携されることが想定できる。もしそれが当たっているならば、データ構造の違いが課題になるだろう。SEも含めソリューションまで落とし、次回の商談は営業2人とSEで訪問することに決めた。
2回目の商談当日
前回持ち帰った質問の回答と、概算から話を進めた。そして、今日のために準備してきた本題のサービス連携について触れると、やはり将来的に繋ぐことを考えていることが分かった。しかし、その際に直面するであろう課題にはまだ気付いていないようで、技術力と経験を踏まえたソリューションの提案にお客様は身を乗り出して聞いてくれた。
A社が、お客様に単なるPaaSサービスの売り込みで今日ここに来たのではなく、お客様の目的に対してサポートしていきたいという気持ちも伝わったのだろう。その後、2つのPaaSサービスと開発案件まで纏めて大型受注が決定した。
翌年
A社に、組織を跨いでターゲットアカウントを専任する部門ができた。その部門名はABM推進部。Mはマネージャーに抜擢された。
社内にあるアカウント情報を一元管理し、ランク付けをして戦略的にビジネスを進める部門だ。また、分析から予兆を掴み関係部門に繋ぐことが役目である。マーケが持つ情報と営業の持つ情報、さらにコールの情報まで繋げて可視化する。関連するシステムや製品なども含め協力体制を築き、月に2回、関係部門が集まり、情報共有と条件の調整を行う。正にアライメントの中核だ。
さらに、すべてのデータの入口を見直している。これは、Mがかつての分析時に感じた名寄せ問題を解消するためだ。登録のルールを徹底し、正規化情報しか取り込めないように縛りを入れた。また、正規化DBにない情報は、申請するようなフローも設けた。また四半期に一度データクレンジングを実施するようにした。つまり、ビジネスに使えるデータマネジメントを徹底したのだ。
これにより、顧客との商談はこれまでよりも充実し提案力も増し、取れる案件の数や規模が跳ね上がった。顧客から継続的に声をかけられる頻度も増えたのだ。
おしまい
ストーリーが伝える3つのポイント
- B to Bは、Many to Manyでビジネスを考えることが必要だということ
- データの蓄積から活用を考えたデータマネジメントが必要だということ
- 関連部門とのアライメントが必要だということ
1番目：特にB to Bにおいて個人という１点だけの情報では、お客様の全体像が掴むことが難しいということです。一つの案件に複数人が登場し、それぞれの立場や役目、目的に応じた接点があります。自社もマーケやセールスなど複数人が何らかの形でお客様企業の複数人と接しています。個にフォーカスすることはABMではなく、極端なOne to Oneマーケティングに過ぎず、これはB to Bビジネスにおいて機会損失を招きかねません。ABMは、まずその本質を理解する必要があるということです。
2番目：マーケティング部門は、主にWebやメールなどのオンラインでのお客様接点になります。一方、営業は電話や訪問などリアル、お客様とは直接の接点になります。このオンラインとオフラインのピースを如何に繋いで一つのパズルを組み立てていくか。また、イベントなどで集めた名刺やアンケート情報などの紙面も如何にデータ化してパズルに加えるか。ABMを行う上で必要不可欠なことは、お客様を知ることです。会社として集めた情報を如何に可視化するかでABMの質は異なってくるということです。
3番目：アライメント（綿密な調整で認識を合わせること）です。チームで行うスポーツにはポジションがあります。例えば、サッカーで言えば、みんなで一つのボールを追うことはありません。守護神のキーパーがいて、攻めのフォワードと守りのディフェンダー、その中間を繋ぐミッドフィルダーがいます。それぞれが、役目を持ち、その役目を少し超える重なりあう働きもします。ミーティングや練習を重ね、互いの動きを理解したときに、得点に繋がるパスが生まれるのです。ABMは特に、マーケティング、営業、製品、システムなど関連する部門とのアライメントが必要ということです。
さて、ABMの必要性が少しでも伝われば幸いです。
会社／製品
- 会社概要：https://www.b-story.co.jp/company
- 公式サイト：https://www.b-story.co.jp
- お問い合わせ：https://www.b-story.co.jp/contact
株式会社B-Storyは、デジタルマーケティングに取り組む企業を支援します。「実効性」と「実行性」をコンセプトに、戦略戦術ストーリーをデータ「蓄積、計測、可視化」の視点で一緒に作り上げていきます。
※当サイトの内容、テキスト、画像等の無断転載・無断使用を固く禁じます。
※当サイトを引用される際は、出典元（株式会社B-Story）を明記をお願いいたします。
※Unauthorized copying and replication of the contents of this site, text and images are strictly prohibited.
※In the case of quoting this site, please specify the source of origin (B-Story,Inc.).
