見出し画像

トライアルをただの"お試し"で終わらせないために

こんにちは。アルプのカスタマーサクセスの水谷(@ryoji0112)です。

アルプは、サブスクリプションビジネスを行う企業向けに、今まで手作業や自社開発がスタンダードだった契約や請求管理を SaaS として提供する Scalebase というプロダクトを開発しています。

SaaSはすぐにプロダクトに触れることができる特徴があるため、本契約前に検討の確度を高めることを目的として、お客様から「トライアル」や「PoC」を求められるケースが多いと耳にします。(実際に他社さんのSaaSのLPで見かけます。)

Scalebaseも検討の最終段階でトライアルを依頼されるケースがあります。
業務アプリケーションであるため完全再現はできないものの、すぐに試せる部分もあるためSalesと相談してお受けするケースがあります。

前職の大手企業向けのERPソフトウェアではトライアルの提案を経験したことがなかったため、SaaS業界に転職して初めてこの概念に出会いました。
はじめは、営業のような、オンボーディング(プロジェクト)のような、この狭間のフェーズで何をすべきか曖昧な状態でしたが、ここ1年の間で100%に限りなく近い、高い確率で本契約へと移行することができてきました。

そこで今回は、具体的な実行内容や重要だと感じている点をお伝えし、トライアルの計画や実行を担当されている方の何かヒントになれば幸いです。

※PoCとはそもそも何か?や営業論についてはとても良い記事がありますのでご覧ください。

トライアルを申し込まれるお客様の心理

ビジネスパーソンとしてシステムの比較検討・上申を経験することは多くはありません。私が担当したお客様を見ても、初めてのケースが大半で、多くて2~3回というのが実感値です。
特にバックオフィスに近い領域ほど長期的に使うことを前提とした選定になる傾向があるため、不安になったり慎重になることは当然の心理であると私は考えています。

上申時は「なぜシステムを導入しなければならないのか」から始まり、「なぜそのシステムにするのか」「ちゃんと要件は満たせるのか」「投資対効果は出るのか」「スケジュールには根拠があるのか」「体制や役割分担は妥当か」など、決裁取得のために社内に丁寧に説明していく必要があります。

お客様は、トライアルやPoCという手法にこだわっているわけではなく、不安を取り除き、比較するための説明材料が欲しいのです。
本当は、比較検討中のシステムを全部導入して、実際のデータを入れてオペレーションを回してみて効果が出るのか?というのをやってみてから判断をしたいのですが、お忙しいご担当者さんにはそんな時間はありません。
システム導入というミッションを絶対に成功させるため、とりわけ不安な点だけでも実際に試すことで選定中のシステムを確信したいのです。

※Expansion に関する施策や日々のオペレーションについては下記記事もご覧ください。

システム検討に長けている方以外のご担当者の方は、どのように進められれば自分の不安を解消できるのか、時間が有限な中でもリスクヘッジして進められるのか、通常の業務と並行して手探りで進められています。

そのような状態でトライアルのお申込みをいただくので、お客様からいただくご質問や打合せのご依頼をただ受けているだけでは、その不安を解消することはできないと私は考えております。


トライアルの成功確度を上げる4つのステップ

我々はSalesとCSが連携して、下記を順に実施しています。

1. Salesと同様の解像度で状況を理解する
2. 目的・不安を言語化し共通認識を持つ
3. プロジェクト化しお客様をリードする
4. 信頼関係を構築する

1.Salesと同等の解像度で状況を理解する

いきなりですが、非常に重要なポイントで、ここでコミュニケーションGapが起きると、その後どれだけ素晴らしいプロダクトや支援が控えていても不安は取り除くことができません。また、結果失注となってしまったときも原因がわかりません。「ゴール発想」「目的志向」です。

弊社ではトライアルに進んでいただく可能性があるお客様は、全件CSへ連携するようになっています。
営業経験のあるメンバーの多いCSとしては、どのようなトライアルでも相談を持ってきてくれて感謝(そして、どのようなトライアルでも必ず受注する!)の気持ちしかありません。
しかしながら、この状況でいきなり進んだとしてもお客様と弊社の双方にとって良い時間を過ごすことができないのではないか?という状況があります。

それは「お客様の目的」「意志決定プロセス」「自社の差別化」を我々自身が言語化できていないケースです。

・お客様の目的:トライアルをせずに契約ができなかったのはなぜか
・意志決定プロセス:トライアルという手段を選択されたい理由は何か
・自社の差別化:Scalebaseにどのようなメリットを感じてくれているのか

営業フェーズという性質上「完璧に把握してからCSに持ってきてほしい」はとても無理な要望であると理解しているため、商談に同席してヒアリングをフォローしたり、よりScalebaseへの解像度を高めていただけるようお客様の商品を設定したデモンストレーションの支援等を行います。
ここで重要なのは、SalesとCSが上記について同等の解像度になることなので、例え一部が曖昧であっても、「目的については少し曖昧である」という解像度が揃っていれば、SalesとCS双方合意でトライアル申込のクロージングをします。

ここで、ゴール発想・目的意識、と言いつつ、「曖昧であっても解像度が同等であればトライアルに進める」と記載していることに違和感がある方もいらっしゃるかもしれません。

弊社のSalesは基本的には上記内容を整理して以下のような情報を連携してくれます。

画像1
あるお客様への提案の実際の資料(※固有名詞のみ一部編集)

スピード感、コンペ状況など、いくらSalesがシナリオをひいていてもその通りにならないときが多い(営業の面白さ)ですし、一方で、お客様の中で本当に曖昧であるというケースも多いです。
後者の場合であっても、我々はお客様のご不安に寄り添って進められるような経験値が増えてきたので、同等の解像度であれば良いというコミュニケーションをSalesとCS間で共有しています。


2. 目的・不安を言語化し共通認識を持つ

トライアルの目的、何を不安に思い、検証したいのか、それは各社さんで背景が異なります。
しかしながら、我々自身が経験値を積んでいく中でトライアルでよく検証されるポイントを予め仮説を立てることができてきました。

目的は概ね以下になることが多いです。

・運用に合うか確認したい
・操作ができそうか確認したい
・費用対効果を確認したい
・稟議や社内承認のための材料にしたい
・いつまでに構築できそうか確認したい
・他システムとの連携について確認したい
・フォロー体制を確認したい(ヘルプセンター、カスタマーサポートなど)

業務要件への適合、UI/UXによる利便性への確信(デモで画面は見ているため実際に試すとどうなのか)、アルプが提示しているコストまたは社内予算に対する削減工数・期待効果との比較、トライアルをして実際に試したという事実の獲得、スケジュールへの納得感の醸成、システム間連携の確実性の担保、CSメンバーへの信頼性 等に分類される

そのために取りうる手法として、不安を取り除くために実際に以下を実施いただきます。

・自社の価格表(プライシング)が設定できるのか確認したい
・イレギュラーな契約条件を持つ顧客を登録したい
・実際にサンプルの請求金額が合っているか確認したい
・特に負荷の高いTOP3を置き換えたときの操作感を確認したい
・契約変更時のオペレーションを確認したい
・現在利用している請求書発行サービスのテスト環境に連携したい
・データのアウトプット要件について説明するので出せるか確認したい

これらを他社さんの事例として提示することで、お客様の中で言語化ができていなかった目的や実施されたいことを必ず初回のキックオフMTGで共通認識を持つようにしてから、具体的な支援内容(検証方法・ステップ)に入るようにしています。


3. プロジェクト化しお客様をリードする

検証方法を提案し、Scalebaseの構造や使い方の説明をしたら後はお客様に実際にお試しいただくのですが、「後はどうぞお試しください」とはしていません。

お客様にも選定のスケジュールがあり、一般的にその期間は1ヶ月程度と非常にタイトです。
既にトライアルに進んでいただいているフェーズですので、お客様社内での進捗報告もあり、それに間に合わせなければなりません。

そこで我々は、何を実施したら最短で契約に進めるか?をお客様と相談するようにしています。
例えば「全部データを入れて数値が合っているか検証したい」といったご要望はお断りをしています。
ほぼほぼ導入工程のすべてであるということもありますが、検証元のデータを揃えて突き合わせる必要があるため非常に高負荷となる一方、契約を先に進めていただくための材料としては一部にしか過ぎず、お客様の検証にかける工数の投資対効果に見合わなくなってしまうためです。

画像2
トライアルから本プロジェクトのステップを可視化したもの

上記のとおり、プロジェクト化していく中では、無事契約を締結いただけた後の再キックオフ、その後も見据えた提案をしています。

トライアルが最も進まない理由No.1は「時間が取れ無くて触れなかった」です。

それに対し、弊社は会議体を設けてトライアルを継続して支援していくのですが、トライアルしてくださるお客様には必ず「トライアルで実施することは本プロジェクトの実施内容を先出ししているものであり、確実に無駄になりません。」ということをお伝えしています。

"トライアルのためのトライアル"にならないよう本番さながらのデータを入れていただくことで検証の際に確信を持つことができますし、テスト検証で入れたデータをそのまま本番移行するケースも多いです。
試すためにデータを入れるモチベーションや、結果としてトライアルの精度が高まり、より"Scalebaseが欲しい"に近づくと考えています。


4. 信頼関係を構築する

我々CSはトライアルをリードできるかどうかが、アルプと契約したい、Scalebaseを欲しいと思っていただけるための非常に重要な要素の1つであると位置づけています。

ただ単にScalebaseの環境を発行して使い方を説明することをお客様は望んでおらず、「自分たちの課題ややりたいことができるのか?」「それに対してCSはどんな提案をしてくれるのか?」を試されていると認識しております。

そのようなコミュニケーションの機会を創出できるトライアルは、工夫次第でお客様との距離を縮めることができる絶好のチャンスです。

課題をヒアリングする際やお客様のシステムを見せていただく際など、お客様と我々の共通認知を高められるのであれば、オフラインで長く時間を取ってお伺いすることもあります。
これに関しては特にテクニック的な要素はありませんが、Scalebaseの検証が思ったように進んでいない場合、一度直接対面で話した方が効果的であると思えばその手段を取るべきですし、それ以外にもコミュニケーションのデザインをしながら、少しでも信頼をいただけるよう対応しております。

結果的に、トライアルから本契約に進んでいただいたお客様とはCSが円滑にコミュニケーションを取ることができ、お客様・弊社の双方にとってとてもハッピーな状態で再キックオフ、プロジェクトに臨めている点もトライアルに力を入れたメリットであると感じています。


最後に

アルプのCSは、トライアルからサクセスまで一貫して、社内の様々な役割のメンバーと関わりながら主体的に取り組むことができます。
もっと具体的に聞いてみたい、面白そう、と思っていただけた方がいらっしゃれば、まずは情報交換などお話の機会をいただければと思います。ぜひお気軽にお声がけください!


この記事が気に入ったらサポートをしてみませんか?