SaaS商談は「課題確認」から始めてはいけない｜最初に受益者を定義する

多くのSaaS営業が、「まず課題確認から」と教えられています。
本屋に並ぶ営業の本にも、コンサル会社のブログにも、判で押したように同じことが書いてある。

でも、少しその常識を疑ってみませんか 

▼ 動画でも見れます。

そのSaaSは、誰のためのシステムか

商談の準備といえば、企業のWebサイトを調べる、業種・規模を把握する、担当者の名前を確認する。これは当然やるべきことです。

でも、その前にやるべきことがあります。

そのSaaS製品の「導入で一番恩恵を受ける部署・担当者」を定義することです。

SaaS商談の相手と、受益者はしばしば別人です

準備をして商談にのぞみ、
実際に、商談に来た相手が、「受益者ではない」ということはよくあります。

その人は「本当の受益者」なのか
それとも「2番目の受益者」なのか
あるいは「受益者から調査を依頼されただけの人」なのか

この違いを意識するだけで、商談の進め方は変わります。

具体的な例を挙げてみます。
勤怠管理の商談で、ITの担当者だけが出席したとします。
この場合、本当の受益者は誰でしょうか

勤怠入力の手間が減るのは現場の従業員です。
集計・管理の工数が大幅に削減されるのは総務部です。
IT部門の担当者は、システムの安定性やセキュリティは気にしますが、業務改善の恩恵を直接受けるわけではありません。

こういう場合、どうしたらいいでしょうか

機能の説明は短時間で切り上げて、
IT部門の方が関心を持つ、クラウドのセキュリティやシステム連携の話に切り替える。
そして、本当の受益者である総務部への橋渡しをお願いする。

こちらの方が、ずっとスムースに今後の商談に引き継げます。

SaaS商談で、受益者を間違えると稟議で止まる

なぜ、ここまで受益者の定義にこだわるのかというと

理由はシンプルです。

受益者が動かなければ、稟議は通らないからです。

経費精算システムを例にあげます。
このシステムの受益者を定義するとこうなります。

1番目の受益者は、経理部です。

仕訳が自動起票され、月次決算のスピードが根本から変わる。
年間で数百時間の工数削減になることもあります。

2番目の受益者は、営業部です。

領収書の管理や精算申請の手間が減り、本来の営業活動に時間を使えるようになります。

ところが、多くの経費精算システムの営業は何を説明するかというと、「スマホで領収書を撮影できます」とか「承認がモバイルでできます」と、2番目の受益者である、営業側の利便性ばかりを前面に出していることが多いと思います。

でも実際、導入の稟議を通すのは誰でしょうか。
経理部長やCFOです。

彼らが本当に知りたいのは、仕訳が自動起票されることで月次決算が何日早まるか、年間で何時間の工数削減になるか、という話です。

「スマホで申請できます」という説明は、営業担当者には刺さるかもしれません。

でも経理部長には、何も刺さらない

結果、商談は盛り上がっても、稟議があがらない

受益者を正しく定義し、その受益者が決裁に動く理由を準備しておく。
これが、最初にすべき理由です。

ERPになると、SaaS商談の受益者は経営者になります。

特化型SaaSの受益者は、特定の部署です。
経費精算なら経理部、勤怠管理なら総務部になります。

ではERP（Enterprise Resource Planning）はどうでしょうか
企業が契約する、最も高額なSaaS製品の一つです。

ERPとは、読んで字のごとく「企業の経営資源を一元管理し、企業全体を最適化する」システムです。財務、会計、在庫、生産、人事、あらゆる業務データが一つにつながる。

となると、受益者は誰になるか。

経営者です。
CFO、COOであり、社長になります。

ERPを導入して一番恩恵を受けるのは、経営全体をリアルタイムで把握できるようになる、経営層になります。

ただし現実問題として、社長や経営層に最初から会えるケースはほとんどありません。
最初の商談相手は業務部門、経営企画部門やIT部門の担当者であることが多いと思います。

だからこそ、「受益者は誰か」を常に意識しながら商談を進めることが重要になります。

目の前の担当者に対して丁寧に説明しながらも、頭の中では

「この人は経営層に何を伝えてくれるか」
「経営者が受益者だと理解してもらうために、今何を話すべきか」

を考え続ける。

受益者に直接会えなくても、受益者を意識した商談設計ができているかどうかで、稟議の通り方がまったく変わります。

特化型SaaSでも、ERPでも、受益者を定義するという原則はまったく同じです。

製品の規模が変わっても、この問いから逃げることはできません。

受益者を正しく定義することには、実はもう一つの意味があります。

それは、契約後、誰が真っ先に「使えている」と実感し、社内でこの製品を守ってくれるか、
つまり定着化の当事者になる人を、商談の段階から見極めておくということです。

受益者を取り違えたまま契約すると、稟議は通っても、契約後に誰も本気でこの製品の定着に責任を持たない、という事態が起こります。

受益者の定義は、稟議を通すためだけでなく、契約後の定着を誰に託すかを決める作業でもあります。

まとめ：SaaS商談の前にやるべき「2つの問い」

課題確認の前に、まず自分に問いかけてみてください

① このSaaSの本当の受益者は誰か
   （どの部署・担当者か）

② 商談に来る相手は、その受益者と同一人物か、
    それとも別人か

この2つを明確にしてから商談に臨む営業と、漠然と「課題を聞こう」と思って入る営業では、1年後の受注率に大きな差が生まれてきます。

ここまで読んできただき、ありがとうございました。
今後も、SaaS営業の現場で使える実践的なノウハウを発信していきます。
今回の記事が参考になった方、ぜひフォローをお願いします。

次回（第2回）は、受益者が定義できたら次に何をすべきか。
「業務のBefore/Afterを先に見せろ」という話をしたいと思います。

▼本記事は3部作の第1回です。あわせてどうぞ。
第2回：業務のBefore/After

第3回（最終回）：提案書の書き方

【SaaS ITベンチャー経営者様, SIer SaaS事業部様へ】

本記事で解説した
「業務のBefore/Afterの描き方」や
「決裁を通す提案書の構造」
理屈はわかっても、いざ自社の商材（SaaS）に当てはめようとすると、手が止まってしまうことはありませんか？

「うちの商材の場合、どうBefore/Afterを描けば経営者に刺さるのか？」
「今の提案書をどう直せば、稟議が通りやすくなるのか？」

30年以上の現場経験をもとに、御社の商材に合わせた具体的な見せ方を一緒に整理します。

ぜひ、現在の提案書をベースに壁打ちしてみませんか？

法人向け、営業コンサルティングメニューはこちらにまとめています。