BtoB SaaSにおける商談・契約のデータ管理とは？

おはようございます。こんにちは。こんばんは。
この記事はcmkt Advent Calendar 2020の15日目の記事です。
前回にnoteを書いたのが昨年のcmkt Advent Calendarという点に爆笑しております。来年の目標はもうちょっとアウトプットを増やすことですかね。。。

さて今回はあまり世の中に情報がないように見えるBtoB SaaSにおける商談・契約周りのデータ管理方法に関して紹介していきます。私の所属しているプレイドにおける実際のSalesforce活用を記事にしていきました。弊社の構成が遅れている可能性や汎用性のない可能性はありますが、きっとそんなことはないと信じて書いておりますw
「cmktとなんの関係があるんだよ！」
って言われそうですが、こうしたデータ管理の流れが様々な仕組みを作るのに生かされていきますのであながち無関係ではないと考えています。
各社、既になんらかの管理方法が確立しているかとは思っていますが、なんらか困っている方々やこれから構築される方々の一助となれば幸いです。

■今回紹介する範囲

1. インサイドセールス
2. フィールドセールス
3. カスタマーサクセス
という流れがある中で、2,3部分の商談・契約まわりのみを取り上げています。本来的にはカスタマーサポートとかを絡めた話や実際の利用状況データをどう使うか？みたいな話などもありますが、まとめていくとあまりにも膨大になりそうだったので、それらの点には触れずにあくまで商談や契約をどう管理しているかという点に今回はフォーカスしています。

■ビジネスフローのざっくり整理

ここからが本題です。まずはBtoB SaaSにおける契約に関わる大きなポイントを上げてみます。

  1. 新規受注
  2. 契約更新 (継続)
  3. Up-sell受注
  4. Cross-sell受注

これらが大まかに考えられる管理されるべき業務群です。

これらの業務群をさらに大別すると受注と更新となります。
更新は自動で処理されれば良い(※ 管理する必要がないということではない)。ただし受注は人の手が介在します。
受注に至るまでのフローとしては以下のようなものになります。

   1. 商談を開始する
   2. 見積を提示する
   3. 申し込みをもらう
   4. 受注処理

大まかではありますが、これらのポイントをどのように管理しているか？という話に移ります。

■データ & オペーションの紹介

・新規受注パターン

いきなり新規受注のデータの流れを紹介します。

細かいことをいうと色々あるのですが、弊社の商談・契約周りは商談で詳細を入力してそれを良い感じに後続に連動させています。これによって二重入力とかはせずに済ましているような感じです。
登場するメインオブジェクト(通常のシステムにおけるテーブル。SFではオブジェクトと呼称する)は以下の4つとなります。
・商談 --- 受注までの状態を管理
・見積 --- クライアントに実際に提示する情報を管理
・契約 --- 確定した受注情報を管理
・申し込み --- クライアントが申し込みした情報を管理
簡易ER図としては以下のような形になります。
ちなみに _cと着けているのはカスタムオブジェクト(元々SFで定義されていない独自定義のオブジェクト)です。

・契約更新 (継続)パターン

新規受注はシンプルですが、SaaSにおいて何が面倒かというと更新管理ではないでしょうか？Salesforceさんへの苛立ちポイントとしては自社がSaaSの癖に製品がSaaS管理にトコトン向いていないという点があると思っております。これがmarkdownとかで書いている場合は打ち消し線でも入れていますがnoteなのでそのままの気持ちを表明しておきます。
では実際の更新管理をどうしているかという点の話です。結論から言うとRenewal商談という商談を作成することで管理しています。Salesforceを触ったことのない方向けに翻訳すると商談を履歴割りすることで管理をしている形です。

一つ前の商談が受注になることで更新処理が自動で作成されます。もしも解約(churn)のご連絡をいただいた場合はこの商談ステータスが「失注」となります。ちなみにこの商談ステータスとMRRを元にしながら売上予測的な部分に繋げていたりします。
これはあくまで商談であるため更新するまでを管理しています。実際に自動更新となった場合は契約側も修正する必要があります。契約も商談同様に履歴割るような形で管理しており、特定時期を超えることでバッチ処理にてRenewal商談と同じようなデータを生成しています。
と言うわけでここまでのER図をまとめてみました。

青背景のものが契約更新で利用されるデータとなります。
本来的なER図からズレていると言う認識はありますが、あくまでビジネスに併せて分かりやすさを優先しているのでご了承ください。

・ Up-sell, Cross-sellパターン

更新管理が面倒と上記で書きましたが、それ以上に大変なものとしてUp-sell, Cross-sell管理なのではなかろうかと思っております。。。実際に弊社も大変でした。
どこまでを管理するかや入力の手間によっても大変さは変わる部分ではありますが、理想的には以下のあたりを満たす必要があると考えています。

1. 入力の手間が少ない
2. 商品ごとの純増MRRが管理できる
3. Cross-sell, Up-sell, Down-sellに分けて数値管理, フェーズ管理ができる
    (≒ Renewal商談と混ぜない。失注の情報を管理できるようにする)

結論から言うとCross/Up/Downと言う商談タイプ(レコードタイプ)を定義しRenewal商談から分離し、Renewal商談を良い具合に紐付けることによって情報の連携と純増MRRの計算を達成させています(基本的なフローに関しては新規商談と同様)
どう言うこっちゃ？って感じかと思うので、以下の図を参照ください。

赤背景が最重要ポイント、青背景の部分が入力箇所と言う形です。基本的にCross-sell, Up-sellと言うの既存の契約があるからこそ発生しえます。その既存の契約情報を連動させることで達成したいことを実現させています。既存契約に相当する商談ID=2のRenewal商談を親として設定することによってCross-sell, Up-sellのMRR計算を精緻にしています。
これらの計算を全て手入力を元にして管理するのは非常に大変です。これをRenewal商談の商品の金額は弄らないと言うルールを一つ設け、仕組みを整えることで入力コストや管理コストを徹底的に抑えています。

上の文だけ見るとRenewal商談を親商談IDにするのではなく契約を紐づければ良いのではないか？と言う疑問が生まれるかとは思います。これはCross-sell, Up-sellのその後のオペレーションを考慮しての構成です。弊社のルールに依存している部分も大いにありますが、Cross-sellの場合、既存の契約に商品を追加するだけの場合と契約自体を巻き直す場合があります。契約に関しては申し込みを通して処理されるので特に問題ないのですが、商談側にも良い感じにデータを反映させるためにこの構成となっています。
文面だけ見ると分かりにくいですが、以下のような感じでデータ更新をしております。

青背景の部分が商談ID: 2が受注になったタイミングで自動更新される箇所です。

では最後に新規商談からCross/Upも含めた全体ER図です。

青背景のものがCross/Upのオブジェクトです。赤線の箇所が特に肝となっているリレーションの部分です。

■おわりに

・これらのデータを元にどう言ったことを施策を実施しているか？
・これらのデータをどのような形でモニタリングしているか？
という部分まで踏み込もうかと思ったのですが今回は諦めました。。
また本来的にはこうした構成の方が良いよな！と思っている箇所もありますが、大幅なそもそもから始める必要があるのでこちらも諦めました。。
需要があれば書きたいと思います。

cmkt的に応用効くのは今回の話に加えて人のデータ(≒ 取引先責任者)をどう管理していくか？と言う点だと考えています。そのあたりの話は新年に頑張って整理するつもりです (1年後にはならないようにします...)。

上で諦めている点や今後整理しようと思っている部分に興味のある方、社内のデータ管理に悩んでいるという方はtwitterとかで連絡もらえると嬉しいです。
是非一緒にお酒飲みましょう！！！！w

と言うわけで、cmkt Advent Calendar 2020の15日目でした。
16日目は事例作りと言えばこの方！のふじじゅんさんです。
皆様楽しみに待ちましょう〜〜〜！！！！