Scalebaseを使ってHubSpotのカオス化を防ぎながら、BizOps業務をスマート化したお話
この記事はマネーフォワード関西開発拠点所属メンバーによるアドベントカレンダーの6日目の記事です！ほかもぜひ読んでみてね！
https://adventar.org/calendars/9990
こんばんは！マネーフォワード i で Adminaプロダクトを開発している umisora です。関西拠点アドベントカレンダーはエンジニアが多く記事を書いている状態ではじまりました。
私のテーマは、、、
HubSpotのカオス化を防ぐために、契約・請求を分離した話。
そのためにScalebaseを契約した話。
0. なぜこの話を書こうと思ったのか
私が今回お伝えしたいのは、CRM運用で起きがちな「データが複雑になってしまう問題」を解消(回避)しようとした実例です。特に、HubSpotでの商談管理と契約管理を分けることでカオスを回避し、Scalebaseとマネーフォワード クラウド請求書を組み合わせてシンプルな運用を実現できた経験を共有したいと考えました。
バックオフィスにおける仕事の時間が減れば、お客様に丁寧な対応を行う時間や余裕が手に入るので積極的にプロセスの合理化・効率化を進めています。今日はその一例のご紹介です。
1. はじめに
HubSpotは便利だけど、契約管理は難しかった
ビジネスが進むと、私たちは多くの商談をこなし、さまざまな商品を提案するようになります。その中でHubSpotは商談進行状況の把握にとても役立ちました。
しかし、受注後の契約管理や請求処理をHubSpot上で行おう時に我々にとっては無理が生じてしまいました。マネーフォワードグループに所属する私たちは自社サービス(マネーフォワードクラウド請求書)で請求を完結させたい思いが強く、HubSpotと連動がうまくいかずに手動作業が増える事態に直面しました。
さらに、セールスパイプラインが「受注」をゴールとする一方で、契約は受注後も長期的に続きます。同じ取引オブジェクトに長期契約の情報まで詰め込むと、ずっとクローズできない取引が残り、オブジェクトを表現する為にプロパティ（項目）もどんどん増える。複数のパイプラインやカスタムオブジェクトを使えば対処できるかもしれないけれど、それでは構造が複雑になりすぎる。と、感じたのが発端でした。
2. カオスを生む原因
契約管理を無理にHubSpot内に収めようとすると…
例えば、商品Aと商品Bを違うタイミングで契約すると、それぞれ独立した取引オブジェクトが生じます。ポストセールスでは一つのお客様単位で活動をしたかったりしますので、請求や契約条件を一本化したいと考えますが、２本の取引を同時に扱うか、または２つの取引を１つにマージする必要がでます。
また、更新日や単価、割引など、契約管理に必要な情報を詰め込むとプロパティが激増。組み合わせを持って表現する必要がでます。更新漏れや入力ミスも増え、操作する側の負担が大きくなってしまいます。
3. 解決策の模索
「商談」と「契約」を異なる軸で運用する
そこで私は、「商談管理はHubSpot、契約管理は別のシステム」という割り切りを採用しました。
商談の流れ：リード管理 → 商談創出 → 商談管理 → 受注（HubSpotで対応）
契約の流れ：契約登録 → 納品 → 検収・請求（Scalebase＋マネーフォワード クラウド請求書で対応）
このようにデータの流れを二本立てにすることで、HubSpotは受注までの営業活動に集中でき、契約の長期的な管理はScalebaseが担う形にすることができます。
"取引/商談"データ軸としたプロセス
リード・マーケ管理 -> 商談創出 -> 商談管理 -> 受注内諾/契約処理
取引・商談のデータをメインとする上記プロセスは引き続きHubSpotで対応することにしました。これらは一連として "営業活動" として一本芯が通っています。これらは "契約" を確定する為の取引や商談というデータを扱うプロセスとなります。取引/商談はファネルがあり、ルールがあり、ステップがあります。そして終了条件も持っています（一般的に数ヶ月で受注や失注など結論づく)
"契約"データ軸としたプロセス
契約登録 -> 納品 -> 検収/請求
"契約"データを軸としたプロセスは、Scalebaseとマネーフォワードクラウド請求書で対応することにしました。このプロセスは営業ではなく"契約"や"請求"という業務になります。このデータの切り口はカスタマーサクセスや、リニューアルセールスに対して "契約情報" を整理して提供する場所にもなりました。これによって次回更新時期なども簡単にわかるようになりました。
"契約"は何年も続くデータであり、途中で契約の変更なども行われるデータです。契約自体にファネルやステップはなく、ToDoがあるのみです。
4. Scalebaseを導入した理由
サブスクビジネスにフィットしたScalebase
上記のように、"取引" というデータを扱う商談プロセス。"契約"というデータを扱う請求・契約管理プロセスに分離したことで特性の違うデータをCRM上で無理に表現する必要がなくなると考えました。それによってどちらのプロセスもシンプルなデータの持ち方が出来ると想定していました。
私がScalebaseを選んだ理由は以下のとおりです。
サブスクリプションに特化した設計であり、マネーフォワード請求書との連携がスムーズ。
スモールスタートがしやすく、機能が過剰すぎない。
APIが充実しており、HubSpotとのデータ連携や自動化がやりやすい。
カスタマーサクセスやサポートが親切かつ迅速で、安心して導入できた。
これにより、契約管理や請求書発行、未入金チェック、更新時期のリマインドなどがスムーズになり、HubSpot上でのプロパティの肥大化を防ぐことができました。
Scalebaseの機能の紹介については、本家のWebサイトに譲りたいと思いますが「BtoBサブスクリプションビジネスのための販売管理システムです。」というほどの必要十分な機能が揃っていました！
実際に導入においては、私（元エンジニア）が牽引となりましたが、セールスチームに引き継いでも問題なく使えるであろう使いやすさ、わかりやすさを備えており、やはり再度言いたいのは非常に良いサポート・サクセスを受けられたことでした。困り事があったときに、より良いやり方・ワークアラウンドについて機能ベース、APIベースでも非常に親身に相談に乗ってくれました。
具体的な効果
そして、現在ですが当初の目論見通り HubSpotは "取引(商談)" の管理に閉じ込めることができ、複雑なプロパティを増やすことなく、セールスパイプラインの管理・可視化に特化することが出来ています。
セールスパイプラインも用途によって複数所有しますが、ポストセールスのプロセスに影響を与えない構成となっているので自由度高く設計が維持できています。
そして、請求・契約プロセスでは、Scalebaseに契約情報を一度登録したら、請求書の作成から、未入金の確認、そして更新時期が来た時にお知らせもほぼ手放しで行われるようになりました。
セールスチームの入力項目をそれほど増やすことなく、管理レベル（プロセスの途中での滞留や、完了漏れ、リマインドなど）を２−３段階高めることが出来ました。
5. 自動化でさらなる効率化
とはいえ、いくつか自分で運用コストを下げるための仕組みをAPIとZapierを使って構築しました！自慢させてください！（本題）
お客様の連絡先データの自動連携 ( ２重入力の回避 )
「同じお客様情報を二度入力したくない」という思いから、Zapierを使ってHubSpotとScalebaseを連携。商談が受注に至ったタイミングでScalebaseへ自動的に必要な情報が転送される仕組みを構築しました。これで、セールスメンバーが別ツールでイチからお客様情報を登録する手間は激減しました。
まず、自分でScalebaseのAPIをラップするZapierAppを非公式に(Private Appで)作成し様々な情報のやり取りをZapierで組み上げることが出来るようにしました。
HubSpotからScalebaseへの連携は、HubSpotの取引ステージへの到達をトリガーとして、契約・請求に必要な情報を自動でScalebaseに書き込んでいます。セールスメンバーは基本的にScalebaseに二重登録する必要はなくなりました。契約ステージに到達したら、Scalebaseに登録されているお客様名で契約の条件を登録するだけです。一度登録したら翌年の請求も自動生成です！もう、請求漏れも忘れません。
取引にコンタクト先を紐づけておけば、Scalebase上でもお客様の連絡先としての情報をScalebaseにも同期をかけています。このZap（かなり長くなった）の１つ目の自動化では、お客様情報などの連携を完成させました。
HubSpotのステージが受注済になると以下の通知が来るので、セールス担当者間での情報共有や、Scalebaseへの登録も忘れません💪💪
請求書送信・未入金のリマインド
Scalebaseでは請求前に下書きが確認できるため、「請求書の確定忘れ」や「送信し忘れ」を防ぐためのSlack通知をZapierで定期的に行うようにしました。期日を超えて入金がない場合も、Slackでお知らせできるので、抜け漏れがほぼありません。
契約を登録したけど請求は月末だから放置していた（忘れる）
請求書の下書きが出来たけど、確定忘れている。
確定して、マネーフォワードクラウド請求書にデータが届いたが、送信を忘れている。
送信しているが、期日を超えても振り込まれていない。
HubSpotのステージ管理ではScalebaseに契約を登録することで、パイプラインを終了することが出来るようにしています（未登録だと取引を完了状態にできないようにしています。) HubSpot側の作業をしていても、Scalebaseへの登録漏れを防ぐ仕組みがあります。
これで、ちゃんとセールスの売上や成績を計上するためには、契約をScalebaseに登録しなければいけないといったプロセスが敷かれ
そして一度Scalebaseに登録したら請求漏れや、更新の対応など漏れなくリマインドされるようになりました。
契約更新の到来のリマインド
契約更新が近づくと、月初めと中頃にScalebaseから該当お客様のリストをSlackに自動通知します。これで更新に向けた商談の準備がが行いやすくなり、お客様への連絡漏れなどの心配から解放されました。
😢 この項目は、残念なことに通知内容の一部がScalebaseのAPIをZapierの仕様や制限を満たして扱うことが難しい関係で、契約情報の取得が完璧ではない。(Slack上に通知する内容をもう少しわかりやすくしたい)という課題が残っています。ScalebaseのAPIの改善を楽しみにしています。
5. まとめ
私が試みたのは、HubSpotとScalebaseをうまく組み合わせて、商談と契約を分離し、CRMが陥りがちな「プロパティ乱立によるカオス」を回避するアプローチです。結果として、HubSpot上ではシンプルな商談管理に徹し、長期的な契約や請求作業はScalebase側で管理することで、セールスメンバーの余計な負担が減り、全体としてスムーズな業務フローが実現できました。
「うちもCRMが複雑になって困っている」という方にとって、この事例が少しでも参考になれば幸いです。