BI ツール、ETL ツール、iPaaS や連携機能を持つSaaS のベンダー様に多く利用されているCData ですが、ベンダー様から「どうせそんなにSaaS 連携を増やしても営業サイドが売ってくれないと意味ないよね」と言われてしまうことがあります。
実際それは、CData 自体がクラウドデータ連携を部品として売っているのでよくわかる問題です。製品サイドが漠然と「連携したんだからドンドン営業に通り売ってほしい」という理想ですが、営業サイドは「そんなこと言って、顧客に迷惑かけそうだから売りたくない」と心の底で思っています。クラウド連携はロングテールです。クラウド連携は足で売るだけではいけないのです。Web でキャッチして、トライアルしてもらうセールス方法を構築する必要があります。
ロングテールなSaaS 連携は足で売らずにWeb で売る
この記事では、多くのクラウド連携を実装した場合のセールスプロセスの必然的変化とCData のOEM が提供する現実解について説明します。
CData Software のOEM で製品のクラウドデータ連携機能を大幅に拡充
CData Software では、Salesforce、Dynamics 365、NetSuite、Marketo、kintone など200を超えるSaaS、クラウドデータベースなどに連携するJDBC Drivers、ODBC Drivers、ADO.NET Providers などのドライバーとして提供しています。普通にエンドユーザーにドライバーをツールやカスタムアプリケーションと組み合わせて利用してもらっているほかに、BI ツール、ETL/iPaaS ツール、DWH、NoCode ツールベンダー様にOEM としてCData Drivers を製品に組み込んで使ってもらっています。
CData Drivers のOEM 提供先（一部）
ツールベンダーからすれば、リソースはツール自体の機能強化に注ぐ必要があり、数が増え続けるSaaS へのロングテールなデータ連携対応は、必要ではあるけれどROI が合いません。そこでCData Software では、それぞれのツールに組み込みをしやすいドライバーをOEM 提供してツールベンダーのSaaS 連携機能の拡張をサポートしています。OEM 開始から数か月で数十のデータソースの連携実装をリリースすることが可能です。
ロングテールなクラウドデータについては、以下の記事で書いています：
https://www.cdata.com/jp/blog/2019-12-10-231629
あれ、営業がうまく動いてくれない？
製品実装さえおこなえばSaaS データ連携は売れるのでしょうか？そうではなく、プロダクトマネジメントの定石として、営業やマーケティングが同じ製品価値を理解してバリューを押し出すように動かなければセールスには結びつきません。
それでは、食い違う製品サイドと営業サイドの意見を聞いてみましょう：
製品（プロダクトマネージャー）サイドの期待：「普通に売って」ほしい
こんなに連携先を増やしたんだから、連携ニーズのある案件を営業が集めてくれるだろう
SaaS やクラウドDB も主要な10-20だけではなく、新興の勢いのあるサービスにも対応だから隙は無い
機能的にも全エンドポイント（含むカスタムオブジェクト）に対応かつ、CRUD ばっちり
営業側がユーザーからニーズをヒアリングして、各データソース毎にテッパンのソリューションを作ってくれるハズ
元々API 公開されてない機能や書き込みができないエンドポイントとかは「できる」ってコミット絶対しないでね
データソース実装はしたけど、実は全データソースを深く理解してるわけじゃないんだ
営業サイドの現実：ハイリスク、ローリターンだから扱いたくない
ほとんどのデータソースの名前も知らない。それがCRM なのか機械学習プラットフォームなのかもわかりません
お客さんに紹介したら、「それは弊社の何に役立つんだ？」って聞かれて。ソリューション化した資料がないので答えられない
製品サイドが「連携できる」って言っているから案件持ってきたら、「そのAPI はRead-only だから書き込みはできないよ。」と言われた。お客さんに合わせる顔がない
せっかくデータソースについて勉強して、資料も作ったのに、サービス自体を使っているユーザーが思ったより多くない
こんなにハイリスクでしかも全顧客がそのサービスを使ってないなら、営業としては扱いたくない
製品のカバー範囲がロングテールに変われば営業プロセスも変更が必要
両者の言い分は理解できるものです。これまではRDB やCSV ファイル、もしくはSalesforce やG Suite といった比較的多くのユーザーが使っているデータソースに対応してきました。これらのデータソースに対して、きっちりとソリューション化を行い、対象ユーザーに総当たりで拡販するという形でした。「機能を売るな、顧客の痛みとそれに対する提供価値を共にしたソリューションを売れ」というのは対面営業では正しいアプローチです。
ただし、これは「自社の顧客リストの大部分が実装した機能から恩恵を受ける」という前提の下で効果を発揮するアプローチです。クラウド連携はロングテールであり、ユーザーが使っているサービスはばらつきが大きいです。そのロングテールなクラウド連携で同じことをやってしまっては上記のようなミスマッチが起きてしまいます。これまでのような人的リソースを必要とするソリューション営業のアプローチを多数のクラウドデータソース向けに行うことは得策ではないと言えます。
ロングテールなクラウドデータ連携を売る場合には、前提として、営業やテクニカルセールスの担当者はデータソースについて顧客が知りたいレベルで知識を持っていることはできない、という前提で販売プロセスを組みなおす必要があります。
クラウド連携は足で売らない、Web でリードを集めて顧客がトライアル
ロングテールなSaaS 連携には、これまでと同じ営業を使ったソリューション型はフィットしません。SaaS 連携機能の付いた製品を売るためには、Website でのリード創出、そして顧客自身が製品をトライアルして評価するという方法がベストです。
顧客は自分で調査する時代に
顧客に自分で探してもらって、自分で評価してもらうというと、驚かれる方もいらっしゃいますが、インターネットで多くの情報や口コミが取れるようになり、顧客の購買パターンが変化しています。以前は顧客の認知から購入までのプロセスの大部分は「営業からの情報提供・提案」が占めていましたが、現在では、「顧客による調査・評価」が一番大きな部分を占めています。すでに顧客は営業さん頼みではないのです。さらにコロナ禍でこの流れは加速していると思います。
出展：THE MODEL より
であれば、営業担当の顧客へのソリューション紹介を購入プロセスの起点とする必要は全くありません。顧客の購買プロセスに変化が生じたい今であれば、ロングテールのクラウドデータ連携機能を顧客に効率的に販売できるはずです。
Web に対応データソースと対応範囲をきっちり書こう
顧客の購入プロセスはデジタルから始まります。BtoB の多くは検索から始まります。「自社のツールが多くのクラウドデータソースと連携できる」という情報は営業のPPT だけでなく、まずはWebsite の製品ページに載せるべきです。掲載の仕方はフワッと動画や画像のなかにデザインとしてロゴを並べても検索エンジンは見つけてくれないので、テキストで載せるようにしましょう。「自社ツール名+ Salesforce」もしくは「自社製品のジャンル+kintone」のようにデータソース名と検索した時にちゃんとTOPに自社ページが来ればばっちりです。
ただし、連携するクラウドサービス名が載っているだけでは、それ以上の情報を得ることができません。サービスへの連携で顧客が次に考えることは「実現したいエンドポイントに対応しているか」でしょう。どんなエンドポイントに対応しているのかという情報はからなず検索した顧客が見えるようにしておきましょう。CData では、データソース毎に対応するオブジェクトのリストがドキュメントおよびドライバーのコードから取得できるようになっています。ドライバーをOEMしたベンダーは、自社のWebsite やドキュメントにデータソース毎の対応オブジェクトを取り込んで表示することが可能です。
Salesfroce Driver のオブジェクトリスト（一部）
トライアルへの導線を
潜在顧客がWeb で製品を見つけてくれたら、次のステップはトライアル版への誘導です。まだ貴重な営業リソースを使う段階ではありません。ロングテールなクラウドデータ連携では、営業担当がユーザーの知りたいことを知っていると考えてはいけません。電話でアポイントを取って、1－2週間後に訪問しても、お客様に聞かれたことに対しその場で情報提供はできないで、持ち帰るばかりです。たとえテクニカルセールス担当であっても数十のデータソースのその中の特定のオブジェクトが使えるかどうかという情報を知っておくことには無理があります。そこで顧客の不確実性を早いタイミングで減らす方法がトライアルです。
Web でキャッチしたユーザーにはトライアル版に誘導しましょう。特にBI、ETL、DWH を使うようなエンジニアやそれに近いユーザーの場合には、トライアルに手間がかかるのはよくありません。まずは製品を使えるようにして「Hello World」をやってみる（一番日本的な使い方をする）までの時間は「TTFHW（Time to First Hello World」と言われており分単位での実現が必要です。先に資料請求とか一度営業がお話を伺ってという方法では大事なリードが離脱してしまいます。営業が声をかけたければ、トライアル取得時にE メールを入力してもらう仕様にすればいいだけです。
「このエンドポイントにつながります。」より少し多い情報の提供ができれば、顧客がトライアルに進むかどうかの判断を促せます。CData Software では、対応しているオブジェクトの範囲および、これらのエンドポイントで使用できるSQL クエリをドキュメントで公開しています。これなら顧客はWebsite やドキュメントの記載を見て、自分が実装したい連携にこのツールが対応しているか、トライアルをしてみる価値があるのかをすぐに判断できます。
ドライバーで使用できるSQL
逆にトライアルを提供していないと、「このデータソースに連携できるとは書いてあるけど、実はサンプルエンドポイントへの連携デモができるだけで、実利用の際にはカスタム開発」という製品じゃないかと勘繰られてしまいます。CData Drivers では実装しているオブジェクトとSQL クエリは完全公開ですので、すぐに実利用に近いトライアルを行うことができます。
トライアルユーザーからの質問で、ドライバーに関する部分はCData のプロフェッショナルサポートチームにお聞きください！
実際に顧客がトライアルをしてくれると、いろいろな照会が出てきます。トライアルユーザーの照会は「このデータが取れるか？」「このSQL で通したい」というような実践的かつピンポイントの照会になります。このような照会に対するサポートでは、是非CData Software のプロフェッショナルなサポートを頼ってください。弊社のサポートはフワッとした安心を求めるサポートは苦手ですが、実践的なクエリや接続に関するサポートは得意です。多くのエンドユーザーやOEM ベンダーのサポートを行っているチームにはどこよりも知見があります。
まとめ
このように、OEM で実現可能になったロングテールなクラウドデータ連携には、従来の営業リソースを使ったソリューション営業スタイルは不向きです。まずはWebsite で「自社ツール＋データソース名」の検索を逃さないこと、データソース毎の対応オブジェクトや対応クエリ操作を公開して顧客がトライアルに入る判断をしやすくすること、トライアルまでのステップを短くすることが必要です。顧客はすでにこのような購入プロセスに寄ってきています。是非製品サイドとマーケ、営業サイドでこのような購入プロセスを念頭に、営業リソースの手を掛けずにクラウド連携サービスの顧客をキャッチできる体制を整えてください。貴重な営業リソースを使うのはそこからです。CData Software は、そのようなプロセスに合わせた製品、ドキュメント、サポート提供をして参ります。
関連コンテンツ
