こんにちは。LayerX / バクラク事業部 / フィールドセールス所属の星野です。
割と最近までインサイドセールスを担当していました。
（最近は料理を始めて、その奥深さと美味しい食事を作って食べる楽しさにハマっています。パンの発酵が難しい、、。）

さて、今回は直近で自分が関わっていたプロジェクトに対して振り返りを公開していきたいと思います。割と出来て当たり前のこともありますが、それらを実践するために悩んだ部分や、次回もし同じことをするならどうするべきかを記します。

こういった方にお役立ちできるかも

• 検証・改善サイクルの回し方がわからない。

• インサイドセールスとして商談獲得以上の事業貢献を図りたい。

携わったプロジェクト

2023年の12月より2024年3月までの4ヶ月間、特定業界に対するGTM（Go To Market）にIS担当として携わりました。
GTMとは簡潔にまとめると「サービスを市場・顧客に届けるための戦略」を指します。「バクラク」は現時点で10,000社以上のお客様にご利用いただいていますが、今回のプロジェクトはその中でもお客様の課題が近しいと考えられる業界に対して、改めてその課題を具体的に掘り下げて提供価値を伝えるプロセスを言語化・展開しようという内容です。

個人単位のミッションと成果

振り返りを記載する上で、自分が担っていたミッションと成果の概要を共有します。
今回のプロジェクトにおいて、ISのミッションは「業務委託の方を含めてそのスクリプトさえあればお客様への価値訴求が叶い、商談機会をいただける型を作ること」でした。

上記の前回他プロジェクトで作成された訴求フロー図に対して、私が今回のプロジェクトで作成したものが下記になります。上記のものと比較すると簡素で資料を作り慣れてない感がありますね笑

簡素な作りになっている背景としては、今回お客様の業界を細分化して、そこに当てたアウトプットとして作成したため、同様のものが複数あるような形になっています。ちなみに、上記のアウトプットを作成するまでの過程がこちらです。

具体的な内容について公開できる範囲が限られていますが、基本は想定課題（3パターンほど）や利用中のサービス、細かい言い回し（課題の当て方や担当者の方への接続プロセスなど）によって分岐、改善が繰り返されています。

これらの仮説検証を経て、商談化率には有意な差を生じさせ、再現性を持たせることに成功しました。
今回は主にこのプロセスとその背景、そして改善できたポイントを言語化していきます

アウトプットまでの細かいプロセス

上記のアウトプットを生むまでのプロセスは大きく以下の流れです。

1つずつ見ていきましょう。

① 事例インプットとSDRによる顧客課題の理解

なぜ顧客課題の理解が大事なのか：
最初に特定業界のお客様への訴求を考えるにあたり、重要なことは顧客の業務フローの理解と考えました。
今回プロジェクトのオーナーを持っていただいた稲田さんが以前に書かれたnoteにもありますが、顧客解像度によって数字目標が「ただそろばんを弾いただけの絵に描いた餅」から「明確な顧客像と勝つためのシナリオを伴った意志を持った数字」となります。

特にISでは仮説・事例インプットをお客様体験の観点から重要視しています
（ISに限った話ではないですが）。
個々のお客様から話を伺い課題を特定することの重要性は間違いありませんが、主に電話を通して多忙なお客様とコミュニケーションをとる場合においては課題とそこへの提供価値を明確に、端的に伝えることが求められます。

顧客課題の理解のために何を行ったのか：
まず行ったことは商談動画、顧客インタビューの確認です。実際にお客様の元に足を運んで業務を見せていただくこともしました。それらをとにかく自分の言葉に置き換えて発信することで、より深い理解と共有を行います。
顧客インタビューは上記noteの執筆者である稲田さんやCSの方より実践いただいた内容が細かく属性ごとにNotionにまとめられていました。

そこでインプットした内容（課題仮説）をSDR（Sales Development Representative, 顧客からの問い合わせを受けて対応する手法）で過去の商談失注や、お問い合わせをいただいた、比較的「バクラク」の認知があり、弊社側もお客様の課題を深く認識できるお客様に当てることでその効果を定量観測しました。
結果として、プロジェクトとしての動きをする前後に商談化率を上げることに成功し、それをスクリプトとして型化しています。
それが上記アウトプットの一部になります。

② 属性によるターゲット層の探索

①において、比較的温度感の高いお客様を相手に課題と提供価値の解像度を高めた段階で、次にそれを温度感の低いお客様に訴求するフェーズに入ります。アウトバウンド活動に寄せることで優先度を付けるためにそのリスト精査、属性の細分化が求められました。

この点においても、顧客課題の解像度を高めることで複数ある属性情報（従業員数や所在地、業界、事業所数、決算期など）の中でどの変数に注目するべきなのかの当たりをつけることができます。

ここでは最も商談化率への影響と業務課題の大きさに起因すると考えられる変数「事業所数」のみに注目しました。

変数を絞った中でもシステムの利用状況や、過去接点保有率、実際に会話した上で感じた組織内の役割分担による課題など、一次情報をまとめながらターゲットを絞ります。
（絞るのみでは不十分で、その検証と改善仮説内容をチーム内で発信することで、自身を含めてチーム全体が認識齟齬なくNext Actionを踏める。ここが地味に重要です。）

ここまで行った時点のアウトプットが次のものになります。

③ BDRにおける訴求方法探索

ここまで①, ②のフェーズにおいて顧客課題とターゲット層の解像度を高めてきました。最後にBDR（Business Development Representative, 新規開拓の役割を担うインサイドセールス手法）において、どのようにお客様に話を聞いていただくか、どのように端的に価値を伝え切るかを考えます。
この時点で業務委託の方と一緒に行動量を増やした活動に入ります。

訴求方法探索を考える上で主な論点は以下4点でした。

（↑ この4点を細かく記述すると内容と外れてしまうため敢えてここでは省きます）

上記4点の分解とその改善に至るまで、とにかく業務委託の方と共に数をこなしてその結果を言語化、そして改善仮説の構築と検証、再度言語化というサイクルを繰り返しました。
1ヶ月という限られた最後のプロジェクト期間の中で、回したサイクルでしたが、結果としては有意な商談化率の変化を生むことに成功しました。

取り組みの振り返り

これらの取り組みの中で学べた点、改善できる点を並べると以下の様になります。（これらはインサイドセールスとしてというよりは、事業を進める上で重要だと強く感じた点になります。）

① 振り返りの設計

いかなる活動においても振り返りがされない活動は改善もされません。
（偉そうなことを言っておいて、私自身も当プロジェクトに関わる以前にはほとんど出来ていなかったのですが、）
例えば、事業判断を下す上では数値が求められます。しかし数値を出す上でも、そもそも元のデータがちゃんと入力されているのか、計測対象は目的と一致しているのか、などの確認を序盤に行うことが重要です。

それなりに工数をかけた上で数値計測ができない、そもそも出している数値が目的に沿っていないということが発覚しても修正が効かずに行動の意義自体を示すことが難しくなります。

ここについては最初の段階で目指すべきゴールとして（妄言でもなんでも良いので）プロジェクトオーナーやマネージャーの方と擦り合わせる必要があります。

実は私もプロジェクト序盤でしたが、全然数値を確認できておらず、収拾がつかない状況になりそうでした。割とメンタルに来たのでここは特に胸に刻みます。

この振り返りの設計を行う上で重要なのが次の「言語化と論点整理」です。

② 言語化と論点整理

「言語化できない」というのは「理解できていない」と同義と考えます。
言語化とは文章に起こすことのみを指すのではなく、ここでは図式化など客観的に状況を理解できるかたちでアウトプットできることを指しています。

例えば「会話のメモをとる」という行為のみでも、これは単なる記録ではなく、見返した際にその会話が目的に沿っているのか、会話で触れられている内容で改善できる点はないのか、といった具合でその論点整理を行うことが可能になります。

昨今「データ分析」という言葉が広く使われている中でも、そもそも何が分析されているべきなのかを明示しなければ、それはただの数値遊びになってしまいます。

余談ですがこの点↑については次の書籍がとても勉強になりました
「DATA is BOSS 収益が上がり続けるデータドリブン経営入門」

今回のプロセスでは、まず顧客課題は何なのか、その解像度を高めるためにどういったアクションをどう言った優先順位で行うべきなのか、お客様との会話を構造化した際に修正できる点はどこなのか
などの内容を全て書き出して、チームで認識を揃えながら行動することで明確な改善を計れています。

また長期的な再現性を求める上でも、言語化されていない内容を他の方に伝えることはできないため、これらは重要だと考えます。（極論、文字や数字がなければ文明は発達し得なかったという例を挙げると納得しやすいでしょうか）

③ 相互理解とオンボーディング、再現性

上記で言語化の重要性について語っていますが、一方でそれが全てというわけではありません。
人同士のコミュニケーションな以上、相手の背景を理解した上で「伝える」ということがゴールです。

伝えるために重要なのが相互理解だと考えています。相手がどう言った経歴を歩んできているのか、どう言ったことで喜怒哀楽を感じるのかなど、相手のことを知らずに押し付ける知識は再現性をもたらすものにはなりません。
（それでもコミュニケーションなく再現を求める場合には、入力と出力が一定となるレベルにまで不確実性を排して共有する必要があります）

これは私が業務委託の方に構造化したスクリプトのみを渡してコミュニケーションを怠っていたの深い反省から得た学びです。後半に毎日擦り合わせの時間を設けたことにより、齟齬なく一緒に目的や課題を認識することができました。

最後に

今回のプロジェクトは「当たり前のレベルを上げる」という観点で本当に学びの多い機会となりました。大変でしたが、参加前には出来なかったことが明確に出来るようになった4ヶ月間で、一緒に動けたメンバーも含めて本当に楽しかったです。

内容を端的にまとめると、振り返りや言語化、相互理解コミュニケーションて大事ですよねということなのですが、そもそもこう言ったことが出来ていなかった自分に今回のGTMプロジェクトへのアサインがされたこと、一緒に走り抜けさせてもらった周りのメンバーの方など本当に環境に恵まれました。
プロジェクトに関わらず、LayerX自体が日々学びが多くて楽しい環境だと感じます。

こう言った内容・活動にご興味をお持ちいただけましたらぜひお話させていただければと思います。私以外にも多様なメンバーが発信をしているのでそれらも参考にしてみてください。

ここまでお付き合いいただき、ありがとうございました。