実証実験「PoC」を安請け合いしない営業術 #SaaS営業論

PoCとは、本契約前に実際のプロダクトにお試しで触れることで、検討の確からしさを上げる実地での検討方法で、いまや主流になりつつあります。

このPoC、普段の営業をしている中で、突然求められることがあります。

慣れていないと「商談が進んだと思って狂喜乱舞。散々実施や検討に時間と手間を取られた挙句に失注。0円。」というような地獄が発生します。

ただの失注どころか、その手間と時間での機会損失は計り知れないもの。（もちろん、顧客との関係構築などの点で「まったく意味がない」とまでは思えませんが...）

実際、PoCも契約だからと油断していたら、簡単に本契約時に失注するし、危ないからとPoCの契約が取れても結局営業活動がずっと続き、本契約を取るために2回営業しているくらい工数がかかります。

だったら、PoCなんてやらない方が良くないですか？

ただ「知ってさえいれば」必要ないPoCを回避することは意外と簡単で、仮にPoCを実施したとしても、本契約を締結する確率を上げることが可能です。

そこで今回は、大手企業への新規営業で培ってきた営業手法を体系化して、「PoC」を安請け合いしない裏技を公開します。

それでは始めましょう。

1. PoCは果たしておいしいか？

1.1 突然出現してきたPoCとはなんなのか？

念のため、一般的な定義を見てみましょう。IT業界でいくとgartnerは鉄板なので、調べてみると下記の定義となります。

A proof of concept (POC) is a demonstration of a product, service or solution in a sales context. A POC should demonstrate that the product or concept will fulfill customer requirements while also providing a compelling business case for adoption.

PoCは営業において製品、サービス、ソリューションの証明である。PoCは製品あるいはコンセプトが、契約のために説得力あるビジネスケースを提供できつつ、顧客要件を満たすと証明できるべし。

あくまでPoCは、顧客の要件を満たしているかを証明でき、契約のために顧客が社内説得できる材料になるものです。

そのため、SaaSであれば、顧客が限定的な期間で、限定的に活用するPoCが行われるのが一般的です。

1.2 PoCの拡大解釈で「PoC死」が起こる

こうした定義にも関わらず、それっぽい「PoC」という業界大好き3文字略語をベンターも顧客も便利に使って拡大解釈が進みました。

・パフォーマンス確認
本契約しなければ得られないような効果を短期間で得ようとして、本来顧客が購買するために自社の経営層にすべき説明責任を果たさない

・真剣味のない実験
経営層から宿題として出た投資テーマでなにかをやった痕跡を残すために、ただや安価で実験をして逃げる

上記は顧客側の事情が中心に書かれていますが、短期的な売上が上がるため、それに付き合うベンダーが多いことも事実、ベンダー側からしかけていることも多いと感じます。

私も最近パートナー企業との初回の打合せで8割くらいの確率で「PoCってできるんですか？」と聞かれるくらいです。なぜ本契約を狙わないんでしょうか？

こうした拡大解釈によるPoCの大流行によって、いつしかPoCは失敗を量産することになって「PoC死」という言葉が生まれたくらいです。

1.3 PoCに安易に触るな危険、メリットとデメリットを整理する

では、全てのPoCがダメかというとそうではなく、PoCのメリット・デメリットを理解して、使い分けることが重要です。

PoCのメリットは確かに存在するので、顧客とベンダー側の利益が一致することと、デメリットにあたる部分がお互いで補填できれば、良いPoCになる訳です。

＊＊＊

ということで、PoCを安請け合いせず、やるとなったら良いPoCにするためにはどうすれば良いのか、下記のように具体的に手法を順を追って説明します。

2. 本当にPoCが必要か？を議論しつくせ！

とにかく誰もが聞いてくる「PoCできるんですか？」という質問から真剣勝負が始まります。

決まって私は、

「PoCはそれぞれ個人によって定義が違うので、貴社がPoCをどう捉えているかを理解したいのと、なぜ御社はPoCをやりたいのかをお聞かせいただけませんか？」

と聞くと、単純にできるのかなと思って聞きました、という回答が多く、3割はこの質問でPoCがなくなります。この回答でまともに返ってくるパターンとしては下記になります。

2.1 「機能を確認したい」

「お金をかけずにやれる方法があるので、まずそれをやりませんか？」

で詳細デモに持ち込む、だいたいこれで解決します。

さらに「本当に自分たちでできるのかが不安」という場合には、ユーザー訪問など、顧客の解像度をあげるようなアクションをうちます。これで解決できない問題があるときに始めてPoCに応じます。

2.2 「実際のパフォーマンスが出るか確認したい」

パフォーマンスを出す最適な期間として、本契約の契約期間が設定してある訳で、そこにも意味があるんですよ。それを伝えるためにも、ストレートに

「契約期間が1年間にしている理由は、それがお客様が効果実感をしてもらえる期間だということです。

それより短いケースは何かを無理することになるので、お互いパワーがかかります。特殊な事情がない限りは普通にプロジェクトを進めることをご提案しています。

それにSaaSは実際パフォーマンスが出なかった時に利用を止められるというモデルなので、本来お客様にメリットがあるモデルなんですが、お客様のご不安な点はなんですか？」

と聞くと、納得してくれたりするので、通常契約の話をして、クロージングに持ち込みます。

もし、ここで不安がでてくるようであれば、それを解消するようなアクションを一緒に考えるのが良いですね。

PoCに応じないと解決されないケースは、会社として本契約前にPoCが義務化されているのが理由だったりします。

2.3 「目的がない」

目的がない場合は、PoCの失敗を招きます。これもストレートに伝えます。

「目的がないPoCは、多くのお場合は失敗して、両社不幸になります。

だから、私はやりたくなくて、やるならお客様と真剣勝負をしたいので、どういうことを主目的にやるか、ディスカッションさせてください」

といって、何のためのPoCなのか、を議論して、必要なPoCなのか、今の不安材料が解消すれば通常提案から本契約できるのか、を明らかにしていきましょう。

このディスカッションに応じないのであれば、基本的には商談ではないので、迷わずに失注にしましょう。

とはいえ、どうしてもこの顧客は入り込みたいという顧客もいると思うので、その際はプロジェクトメンバーにも覚悟をもってもらい、会社としてやるかどうかのジャッジが必要になります。

＊＊＊

ここまででPoCの目的を議論することで、無駄なPoCを削ぎ落とすことができてるはずです。とは言え、PoCは0にすることはできないと思いますし、戦略的にPoCをやることもあると思います。

まだ手を抜けません！PoCを契約する前にまだまだ仕込むことがあるんです。これでPoCの成功率は大きく変わります。次にそれを説明しますので、しっかり最後まで読んでください、あともう少し！

3. PoCをやるなら、絶対に成功させる3つのチェックポイント

目的をきっちり両社で設定したPoCは成功に近づいていると言えるでしょう。とはいえ、まだPoCでやる具体的な議論はできていません。そこを契約前に詰めることが成功率を確実にあげます。

以下3ステップを実施して、PoCの成功を確実のものにしましょう。

3.1 ただより高いものはない

まず予算確認です。予算がなく、PoCはただもしくはただ同然でできるという勘違いもあります。

ただでやることは簡単ですが、顧客に覚悟がなく、真剣にやらずに終わることもかなり多いので、PoCに応じる場合は少しでも金額を出してもらうことは必要なステップです。

私はたいてい

「貴社の目的に合わせれば、PoCと言えど、しっかりプロジェクトをやらないと期待する効果は得られないので、費用をいただいて実施しています。」

と事実を伝えて、顧客の反応をみます。反応を見れば、予算を考えているかどうか、本気度があるかどうかわかります。予算面に不安がないことがわかれば、PoCを実施する議論を進めましょう。

顧客が予算がそれでも出ないという場合は、例えばデモをより詳細にやりながら顧客が活用するイメージを作るなど、予算がなくてもできる方法を議論しましょう。

3.2 やる前から成功を決める

PoCの目的確認である程度明らかになっているものの、再度具体的な成功基準を議論すること。本契約となるにはどんな材料が必要なのかを議論して、具体的な内容を詰めていきます。

特に顧客がPoC実施の際に成果を求めてきたときは注意です。

自社が求める本契約の期間よりも短期間になれば、本契約と同等な成果を期待されても難しいので、PoCを成功させるために、適切なゴールをどこに設定するかを顧客と握りましょう。

ここを握れれば、自社のリソースをどう投下するかも決まりますし、顧客の要求があまりにも過剰な場合は調整をプロジェクト前に実施することが可能になります。これがトラブル防止に繋がります。

乖離が埋まらない場合はPoCを諦めてもらって、再度通常提案に切り替えることも一つの手です。あくまで自社の論理ではなく、顧客の目的で語るのがポイントです。

3.3 PoCが成功する期間に整える

成否基準が決まれば、最低限必要な期間は定まるため、その期間も握ってPoCを実現しましょう。

顧客側の事情で異様に短い期間でやらなければならない場合もあるので、そのケースは成否基準に戻って再度議論しても良いでしょう。

実際このやり取りの中でも、そもそもPoCじゃなくて、普通にプロジェクトとして実施した方がよいですよね、となることもあります。

PoCをしなくて良いなら、やらないにこしたことはない、顧客の成功を考えて徹底的に議論しましょう。

＊＊＊

私の経験則も極力一般化してお伝えしましたが、偏りがあるだろうと思い、PoCネタのツイートに反応してくれた法人営業の猛者2人にPoC回避策を聞いてみました。

特別編：2人の法人営業の猛者にも聞いてみました！

■あくえりさん

＜営業の違いによる PoCの捉え方の違い＞
大手SIのエンタープライズセールスでは、顧客1社で年間3桁億の売上になります。限られた大手向けの市場で、営業も1社を複数人で担当する体制です。

この場合、野村さんのようにドライにPoCを捉えすぎると、貴重な商談機会や競合優位性を失い、結果的にビジネスが縮小するリスクがあります。

＜PoC回避策＞
このnoteと同じようにPoCを牽制する動きは共通してやります。

ただ、目的がないPoCでも付き合い、検討目的を作るところから、有償で顧客に伴走していきます。

イメージとしては、PoCという名で検討支援を行い、本契約に向けた社内説得材料を一緒に作る感じです。これでPoCの7割程度は本契約に移行できていました。

＜Twitterリンク＞
あくえりさん：https://twitter.com/beh1st

■すぎぽさん

＜PoC回避策＞
営業側も顧客側も「PoCを実施しない選択肢を評価する」こと。

この基準があると、実施することありきで推進されてしまってるときにも全体のロードマップの中で無駄にならないPoC（あるいは代替の取組み）になって、安易なPoCを避けられます。

顧客側からみて結果的に失敗のPoCであっても、コストに見合った対価が得られるのであれば営業上は案件として失敗にならないので、PoCだからと対価を譲歩せず正当に要求することも重要です。

＜Twitterリンク＞
すぎぽさん：https://twitter.com/koichi2905

まとめ

これでPoCの仕込みは完了です。ここで改めてシンプルにまとめると、

1. PoCを理解する
2. PoCの目的を議論する
3. PoCを成功に導く

となります。ここまでやれば、仮にPoCを実施することになっても、プロダクトが本当に顧客と合わない場合を除き、7割は成功に導けるはずです。

PoCで疲弊しているという方は、ぜひこのnoteを参考に「顧客とPoCの目的を議論する」ところから始めませんか？
※DMなどいただければ、可能な範囲でご相談に乗ることも可能です。

さて、今後は「#SaaS営業論」として、様々なことをテーマに執筆しようかと思っていますので、ご期待ください。

励みになるので、よければこのnoteのシェアやスキをお願いします！