Lavender は AI セールスメールコーチです。リアルタイムのスコアリング、パーソナライズの提案、そして Gmail や Outlook といったツールの受信トレイからそのまま使えるコーチングによって、レベニューチームがより多くの返信を得られるアウトバウンドメールを書けるよう支援します。
セルフサーブの PLG プロダクトと、エンタープライズ向けのセールス主導モーション。この 2 つのまったく異なる市場開拓モーションを同時にスケールさせ始めたとき、Lavender は成長中の SaaS 企業に驚くほどよくある問題に直面しました。基本的な問いにさえ、自信を持って答えられなくなったのです。
自社の ARR はいくらなのか。
収益は Stripe を通じて流れていましたが、その土台にある指標をプロダクト・料金モデル・顧客タイプをまたいで突き合わせることは、ますます難しくなっていました。
Lavender の COO、Elliott Fisher はこう振り返ります。
“When I joined the company in 2024… there was never full confidence in what our ARR number was.”
なぜ、こうなってしまったのでしょうか。
作り込みすぎた RevOps
Lavender の場合、ARR の混乱は 1 つのシステムの破綻が原因ではありませんでした。その場しのぎの意思決定、担当者の入れ替わり、そして善意から生まれた回避策が何年も積み重なった結果だったのです。
2 つの異なる市場開拓モーションをスケールさせるということは、絶え間ない実験を意味します。メッセージング、グロース施策、価格戦略を次々と試していくのです。
“We had consultants and we paid them a fortune. We hired a RevOps director… we had another SaaS tool for analysis and forecasting… All of this contributed to us over-architecting how we did RevOps.”
異なる顧客タイプに、異なるワークフローで、裏側では異なる請求経路を通じて販売するようになると、収益は単純な数字ではなくなります。それは、終わりのない調整の問題へと姿を変えるのです。
Lavender が「すべて壊す」しかなくなった瞬間
ある日、CEO がシンプルな質問を投げかけました。“What’s our current ARR number?”
誰も自信を持って答えられませんでした。
“None of the leadership could give him an answer… and at that point it was like, alright, we have to essentially blow this up and rebuild it from scratch.”
Elliott にとって、それは決定的な瞬間でした。すでに複雑になりきったシステムの上に、さらに修正を重ねるのをやめる必要がありました。矛盾を継ぎ足しでふさぎ続けるのではなく、Lavender はゼロからやり直すことを決断したのです。
立ち戻ったのは、いまも完全に信頼できる唯一のデータソースでした。Stripe です。
チームは 4 年分の請求書履歴をエクスポートし、Excel 上で ARR ウォーターフォールモデルを 1 行ずつ手作業で組み直しました。骨の折れる作業でしたが、それまで手にできなかったものが得られました。クリーンなベースラインです。
さらに重要だったのは、収益の定義、インプット、責任範囲について社内の一貫性を確立せざるを得なくなったことです。これが、この先より強固な標準業務手順（SOP）を築く土台となりました。
救命ボートであり、信頼できる唯一の情報源でもある ChartMogul
サブスクリプションデータのクリーンなベースラインを作り直した Lavender にとって、次の課題は、二度と同じ手作業を繰り返さない仕組みをつくることでした。
Pilot の担当 CFO からは、ARR をきちんと自動化すべきだと助言を受けます。そこで Lavender が選んだのが ChartMogul でした。
オンボーディングは 1 週間もかかりませんでした。
“ChartMogul was so straightforward and intuitive… It was very relieving. Here we finally can have this number calculated for us in real time.”
それまで試してきたツールと違い、ChartMogul は新たな複雑さを持ち込みませんでした。信頼できる ARR 数値をすぐに提供しつつ、必要になれば時間をかけてより深い分析へ広げていける余地も残されていたのです。
“ChartMogul could be as simple as telling us ARR, and as dynamic as analyzing revenue by product or customer type as we grew”
自動化だけでは片づかないものを整える
Lavender の環境がとりわけ複雑だったのは、サブスクリプションデータが 1 か所にまとまっていなかったからです。セルフサーブ向けに複数の Stripe アカウントを運用し、さらにエンタープライズ商談には SalesBricks を使っていました。同じ 1 社の顧客が 3 つのシステムすべてに現れることも珍しくありません。あるエンタープライズ顧客が、SalesBricks では契約として存在し、ある Stripe アカウントでは一度払いの決済があり、別のアカウントでは継続サブスクリプションが作られている、といった具合です。
ChartMogul の導入前は、こうした散らばりを突き合わせる手段はスプレッドシートか回避策か、あるいは数字が完全には一致しないと割り切ることしかありませんでした。ChartMogul なら、請求書データを直接編集し、複数のレコードを 1 人の顧客にマージし、存在しないサブスクリプションを手動で作成し、必要に応じて一度払いの決済をサブスクリプション収益へ変換できます。
この柔軟性が決定的でした。硬直したデータモデルに合わせてプロセスを作り直すことを強いるのではなく、ChartMogul は事業の中で収益が実際にどう流れているかをそのまま映し出し、そのうえで先に向けて標準化していくことを可能にしたのです。
ChartMogul で事業を動かす
現在、Elliott は ChartMogul を Lavender の指標の土台と位置づけています。
“ChartMogul is our source of truth… because it aggregates the information across products.”
Elliott は経営レポートから更新状況の把握まで、毎日 ChartMogul を使っています。週次の経営会議はチャーン、リテンション、更新、ARR を軸に進みます。新規サブスクリプションはリアルタイムで確認され、近づいている更新は営業チームへ先回りして共有されます。
プロダクトラインを広げていくなかで、ChartMogul は成長がどこから来ていて、誰がそれを牽引しているのかを理解する助けにもなりました。データエンリッチメントとセグメンテーションによって、Lavender は次の軸でコホートを分析できるようになりました。
- 業種
- 企業規模
- 地域
- 顧客セグメント
“Jordan said, ‘we can actually do data enrichment for you.’ Another life-saving miracle for us.”
その結果、コホート分析はより明確になり、市場開拓の判断はより鋭くなり、事業全体のレポーティングに自信が生まれました。
Elliott からのアドバイス：まず単純化、自動化はその次
Elliott が身をもって学んだ教訓は、シンプルなものです。クリーンな指標は複雑なツールからは生まれません。一貫したワークフロー、明確な責任者、そして運用上の厳密さから生まれるのです。
“You need to simplify the workflow. Create a process where the data can be consistent. Assign an owner… then look for tools like ChartMogul to automate the work.”
最終的なゴールは、ソフトウェアを増やすことではありませんでした。明確さと一貫性、そして事業が信頼できる仕組みをつくることだったのです。