受注後で失速しない設計図 ― SaaS RevOps のレベニューアーキテクチャ

皆さんこんにちは、タカシです。今日は SaaS RevOps の入り口として、レベニューアーキテクチャを扱います。Winning by Design は、SaaS の1件の契約で得る総収益のうち 82パーセントが将来収益にあるモデルもあると示しています。つまり、受注だけ見ている会社ほど、実は大事な部分を見落としやすいんです。

その通りです。レベニューアーキテクチャは、マーケ、営業、導入、CS、更新、拡張までを一つの収益システムとして設計する考え方です。組織図を並べる話ではなく、顧客ライフサイクル全体を同じ定義、同じデータ、同じ会議体で動かせるようにする設計なんですね。

従来のファネルは、受注までを管理するには便利です。ただ SaaS は、契約後にオンボーディングがあり、価値実現があり、更新と拡張があり、そこで利益が積み上がる。Winning by Design はこの構造を Bowtie で表し、 acquisition と retention と expansion を一つの流れとして見るべきだと整理しています。

SaaStr で Calendly の CRO Kate Ahlering も、RevOps は顧客ライフサイクル全体の体験を定義し、追跡し、管理する仕事だと話しています。経営陣で buyer journey と中心 KPI を先に揃えることが出発点で、alignment に注力した組織は 19パーセント速い成長と 15パーセント高い収益性を示すと紹介していました。

Snowflake の事例は示唆的です。SaaStr によれば、同社は営業やマーケに散らばっていた data analyst と BI を中央集約し、RevOps は何を見たいかを定義し、intelligence team がどう作るかを担う形へ整理しました。結果として support で週 418時間削減、特定マーケ施策では 90パーセントの時間短縮が出ています。

Fortinet も分かりやすいです。Clari のケースでは、データとプラットフォームを標準化し、KPI を揃えて forecast を一つの仕組みで回した結果、forecast accuracy が 92、96、97パーセントへ改善しました。予測精度が上がると、採用、投資、地域配分まで早く決められるようになります。

Skai の事例では、毎週水曜朝 7 時に C-suite と revenue leaders が同じ forecast dashboard を開き、数字合わせではなく gap と blocker の除去に時間を使っています。product gap なのか、legal bottleneck なのかをすぐ切り分けられるのは、single source of truth があるからです。

HubSpot Academy も lifecycle stages を CRM strategy の backbone と説明しています。つまり、MQL を何と呼ぶか、いつ sales へ渡すか、いつ customer と見なすかが曖昧だと、どれほど高機能な CRM でも経営基盤にはならない。Revenue Architecture の最初の仕事は、ステージ定義を経営で決め切ることです。

よくある失敗は五つです。RevOps を営業支援に閉じ込める、ツール導入を先にやる、受注前だけを最適化する、会議体が報告会のまま、そして定着運用を軽く見る。このどれかがあると、立派なダッシュボードは増えても、収益システムは整いません。

明日からやるなら、まず顧客ライフサイクルを獲得、導入、活用、更新、拡張まで書き出し、owner と exit 条件を定義すること。次に MQL、SQL、pipeline、renewal at risk など主要定義を 1 枚にまとめること。最後に、週次の revenue meeting を gap と blocker 解消の場へ変えることです。