プリセールスのタスク
ここでは一つの参考例としてSaaSソフトウエアベンダーでのプリセールスのタスクについてまとめてみたいと思います。
定義
プリセールスのプロセスの中でここで扱うのはエンジニアによる支援部分、つまりプリセールスエンジニア（ソリューションコンサルなどと呼ばれる事もある）の範疇を扱うこととします。また、パッケージソフトウエアを例に取った内容となりますので、全ての業種に当てはまる物では無いことをご了承ください。
案件の支援という観点のタスクを一例として以下のように整理します。
営業とのタスク
案件の支援を行う以前にプリセールスは営業と同じ売り上げ目標を担うチームとして、営業チームとともに目標の数字達成のために必要な一連のタスクを一緒に実行します。
毎年その年の期首に行う事として、年間計画の確認から始まり、プリセールスとしてはどの業種でどのようなプロダクトミックスに注力するか、新たに技術習得の必要な新製品を適用する必要がありそうか、インテグレーションを行うパートナーソリューションで注力するものはあるか、などの技術的な観点でのプランを営業からのインプットをもとに策定します。
大手顧客の場合、アカウントプランニングセッションへの参画も行い、顧客の各事業で使っているシステムやその改修時期、ホワイトスペースなどの情報からその顧客のソリューションマップ（どの事業部でどんなソフトウエアが使われているか、提案するスペースはあるかをまとめたもの）を作成して、販売機会がどこにあるか、その提案規模はどの位になりそうかなどを見極めます。その時点で不足している情報なども明らかにして、ヒアリングを進めるべき内容も決めてゆきます。
中堅以下の顧客を扱う営業部の場合は顧客を特定しての活動は難しいため、注力する業種やプロダクトの絞り込み、セミナーの実施計画などのパイプライン醸成のための集客イベントの計画などマーケとも協力して策定します。
商談の支援依頼の精査
アウトバウンドで仕掛けている場合を除いて、プリセールスのプロセスの開始は営業からの支援依頼になります。パイプラインの会議に参加している場合は、その中から今後支援すべき案件などを協議して優先順位を決定することもあります。いずれにしてもプリセールスの工数は会社の資源なので無闇に消費することは許されません。営業の指示だけで動くチームでもありませんから、プロフェッショナルとして案件の精査、どの様に支援するかの確認ができない中で支援業務を開始することはありません。つまり、プリセールスのマネージャーは良い意味でゲートキーパーとして依頼案件を選別する必要があります。私は依頼を受ける際に提案の背景、顧客が達成したい内容、顧客側の検討チームと顧客の誰に何を訴求すべきかの案、クロージングまでのマイルストーン、この時点までに提案している内容などをリクエストフォームに入力してもらい、アサインをするかの判断をしていました。ジュニアな営業ではヒアリングしている内容に不足が見られるとこと多いので、その段階では担当の営業へアドバイスも行って不足している内容などどの様に確認するかのサポートを行います。必要に応じて営業育成のための同行訪問など行う場合もあります。
このフェーズをきちんと行うことで、案件の成約率は確実に上がりますし、プリセールスの工数を無駄に消費することも少なくなります。
良く言われることですが、シニアな営業がプリセールスを鍛え、シニアなプリセールスが営業を育成するのだと思います。
提案の枠組みの構築
対象の案件で顧客の要望する内容に対してそれを解決することで本当に顧客にとって価値があるのか、それを実現するためのROIは担保できるのか、顧客の気付いていない価値を提供できる可能性はないのかなどを一歩引いた視点から考えて、全体の提案の枠組みをどうするかを考えます。経験的に多くの場合、顧客が製品のことを熟知していることはありませんから、目先の課題の解決に焦点が当たって、将来的な価値を見逃している可能性は多いと思います。また、選択しようとしている製品の導入が目標の様に捉えられ、本来の達成すべき目標が曖昧な場合なども多くあります。その際に、改めてどの様な枠組みで提案するかを考えることは重要です。プリセールスは準備でその成果が決まると考えており、このフェーズは非常に重要なものとなります。
Fit＆Gap分析（フィージビリティ・スタディ）
パッケージソフトウエアを提案する場合に重要となるのが所謂Fit&Gap分析と呼ばれるタスクになります。このタスクは顧客の要件をヒアリングして販売するソリューションが要件を満たすかの確認を行い、どの様に顧客の要件を実現できるか、代替案は何か、ソリューションが適さないケースがあるかを考察します。必要に応じてリスクが高いと判断された場合には案件のGo/No Goを判断する場合もあります。無理に販売して導入プロジェクトのトラブルを起こしたり、稼働してからの問題が起きないようにゲートキーパーとしての役割も果たす訳です。ミクロな観点でこのFit＆Gap分析に注力して前述の提案の枠組みから外れないようにすることも重要です。
システムランドスケープの確認
販売するソリューションを導入した場合、顧客のシステム構成とどのように関連するか、必要なインテグレーションをする対象システムや連携方法、タイミング、実現可能性などの確認をし、実装段階の課題がないか確認します。将来的なリテンションを排除する上でも、既存の顧客システムとの密な連携を行う様に設計することは重要で、段階的なインテグレーションのプランを含めてその価値を提示して全体のシステムランドスケープモデルを策定します。
ロードマップの作成
特定の顧客（キーアカウントなど）に対して、システム展開のロードマップを作成することがあります。特に事業部の展開や関連会社への展開、海外事業への展開など、段階的に展開を進めたり、ソリューションの範囲を段階的に広げてゆく計画がある場合など、展開のロードマップを作成して、顧客と合意することによって将来のレベニューを予測する為に活用します。ロードマップは一回作成して終わりではなく、継続的な顧客とのコミュニケーションツールとして、責任者が同席するステアリングコミッティーなどで定期的にレビューして修正をして行きます。この作業はアカウント営業が行うこともありますが、技術的な観点での実現可能性などはプリセールスが確認をします。
デモの構築（場合によってはPOCの実施）
デモはプリセールスに期待される仕事の一つではありますが、現在いくつかの企業では標準的なデモに関しては営業が商談現場で自ら実施する場合も増えてきており、プリセールスのエンジニアはそのデモ環境整備やデモシナリオの整備を行なっています。此処ではその段階を経て顧客の要件を具体的にどの様に実現できるかの確認、UIの確認など後日問題とならないかの確認をしたいという要望に対応することを前提とします。つまり、機能を紹介するデモではなく、カスタムデモを構築して実際にどう実現できるかを擬似的な顧客データでデモを行うものです。ここで重要なのは顧客の要件を超える価値、顧客の期待を超える価値を提供出来るかを検討し、競合との差別化を図る点が訴求できるかと言うことも検討します。言うまでも無いですが、営業から「とりあえず見せてあげて」とか、「まず標準のデモでいいから」という様な要求には答えてはいけません。デモで何を達成するかのシナリオが無い場合はデモの要求は却下で良いのです。
デモの作成やモバイルアプリのモックアップ作成などの作業は海外のエンジニア（インドやベトナムなど）が一括して高い生産性で行なっている場合もあり、その場合は適切に要件をまとめ、シナリオを作成することが求められます。
セキュリティーチェック
SaaSの製品の場合、外部のサーバーにデータが保管され、社外への接続を行うことが前提となるので、顧客の求めるセキュリティー要件を満たしているか回答を求められます。ベンダーはデータセンター、脆弱性、データ保管などが基準に合致するかを証明する必要があり、多くの場合はISMS、ISO27017やPマークなど第三者認定の証明を提示したり、可能な場合はデータセンターの訪問を受ける場合もあります。
個別の案件支援ではなく、パイプラインを増やすなどのマーケティング的な支援を行う事も多く、例として以下の様な内容を含む場合がある。
ワークショップの実施
まだ顧客側に具体的にシステムに対しての要件は無いが、ソリューションを利用して何らかのBreak Throughを実現したいと考えている場合、どのような未来が実現できるかのビジョンを共有するワークショップを実施することがあります。これは案件化するための支援として実施することが多く、顧客の関連部門のメンバーに参画してもらい、現状の課題と解決のためのアイデアを出しながら、並行してベンダーの持つソリューションでどうそれを実現できるかをビジョンデモを構築してイメージを持ってもらいプロジェクト化する為の支援を行います。数回のセッションを経てデモ構築とプレゼンテーションを行うため、数週間の期間も掛かり、重要な顧客や案件について行うことになります。
マーケティング活動への協力
プリセールスの重要なタスクとして、案件の創出への協力が挙げられます。マーケティングイベントでのデモブースサポート、イベント向けのデモ開発、テクニカルセッションのプレゼンターなどがその主なものになります。
後工程へのハンドオーバー
プリセールスのタスクとして案件のクローズだけでなく、顧客に提案した内容が成功裡に実現できる様サポートすることも含まれます。クローズ後の後続の工程への引き継ぎとして、プリセールス段階で得た内容を導入チームへ引き継いで、さらにその後CSMが元々どのような目的で導入したか、達成目標が達成できているのかの計測が出来るようにします。多くの場合顧客は同じことを２度の３度も話すことを望まないし、一貫性のあるサポートを期待するため、こうした引き継ぎは重要なタスクになります。重要な案件の場合はプリジェクトスタート後のセッションにも参加して提案時と齟齬のない進め方となっているか確認しながら初期フェーズが進む様支援もします。後工程をパートナー企業が担当する場合はパートナー企業のプロジェクトメンバーと引き継ぎの打ち合わせを行い、加えてチェックポイントでの会議をして期待される内容で進んでいるかの確認を行います。
この記事が気に入ったらサポートをしてみませんか？