- LAPRAS株式会社
- セールスマネージャー
- 中島 佑悟
個人の「成約件数」は追わない。セールスをデータで仕組み化し、人に依存させない方法
〜セールスの「属人化」を排除し、少人数でレバレッジの効く体制を目指す。データと定性情報をもとに仮説を立て、有効なモデルをつくるセールスの仕組み化とは〜
あらゆる分野においてサイエンスが進む中で、まだまだ属人性の高い職種が「セールス」ではないだろうか。
2016年5月に創業し、エンジニアのオープンデータを元にスカウトを送ることができるAIヘッドハンティングサービス「LAPRAS SCOUT」を展開する、LAPRAS株式会社。
▼AIヘッドハンティングサービス「LAPRAS SCOUT」
約1年前までセールス専任のメンバーがいなかった同社でも、セールスの属人化がひとつの課題であったという。
そこで本格的に受注を伸ばしていくタイミングで、セールスマネージャーを採用し、少人数でレバレッジの効く仕組みづくりを開始。
具体的には、約70〜80社分の営業記録を洗い出し、受注と因果関係のありそうな項目を整理。そして、受注に影響するのは何か? に対する仮説を立ててデータで検証し、確からしいものを仕組み化することを繰り返しているという。
同社のセールスマネージャーを務める中島 佑悟さんは、「営業において個人の目標を追うことは、あまり意味がない」と語る。
今回は中島さんに、LAPRASのセールスの仕組み化について、詳しくお伺いした。
セールスの「属人化」を脱し、いかにレバレッジを効かせられるか
僕は元々、新卒で入った会社で2年ほど広告営業をしていたのですが、当時、商談記録を取っているメンバーが少なかったことに違和感があって。そこで個人的に、1年目の時から商談記録をスプレッドシートで管理していたんです。
そうして自分のCVRやリードタイム、顧客属性、提案商品の記録などを計測していると、この営業目標を達成するには1ヶ月前に何件の商談数が必要で、その商談をつくるにはどういうターゲットに何件アプローチするのが必要だな、ということが大体見えてきて。
実際、2年目の時に1年目で作ったデータをもとに行動してみたら、かなりホワイトに働けるようになったんですよね。その経験から、セールスにおいてデータを取得することの大切さを学びました。
その後、フリーランスでの営業コンサルティングや、事業会社での営業部の立ち上げを経験し、2018年の8月にLAPRAS初のセールス専任として入社しました。
現在は、セールス全般のマネージャーと、「LAPRAS SCOUT」の新規顧客の獲得における責任者を務めています。
僕が入社する前、ビジネスサイドのメンバーは4人いましたが、PR、マーケ、COO、CSといった形で、別の担当領域をもちながらセールスを兼務しているような体制でした。
当時は、毎月の目標値に対して、各メンバーが担当先の受注のヨミを入力するような形で管理していたのですが、担当者の感覚に依存していた部分が大きく、セールス手法も属人化してしまっていて。
これからプロダクトの受注を伸ばしていくことを考えた時に、より体系的に、再現性をもったセールスの仕組みをつくる必要がありました。
一方、弊社の組織体制としても、むやみにメンバーを増やさないという方針があったので、「少人数でいかにレバレッジを効かせられるか」をミッションとして、セールスの仕組みづくりを始めました。
セールスのステージを定義し、受注に相関のあるデータを整備
まずはじめに、過去のセールス記録にどのようなデータがあるのかをざっと見て整理し、全体を把握することから始めました。
そこで最初に行ったのが、セールスの「ステージ」と「ステップ」の定義です。問い合わせ、アポ、商談といった一連の営業プロセスの中で、受注と因果関係のありそうな項目を整理しました。
▼実際に整理した項目
こうしたステージ移行の因果関係にありそうな変数は、SPIN(※)やBANT(※)といったビジネスフレームワークを元に設定することができます。
※SPIN:Situation(状況)、Problem(問題)、Implication(示唆)、Need-payoff(解決)の頭文字をとった略語で、営業のヒアリング手法
※BANT:Budget(予算)、Authority(決裁権)、Needs(ニーズ)、Timeframe(導入時期)の頭文字をとった略語で、営業の基本となる質問項目
それから、「問い合わせ→商談」や「商談→受注」といった意思決定ラインを超えるのに影響するデータは何か? という仮説を立て、それを検証するためのデータを拾っていきました。
実際には、約70〜80社分の受注データを、セールス担当のメンバー全員の頭の中から洗い出していったのですが、これがかなり地道で大変でしたね(笑)。
例えば、「エンジニアが商談に同席していたか」「問い合わせ時に価格にネックはなかったか」といったヒアリングで取得した情報から、「デモを発行したか」といったWeb上の取得データまで、とにかく関連度の高そうなデータ項目をみんなで記入していったんです。
この作業を1ヶ月くらいかけて行ったことで、データ整備だけでなく、メンバーの共通認識をすり合わせることができました。また、データからは見えてこない情報もあるので、僕自身も商談に行きながら、現場の肌感を養っていましたね。
仮説を立ててデータで検証し、確からしいものを仕組み化する
スプレッドシートに一通りの記入を終えた後は、RやPythonを使ってデータ解析をし、受注に相関のあったものすべてを、営業管理ツールのHubSpotに記録していきました。
データをモデル化する際には、受注単価やリードタイムなど何をゴールに置いてもよいのですが、弊社の場合は、一番わかりやすくてシンプルな「受注したか否か」で測っています。
▼LAPRAS SCOUTでのモデル(一例)
受注する確率 = 係数×訪問か否か + 係数×人事部か否か + 係数×ダイレクトリクルーティング経験ありか否か……
仮説を元に、いくつかの変数を組み合わせてモデルを作っていくと、その中でも確からしい仮説が見えてきます。それに対する打ち手を考えて、営業フローに組み込んでいきました。
例えば「エンジニアが商談に同席した方がよい」という仮説に対しては、「GitHub等からデータを収集しているので、エンジニアさんもいた方が導入判断がしやすいですよ」とお伝えして、ご同席をお願いしたり。
他にも「過去にダイレクトリクルーティング施策を経験している方がよい」という仮説に対しては、競合サービスに出稿している企業をリストアップして、重点的にアプローチする、といった形に変えました。
一方で、モデル化しても相関が見えてこなかったものも、逆に試してみる価値があるんですね。
実際にあったのが、契約プランの期間変更でした。元々、半年契約のプランしかなかったのですが、契約期間の長さって、実は受注に相関しないんじゃないかという仮説があって。
そこで、ある顧客から3ヶ月プランが欲しいと言われたのがきっかけで、1年、2年プランも一緒に作って提案してみたところ、より期間の長い1年プランが決まったんですよ。
結局、3ヶ月プランがいいというのは「運用するための工数や知識が足りているか確かめたい」という意図であって、それ以外のプランの料金や長さは、意外と受注に相関しない変数だったと。
こうして仮説を立ててデータで検証し、確からしいものは仕組み化する、ということを繰り返していますね。
仮説づくりは、データの裏側にある「定性情報」が大事
その仕組み化をする上で重要なのが、そもそもの「仮説づくり」です。
例えば、フリーミアム戦略を取っている企業であれば、ログイン時間が週に何時間を超えると受注に相関する、といった仮説が立てられますが、それに対する戦略がなければ意味を成しません。
またデータは大事ですが、それ以上に、その裏にある「定性情報」を汲み取ることが大事ですね。矛盾するようなことを言ってしまうと、データは大事だけれど、全然信用できないと思っていて(笑)。
なぜなら、例えば100件のデータがあった際に、性別だけを変数に取ると2パターンに分けられますが、情報が1種類なのでざっくりとしたデータになります。
そこで、2分類の変数を2つ増やしてみると、2×2×2の8パターンができ上がります。すると、各データの情報量は多くなりますが、各パターンに該当するデータ数自体が少なくなるので、その信用性が低くなってしまうんです。
そこで、サンプル数が多くない場合には、できるだけ変数の「個数」を減らす必要があるのですが、そうするとモデルに組み込まれない情報も多く出てきます。
実際、セールスの場面では、相手の心情や表情だったり、データにできない定性情報もかなり多いじゃないですか。
手を替え品を替え、できるだけ多くの情報量をもつ変数に絞り、データを入れ替えていくのですが、そこから落ちるような定性情報も踏まえて仮説を立てるようにしています。
個人の営業目標は追わず、エラーがあれば「仕組み」を疑う
そして、検証したモデルは、顧客対応の分岐や商談トークなどにも落とし込んでいきました。
▼顧客対応の分岐チャート図
こうして仕組みを作ったことによって、アウトソースを活用したセールス体制を構築できるようになりました。現在もセールス専任は僕だけですが、COO、人事、マーケの社員3人と、外部委託の3人、合計7人でセールスを担当しています。
社外の方に、問い合わせ対応や商談代行なども依頼していますが、クオリティを落とさずに問い合わせや受注を伸ばすことができており、うまくワークしているかなと思います。
実際、僕が入社する以前の2018年1〜7月と比べると、2019年の同期間における平均問い合わせ数は約160%増加し、平均商談数も約140%増加しています。
データをもとに顧客対応を分岐するだけでなく、マーケに対して受注しやすいターゲット属性を伝えたり、開発に対してもプロダクトの要望を伝えたりして、改善を回していますね。
また、何でも仕組みで解決することを基本にしているので、個人の受注件数などは目標として追っていません。
以前は、個人の受注確率もデータとして出していたのですが、結局いろんな変数がある中で、個人目標を作ったり実績を見せたりするのってあまり意味がないと思ったんですね。
なので今は、各自にリードを渡して、一定の打率で受注をしてくれたらOKという形にしています。
もちろんデータは取得しているので、受注率が低いなどの異常を検知したら、人ではなく「どこ」が課題なのかを考え、仮説を立ててデータを作り、打ち手を実行していますね。
「人」によるアクションを、Web上に落とし込んでいきたい
「営業はアートだ」という言葉を聞くように、科学しきれない部分はもちろんあると思うのですが、僕はセールスも仕組みで解決することが大切だと思うんです。
例えば、担当者から「LAPRASを使いたい」という言質を得ることが受注に相関していることがわかっても、その先のハードルとして、決裁者の意思決定を得られるかが新たなハードルとして出てきます。
それに対して、普通の営業であれば、改めて上長を含めた商談を設定したりして解決すると思うのですが、これって結局、人に依存したモデルになってしまうんですね。
そうするとレバレッジを効かせられなくなってしまうので、営業トークなどの要素を入れ込んだ、社内稟議を通すためのサービス説明動画を制作しました。
今の営業アクションって、直接話すことの安心感とか、信頼を作れるとか、何かしらの影響を与えているから存在していると思うのですが、今後はそれをできる限りWeb上のコンテンツに落としていきたいと考えています。
例えば、最初の商品説明を動画に置き換えたり、チュートリアルを入れてトライアルフローの中で営業を完結させたり、一緒に運用がんばりましょうという応援であればWeb上のキャラクターでもいいかもしれないですし。
そうした工夫をして、営業のレバレッジをさらに高めていきたいと思います。(了)