今回のnoteではエンタープライズSaaS営業には必須となる2枚のスライドについて解説をしていきます！

このスライドを作成することで、

・お客様の意思決定が早まる
・オンボーディングが順調に進みやすくなる
→炎上や解約をプリセールス時に未然に防ぐ

といった効果にも期待ができます。

早速解説･･･の前に、

・エンタープライズって何のこと?
・大企業ってことだよね?
といった理解の方は以下のnoteも事前に読んで頂けると良いかなとおもいます。

※SMBのSaaS営業の方にも実践して頂きたいのですが、使う時間とのトレードオフとなるので、各々判断してくださいね。

①営業フレームワーク(MEDDICやBANT)を捨てよう

まず初めに、営業フレームワークは捨てましょう。

多くの方の勘違いは、MEDDICやBANTを聞いたら売れると思っている点です。
そんなワケありませんw

MEDDICやBANTは、売れている営業がヒアリングしている内容を逆引きしたらこの内容だったというものです。

さらに、圧倒的な売り手目線のフレームワークです。
お客様からお聞きしたMEDDICやBANTを完璧に提案書に書いたら買って頂けるのですか?
んなアホなw

さらに、とにかく古い概念です。
BANTはIBMが1950年代に、MEDDICはPTCが1990年代に作ったフレームワークです。
インターネットもマトモにない時代の購買のお話です。
参考になりません。

これからの時代はお客様が実際に体感する変化にフォーカスして提案をする。もっというとお客様と共創していく時代になります。

売り手中心の時代から、共創(お客様主導)の時代になっていきます。

正しくお客様に起こる変化にフォーカスして行きましょう。
(売り込むためのこじつけ=提案書という構図から抜けましょう。)

お客様は提案書を読んでいない

次はお客様の目線から考えてみましょう。
100ページを超える膨大な商品紹介を含んだ超大作の提案書、
(SIer時代はこんな提案書が多かった･･･)
お客様はびっくりするくらい読んでいません。

まず確実に知りたいのは費用とスケジュールです。

絞り込めば8ページに収められると思います。

（このテンプレは汎用的な一例ですが、8ページだと4in裏表印刷にすればA3一枚で完結するのでおすすめです。）

そして最も大切なのは実際にどんな変化が起きるかです。
ここの変化がプラスの方向でなければ買う意味がないですし、売ってもいけません。

｢なんとなくええ感じ｣ではなく、
｢明確にこんな変化が起きる｣というところまで示し、お客様と共通認識を持つことが重要です。

変化を可視化し、共通認識としておかないならば、どこまで行っても前時代的な勢い任せの営業でしかありません。

お客様が知りたいのは、業務とIT、2つの変化

さて、ようやくここから本題です。

お客様がSaaSの営業に求めていることは“業務とITの変化”です。
これらを2枚のスライドとして作成し、お客様と共有しましょうというお話です。

ここで注意するポイントは1つだけ。
営業が妄想の世界で作らないこと。

裏を返せば、
お客様はベンダーの営業に丸投げをしてはいけないということです。
お客様と営業で共創するのです。

これが真の合意形成だと私は考えています。

お客様がいつ買うだとか、予算がいくらだとか、誰が意思決定者だとか、そんな内容の合意形成したとことで、
お客様のビジネスにプラスの価値は生まれませんからね。小手先のテクニックに過ぎません。地に足を付けましょう。

1枚目:業務プロセスのAs isとTo be

自社のSaaSを導入すると、どのような変化が起きるのか書きましょう。

例として、自社の問い合わせ管理をスプレッドシートからHubSpotに切り替えたパターンを書いてみました。

もう少し大きい粒度で書くのであれば、こんな感じでも良いと思います。

そしてこのスライドの最大のポイント･･･

業務プロセスの流れ=デモの流れ

となっていることが重要です。

変化を訴求するんです。
｢今のお客様の業務が、このように変化するのです｣

と、お客様の目の前でお見せする。
これ以上の証明はありませんからね。

2枚目:システム構成図

次はシステム構成図です。
SIerの営業ならば当たり前の様に作成するシステム構成図も、なぜかSaaS業界の方々で作っている人はほぼ皆無です。

これは作りましょう。

(サンプルですら作るのに時間かかるので、公開できるものをいくつか見つけてきました。)

出典:CloudSkew

もうすこし簡易的なものですと、
こちらのnoteにかかれている構成図が非常に参考になると思います。

2枚のスライドが表すもの

この2枚のスライドが表すものは何か･･･

運用面とシステム面の双方でどのような変化が起きるのか、
何を改善したら良いのかを明確化すること

です。

以下あるあるネタとして･･･

｢こんなイレギュラーもよく発生して困ってるから、それもシステムで対応できる様にカスタマイズしたい｣ by お客様

これを営業が鵜呑みにして、
カスタマイズの見積をする→物凄く高いカスタマイズ費用
費用を提示→お客様がフリーズ

なんてことありませんか？

正しい対応をするのであれば、以下のような深堀りが必要です。

イレギュラー:どのような内容なのか
発生して:どのくらいの頻度で
困っている:どのような対応が必要なのか

実際には、手で金額を入力することが、四半期に1回、5分で対応できる内容ってこともありますからね。
システムで対応すべきか、運用で吸収するべきか、その判断を正しく行う材料として、この2枚を作っていただければと思います。

ITの営業であれ

ここまでの内容を読まれたSIerご経験者の方からすると、
｢何当たり前のコト言ってるの？｣
くらいのレベルだと思います。

しかしながら、多くのSaaSの営業がここまでやっていません。

お客様の目線からすると、ここまで一緒にやってくれるなら、信用もできるし、社内を説得しやすいと思います。

この内容すら出来ていないのに、
お客様との合意形成と口にするなんてあり得ません。

｢SIerはダメだ｣と口にするSaaS業界の方も少し考えてみてください。
SIerが当たり前にやっている内容すら出来ていないなら、いつまで経ってもSIerに勝てませんからね。

バリューセリング？
コンサル営業？
ミッション・ビジョン・バリュー

このような美しい綺麗事を並べるのは簡単ですが、SaaSの営業やスタートアップの営業である前に、ITの営業であることを自覚しましょう。

あまりズバッと言う方は少ないかもしれませんが、あえて言います。

上記のような綺麗事並べている“だけ”の方は、
業務知識(理解)不足とITリテラシーの無さを誤魔化しているだけです。

SaaS SE全盛の時代が来る

エンタープライズSaaS営業はここまで責任を持て！と厳しく書いてきましたが、完璧に出来る営業なんて日本中探しても極少数だと思います。

これらは、全てを営業が作るワケではなく、タッグを組んで共同作業をしていきます。

そのタッグパートナーが、SEと呼ばれる職種の方々です。

(SE:ソリューションエンジニアやセールスエンジニアの略)

外資系のエンタープライズSaaS企業では必ずと言っていいほど、SE組織が設置されています。

SaaSのSEはSIerのSE(システムエンジニア)とは異なり、
プリセールスからオンボーディングチームに連携する部分まで、営業とタッグを組んで行動するパートナーです。

個人的にはThe Modelの図の中にSEが書かれていないことがとても悲しいのですが、図で表すとこんな感じです。

ここまで書いてきた内容をすべて営業だけで作れ！！と言われても、なかなか難しいと思いますが、
“エンジニア目線”で、営業とタッグを組むSEと協力しながらお客様と対話して作成していくと良いと思います。
(営業だけで実施できたら最高)

このSEという職種、日本にはまだまだ人数が少ないため、配置していないSaaSベンダーも多いと思います。

しかし、日本のSaaSはこれからエンタープライズを目指す(キャズムを超えていく)段階です。
営業よりもSE全盛の時代がまもなく来るのでは？と私は予想しています。

※優秀なSEの行動特性
というnoteで後日まとめようと思います。

この内容、ウェビナーを実施したら興味ありますか？

最後になりましたが、ここまでの内容を、

・基本的な考え方
・実務で使うテクニック
・組織や文化の醸成

といった内容でウェビナーを実施したらご興味ありますか?

準備に少し時間がかかるので、ご希望なさる方が多ければ実施しようと思っています。

Twitterなり、noteなり、レスポンスを頂けたら幸いですが･･･

こちらのフォーム　からウェイティング登録頂けたら一番把握しやすいので、何卒お願いします。
登録して頂くと、実施決定となった際にすぐにご連絡ができます。