クラウドアプリ界の異端 ブランドダイアログ~その“キセキ”を追う
<クラウドアプリ界の異端 ブランドダイアログ~その“キセキ”を追う>第3章 過去に手がけた「ナーチャリング」が「Knowledge Suite」の“血”だった
2011/07/26 20:29
・第1章・第2章を読む
顧客のスタイタス管理の原点はクーポンとの情報リンク
マイクロソフトの「Windows2000」を搭載したパソコンが、企業向けに入り始めていた頃のこと。独立前に稲葉社長は、インターネットを活用した、今でいう「リード・ナーチャリング(見込み客/リード獲得を目的としたサイトで来訪者を見込み客にまで育成する)」を、10年以上前に提案していた。取っていたのは、インターネットで獲得した見込み客をメールを活用して育成し、同時に顧客スコアリングでリアルに顧客に訪問して懐に入り込む手法。当時、この手法を採用した自動車メーカーの例をみてみよう。「自動車購入資金100万円プレゼント!」。ポータルサイトのYahoo!のバナーで、この広告を見た記憶がある方は多いだろう。これを仕掛けたのが、当時の稲葉社長だ。キャンペーンの仕組みは、まず、現在保有している自動車のメーカーと車種、車検までの期間、家族構成などのアンケートに答えて応募。するとクーポンが発行されるので、それを自動車ディーラーに持参すれば、もれなく店頭でプレゼントがもらえるというものだ。
このクーポンには、名前と住所、電話番号が記載されている。今でも自動車メーカーのディーラーの店頭に行くと、「お客様カード」を記入させられることがある。しかしどうだろう。冷やかし半分でディーラーを訪れたとき、記入を求められても、拒んでしまう人がほとんどだろう。いったん「お客様カード」に住所氏名を記入すれば、自宅の郵便ポストにダイレクトメールが届けられ、自宅を訪問してくる営業担当者もいるだろう。その煩わしさは、容易に想像できる。
ところが、稲葉社長が手がけたクーポンの場合、ディーラーは「お客様カード」への記入を求めてこない。応募の際にインターネット画面で記入した「お客様カード」の情報が、クーポンの右上隅に刻まれた番号とリンクしていているからだ。これは、店頭に来た顧客に対する対応をセグメントする目的もある。顧客はこの番号が管理ナンバーでなく、応募に必要な基本情報を備えたカードであることを知っていない。「買わされる」という心理が働く顧客のステイタス情報は、クーポンには一切表示していない。顧客のステイタスは、すべて番号に置き換えられているのだ。
ここまで、自動車ディーラーの見込み客獲得策の一端を見てきた。ここからは、ブランドダイアログの「GRIDY」や「Knowledge Suite」の製品特性となったビジネスモデルだ。稲葉社長が手がけた自動車ディーラーの「お客様カード」をナンバリング番号に置き換えて営業管理番号として管理していた仕組みでは、「トヨタ自動車は1」「日産自動車は2」―などと、保有車種やタイプ別、車検、家族構成などのすべてを番号で管理しており、ディーラーの営業担当者はこの番号を対照表で確認するだけで、顧客のステイタスを管理できた。
例えば、ディーラーに足を向けさせるキャンペーンを打ったとする。インターネット上に構築したSFAのアプリケーションを確認すれば、来店していない顧客リストのデータベースが一覧を取り出すことができるので、これを営業担当者が個宅訪問に使う。このアプリは各営業担当者が閲覧でき、管理画面でキャンペーン応募者に対して各担当者の営業日報を書き加えたり、スコアの低い顧客にメルマガを配信した履歴接触に関する履歴情報をアップデートしていったりする構造をつくったのだ。
ここまでくれば、ブランドダイアログの製品と、自動車ディーラー向けに稲葉社長が手がけたこととの関連性を理解していただけると思う。常に顧客をフォローし続け、顧客接点を最大化させる「リード・ナーチャリング」を、すでに10年以上前に行っていたのだ。この自動車メーカーでは、稲葉社長が行った仕組みで、受注までの顧客接触回数が減り、顧客対応時間も大幅に削減できた。さらに、これが一番大切なことなのだが、営業担当者の月間受注率が130%以上に上昇したという。
関連記事
<クラウドアプリ界の異端 ブランドダイアログ~その“キセキ”を追う>第1章 なぜ「Knowledge Suite」が選ばれるのか?
<クラウドアプリ界の異端 ブランドダイアログ~その“キセキ”を追う>第2章 挫折の連続、「GRIDY」初期の“光と影”
BDとウイングアーク、SaaS/クラウド市場において戦略的業務提携を締結
<クラウドアプリ界の異端 ブランドダイアログ~その“キセキ”を追う>第4章 クラウドサービスの行く末を決めた戦略的な価格設定