2つのSaaSプロダクトタイプ
SalesやCSの支援方法、プロセスなどを考えるにあたって
「プロダクトの何をアピールすれば響くのか」
「どこでユーザーがつまずきそうか」
などを考慮して、創っていくかと思います。
実際に私も"プロダクトの特徴"を加味して、日々の資料や顧客への支援を試しながら業務に落とし込むようにしています。
今回のnoteは、Magic Successの岡村さんにCS活動についてヒアリング時に
「御社のサービスって、プロダクトの特徴的に活用方法とかを細かく提案していくみたいなことが必要になるんですか?」
と聞かれたときにインスパイアを受けた内容となっています。
背景として、私はRPAとOCRで2つのプロダクトのCSを経験しています。
それら2つがプロダクトとして大きく違う"特徴"が存在したため、どのような概念が存在するのだろうと考えてくうちに発見したことを言語化していった結果、SaaSには大きく分けて2つのプロダクトタイプがあることに気づきました。
それぞれについて、痛いほど体感してきたのでリアルなアウトプットをします。
1. FIT型とBUILD型
SaaSプロダクトには大きく分けて2つのタイプが存在します。
これは私の経験だけでなく、他のCSの方々とも共通の意見を交換したことがきっかけでした。
よくCSの支援方法やオンボーディングプロセスなどを議論する際に
「プロダクトの特徴によるんですけど」
というような言葉が飛び交うことが多い印象です。
もちろん場面によって、人それぞれイメージしていることは変わるかもしれませんが、私の中で考えてみたときに支援方法やプロセスを語る上で必要なプロダクトの特徴、すなわち"タイプ"は大きく2つに分けられるのではないかと仮説を立てました。
弊社内でその考えを共有し、実際の支援方法やプロセスを考えてみたところ、議論の質とスピードがかなり上がり、社内でも一定の共通認識を持ちやすくなることを実感しました。
そのため、自社プロダクトのタイプを理解することはCSとして必須であると定義しています。
ただ、私たちはRPAとOCRの2つの異なるタイプを経験しているからこそ、頭にスッと入り込んできましたが、経験がない or 意識していないとなかなか共通認識を持つのは難しいです。
そのため、今回は2つのプロダクトタイプを簡易的に理解いただけるよう書いていくので、ぜひ自社プロダクトに落とし込んで考えながら読んでみてください。
結論から言うと、2つのプロダクトタイプとは
FIT型とBUILD型です。
FIT型 = 既存業務に当て込むプロダクト
・導入前と比べて業務フローがほとんど変わらない
・利用方法が単一
・初期設定のみ、かつシンプル
・「これが、こう」と説明するだけ
例:受発注バスターズ(OCR)、Slack、クラウドサイン などBUILD型 = 既存業務を大きく変えるプロダクト
・導入前と比べて業務フローが大きく変わる
・利用方法が複数
・継続的に設定、かつ複雑なことが多い
・どのように活用するかを提案する必要がある
例:RPA、Salesforce、Kintone など
特徴などを踏まえると結論、FIT型が分かりやすく、簡単です。
売るのが簡単で、かつオンボーディングもプロダクト目線でいくと単一な方法で実行できます。
(※もちろん個社ごとに対応しなければならないことがあるので、単一的にオンボ達成できるわけではないが、あくまでプロダクトのみで考えた場合)
しかし、BUILD型がただ手間がかかるという理解はもったいないです。
そもそもプロダクトとしての拡張性があるため、アップセルを狙いやすいです。
また、BUILD型のプロダクトを中心に業務が回っていることが多いのでチャーンリスクもFIT型に比べると低いです。
「できることが決まっている」は共通なので違いにはなりませんが、「できる範囲」はBUILD型の方が広くなることが多いです。
※「アナデジ」とは少し違います。
アナログなものがデジタルになることで大きく業務フローが変わるのであれば、BUILD型ですが全てがそうではないです。
現にAI-OCRは、紙やPDFをデータにするという1ステップを加えるのみなので、業務フロー自体は大きく変わらないので、FIT型に属します。
2. CSとしての違い
プロダクトとしての違いについては上記で理解いただけたかと思いますので、ここからはCSとしての支援方法やオンボーディングにおける違いを紹介します。
■ FIT型
・目的とゴールが決めやすい
・オンボーディングの定義を決めやすい
・決まった使い方なので、それに合わせてもらう(※前後の業務フローを整える必要あり)
・細かい要件定義が必要
(※レールから外れることはできない)
(※"できる・できない"がはっきりしている)
■ BUILD型
・目的とゴールが決めにくい
・オンボーディングの定義を決めにくい
・活用方法が様々なので、そこをCSがデザインする
(※全ての業務フローを整える)
・必須な要件だけ確認し、あとはプロダクトごとで臨機応変に対応する
(※最初からできない想定はあまりしない)
■ 共通点
・細かい機能や利用方法などのコンテンツ作成が必要
◯ FIT型 = コンテンツがあればミッドタッチ・ロータッチが可能
◯ BUILD型 = コンテンツがあるのが前提。基本はハイタッチ、コミュニティタッチで加速する可能性あり
弊社もBUILD型(RPA)のときは、オンボーディングの定義などに苦戦しました。
また、支援内容がほとんどサポート寄りになってしまいZoomでの伴奏支援やFAQのコンテンツ作成などがに費やす時間が大半でした。
とはいえ、プロダクトとしてカバー範囲が広かったため顧客のニーズに応えられないことはかなり少なかった印象です。
一方で、FIT型は利用条件やカバー範囲がある程度決まっているので、オンボーディングの定義や支援内容については非常に構築がしやすかった印象です。
ただ、ROIやそれにも伴うExpansionがCSとしては難しいです。
もともと行っていた業務プロセスに当てはめる、または代替されることになるため1つプロセスが追加されるようなパターンが多いためです。
ただこれらはCSだけでなく、開発も含めたプロダクト改善によって解消することが可能です。
3. BUILD型でもFIT型のように売れる
冒頭の結論でもあった通り、FIT型である方が成約後の流れとしてはオンボーディングなどを含めてもシンプルであり、BUILD型はやや複雑だと感じるかもしれません。
しかし、プロダクトの特性がBUILD型であってもFIT型プロダクトとして提供することは可能です。
それは、
あえて業界・業務を限定する
ということです。
Horizontal・Verticalにどう当て込んでいくかによってプロダクトの特性に関係なく、FIT型のプロダクトとして売ることができます。
弊社の受発注バスターズ(AI-OCR)も、元々はHorizontal、かつBUILD型のプロダクトです。
帳票類のデータ化になるので、様々な部門や業界で活用可能です。
・注文書→営業・生産管理部門
・請求書→経理部門
・見積書→購買部門
・納品書→生産管理部門
・検品書→物流部門 など
しかし、細かい話をすると各業界や帳票によって課題感や難易度などが全く違うためプロダクト観点だとユーザーの業務プロセスやオンボーディングの難易度が全く変わります。
そこで弊社はあえて、製造業・卸売業における受注業務に特化したAI-OCRとしてサービスリリースを行いました。
このようにBUILD型のプロダクトでも、あえて業界・業務を限定することでFIT型のように売ることができます。
4. Biz全体ですべきこと
プロダクトタイプは、『ビジネスモデル』に紐づきます。
そのため、ビジネスモデルによってプロダクトの価値が変わります。
そして、Sales・CSのプロセス、アクションが変わります。
つまり、
・ビジネスモデルが「親」
・Sales・CSのプロセス、アクションは「子」
となります。
Biz全体では、中長期的にプロダクトがどうなっていくべきかを顧客のインサイトから提案していかなければなりません。
特にCSは現場に1番近い存在であるため、常にプロダクトに対してのフィードバックをしていくべきです。
またそれは、ビジネスモデルについても同様です。
今回のnoteで1番伝えたかったのは、「2つのプロダクトタイプに対してビジネスモデルが紐づく」ということです。
どんな売り方、見せ方、支援方法などをするかによってプロダクトが売れるかが決まります。
実際に同様のプロダクトにみえて、売れるプロダクト・売れないプロダクトがあります。
また同様のプロダクトにみえて、どちらも売れている場合もあります。
つまり、ただプロダクトタイプだけに注目していくのではなく、
プロダクトタイプを加味してビジネスモデル(= 戦い方)を変化させていくことが必要になるということです。
そのためには、現場に1番近いCSやSalesの方たちが常にプロダクトやビジネスモデルに対してフィードバックを行うべきであり、そのような時間を増やしてほしいと思っています。
私も体現できるよう、引き続きチャレンジしていきます!
それでは、また。
事業成長に合わせて、CS組織も成長させていかねばならず絶賛採用中です!
少しでも興味がある方はぜひカジュアルにお話だけでもしましょう!
※募集:カスタマーセールス・カスタマーサポート・カスタマーマーケティング