前職でフィールドサールス協業型インサイドセールスを立ち上げる際に、フィールドセールスの部門長はみんな大賛成、どんどんパイプライン創出してください、なのですが、フィールドセールス担当のレベル、すなわち、現場の実務レベルに落ちると、いくつかの問題に出くわしました。これをどのように乗り越えたか、経験を踏まえて、ブログにまとめました。
■インサイドセールス立ち上げ段階の営業連携問題のあるある
私自身、前職でフィールドセールス協業型のインサイドセールスを立ち上げた経験があります。フィールマーケティングのマネージャーとしてデマンド・ジェネレーションの企画・実行をしながら、マーケティングのリードをフォロー・精査するインサイドセールスを外注ベースで管理していました。いわば、マーケティング部門で管理するインサイドセールスというスタイルです。ちなみに、コーラーは3名でスーパバイザーが1名、マーケ業務との兼務ですが、毎週2回スーパーバイザーとの進捗会議含め、かなりの業務量だったように記憶しています。
社風・組織文化・時代背景を補足しますと、インサイドを立ち上げたのが2013年ぐらいと初期であり、比較的ベテランのフィールドセールスが多く、重要な顧客管理は自分で完結したい意識の方が多い、既存顧客の一定層いる環境でしたので、その意味で、インサイドが見込み案件を獲得することが当たり前という理解がなかった時期なのかもしれません。
で、実際に、インサイドセールスを立ち上げると、味方だと思っていたフィールドセールスから、次のようなクレームや不整合を目の当たりにすることになりました。
・フィールドセールスが担当しているアカウントへの荷電は控えてほしい。もしくは荷電前にフィルターさせてほしい。
・案件が少ない営業は、SQL要件よりも浅いアポイントメントベースで引き渡ししてほしい。
・インサイドのヒアリング内容と顧客訪問結果があまりに乖離ありすぎる。ヒアリングに問題あるのではないか。
フィールドセールスの部門長はみんな賛成、どんどんパイプライン創出してください、なのですが、フィールドセールス担当のレベル、すなわち、現場の実務レベルに落ちると、こんな問題が出てくるわけです。
■SLA、オペレーション連携の詳細設計でどんどん潰しこんでいく
なんとなく、想定できていた問題ではあるんです。前職の良いところは、そのような問題を営業が包み隠さず、まずはフィードバックしてくれる点ですね!!
ですが、営業の要望のみを組み込んでいくと、スケールアウトするというマーケティングの良さがどんどん削がれてしまうわけですから、オペレーションの部分最適で対応し、マーケティングの良さを最大限残す努力をしました。
●荷電先のフィルター:キャンペーン・カテゴリー単位に荷電フィルターの強弱をON/OFF
フィールドセールスに荷電対象のフィルターを入れることを前提にしてしまうと、マーケが創出したMQLがどんどん目減りし、SQL変換率にも影響でます。欧米ではフィルターはいれないですし、SQL変換率もアグレッシブで高めです。ここで、営業のフィルターを入れて、コールしないMQLを増やすと、マーケティングROIの観点で完全にアウトです、本社から突っ込まれます。まして、毎日、ウェブのコンテンツダウンロード入ってくるリードをいちいち営業確認できない、フォローアップスピードが重要な展示会のフォローアップもしかり、なわけです。
そこで、キャンペーンのカテゴリーをセグメンテーションしてみて、荷電フィルターが効かせるものとそうでないものをルール化しました。
・営業が集客する自社イベント・セミナー
参加者は、まさに営業がグリップできている方々です。インサイドのフォローに回しても案件化は難しいと判断し、これらは営業がフォロー希望の場合はリードフォローを営業に任せました。自社のイベントですので、外部イベントのように他社がリストのリーチすることもないので、フォロー時間の余裕もあります。
・展示会、外部セミナー、ウェブ・リード等のその他のすべてのキャンペーン
これらのキャンペーンは、どんなに営業が入り込めているアカウント、担当者であったとしても、時間優先でインサイドがフォローするルールとしました。但し、成熟市場で営業のカバレージも効いている会社でしたので、インサイドがコール時の段階で、営業やパートナーのタッチ状況を丁寧に切り分けしていくコールスタイルというのは大前提です。
●浅めのSQL要件でのパス:アウトバウンドキャンペーンを組成、SQL要件の強弱へ
確かにリードにはアカウントが紐付いていて、どの営業のテリトリーのリードかが分かれば、営業単位でSQLの要件の強弱は可能です。ですが、これをやり始めると、私の場合は外注ベンダーを管理していたので、KGI、数値管理がブレるわけです。SQLがやたら増えても、受注は増えないとかです。
その為、緩めのSQL引き渡しは、例外として、個別のアウトバウンドキャンペーンで設計し、当該キャンペーン分のSLQはアポベースとするといったことを行いました。実際、営業のテリトリーによって、リード、SQL引き渡し案件の強弱は出ます。例えば、製造業は多くの案件が発生するが、リード獲得が難しく金融は案件が少ないといったケースが見られました。そこで、案件数が少ない営業のテリトリー、セグメントに併せて、アウトバウンドを行っていきました。
そして、アポで訪問後に営業からきっちりフィードバックを貰い、SQL作成の要否を切り分けしていきました。
●ヒアリング内容の乖離:訪問後の営業フィードバックを上長含めて双方向に
日本の場合、大企業になればなるほど、自社の課題を電話でオープンすることはありません。特に私が扱っていた商材はITセキュリティでしたので、尚更です。そうなると、ヒアリング内容と訪問結果の乖離が発生することがあります。また、外注のテレマーケティングを利用している以上、コーラーの知識形成もなかなかの課題です。
そこで、当時は、インサイドからフィールド担当に案件情報を引き渡す際に、フィールドセールスの上長、マーケティングの私、テレマーケティングのスーパーバイザーを含めてもらい、訪問後の結果、フィードバックを上長含めて行いました。インサイドとフィールドが1対1でコミュニケーションを完結してしまうと、どうしても情報が見えにくくなるためです。
これにより、スーパーバイザーがヒアリングポイントの勘所を理解し、コーラーを再教育するなど、組織的にコーラーのヒアリング能力・質の改善に取り組みました。
■私のアカウントに荷電するなから、もっと荷電してへ
上記以外に、フィールド部門長、マーケ部門で月次で会議体を持ち、どの営業にどの程度の案件をフォワードできているか、案件少ない営業向けにアウトバウンドを実施するか、など各営業の案件バランスを配慮するようにしました。
最初は、私のアカウトに荷電するな、と言っていた営業も、他の営業がどんどん案件もらえるようになる、または自分が良い案件をもらえるようになると、一転して、どんどん自分のテリトリー優先的に掛けてほしいとなります。その意味で、誰にどのような案件を引き渡しいるか、営業全体に情報共有するコミュンケーションも大事なのかもしれません。