VC のプラットフォームリードから最近こう尋ねられました：「11 のポートフォリオ企業が HubSpot を使っていて、6 社が乱雑です。どこから始めますか？」本能は会社ごとにトリアージすることです。最も乱雑なのを選び、四半期埋め込み、次へ移動。そのモデルは複利しません。3 社目を終える頃には、4 社目と 5 社目はさらにドリフトしています。ポートフォリオ RevOps サポートは、作業の単位が会社ではなく監査のときにのみスケールします。11 社すべてで同じ 90 分パスを回し、4 つのバケットに分け、ロゴではなくバケットに介入します。
なぜ今これが重要なのか
ファウンダーの RevOps への過小投資は構造的です。Poyar は、Product-Led モーションと従来型セールスを組み合わせること、初期 B2B SaaS ポートコの標準形、が、組織構造、採用、報酬、アカウント割り当てに関する運用上の複雑さを生み、ファウンダーは Forecast が外れ始めるまでそれを系統的に過小評価する、と論じてきました。その時点で、プラットフォームチームは 1 年分の蓄積負債の下流で介入を求められます。それを 11 社にまたがって掛け算すると、プラットフォームチームは 11 件の同時クリーンアップを見つめており、すべてが緊急で、互いに積み上がっていません。サポートモデルは反転しなければなりません。監査を前もって定義し、インテーク時にすべてのポートフォリオ企業で回し、プラットフォーム RevOps の価値の 60% は実装ではなく診断であることを受け入れます。
プラットフォームチームの罠
ほとんどの VC プラットフォームチームは、以前ポートフォリオ企業内で RevOps を回した 1〜2 人のシニアジェネラリストで構成されています。本能はかつて手伝った方法で手伝うことです、埋め込み、ハンズオン、1 社ずつ袖をまくる。そのモデルは彼らがオペレーターだったときには機能しました。彼らがファンドのとき機能しません。
問題は、ポートフォリオ全体に対するビスポーク支援は時間にキャップがなく、アウトプットが再現不可能なことです。すべてのエンゲージメントはゼロから始まります。すべての推奨は単発です。プラットフォームチームは遅い社内コンサルティングになり、実際に支援を受けるポートコは LP ミーティングで最も声が大きい、介入から最も高いレバレッジがあるポートコと同じセットになることはほとんどありません。
90 分ポートフォリオ監査
スケールするのはその逆です。単一の監査テンプレート、固定スコープ、固定時間、固定アウトプットを定義します。すべてのポートフォリオ企業で同じ深さで回します。会社ではなく監査を作業の単位として使います。
Checkpoint で回すバージョンは 90 分で 4 つの領域をカバーします。
- Pipeline 定義。Deal ステージは何か？それぞれに 1 文の定義、Entry 条件、Exit 条件があるか？2 人の Rep が「qualified」を同じ方法で説明できるか？ほとんどのポートフォリオ企業は最初の 15 分でこれに失敗します。
- Lead Source アトリビューション。Contact はどこから来て、Source は実際に作成時に入力されているか？単一のソース・オブ・トゥルースフィールドがあるか、競合する 3 つがあるか？プラットフォームチームは、手動エクスポートなしに Campaign 支出数とソース化された Pipeline 数を照合できるか？
- Marketing Contact 会計。HubSpot Contact ティアはどう管理されているか？Lifecycle 変更で Marketing Contact を自動マークするワークフローがあり、それは実際の有償ティアと一致するか？ここでシートコストが漏れます。
- 更新と販売後衛生。新規ビジネスとは別の更新 Pipeline があるか？サブスクリプションオブジェクトが使われているか、誰も更新しないカスタムプロパティで更新が追跡されているか？カスタマーサクセスはシステムに対して動いているか、スプレッドシートに対して動いているか？
90 分は深掘りではありません。1 ページの診断とトリアージ判断を生み出します。
4 つの問題カテゴリ
すべてのポートフォリオ企業監査は 4 つのバケットのいずれかに着地します。介入はゼロから設計するのではなく、バケットにマッチさせます。
カテゴリ 1：グリーンフィールドインストール
シードまたはプレシリーズ A、ファウンダー主導 GTM、HubSpot は週末に創業 AE がセットアップ。システムがないので負債もありません。介入はテンプレ化インストール：標準 Pipeline、標準 Lifecycle ステージ、標準 Lead Source スキーマ、標準更新 Pipeline。プラットフォームチームがサンドボックスにデプロイし、会社の実際の Deal データに対して検証し、2 週間で出荷するポータブル HubSpot テンプレートを持っています。ビスポーク設計作業はありません。
カテゴリ 2：ブラウンフィールドトリアージ
シリーズ A または B、HubSpot は 2 年以上稼働、カスタムプロパティ数は数百、過去 3 人の RevOps 採用者がそれぞれ指紋を残しました。介入は keep / edit / delete パス、別の投稿でカバー、であり、アウトプットは次の採用者が実際に運用できるクリーンアップされたスキーマです。これがプラットフォームチームが継承するものの大半です。
カテゴリ 3：再プラットフォーム候補
Pipedrive、Attio、またはチームが卒業したが単独では移行できない Salesforce インスタンスに乗っている。介入は移行スコーピングドキュメントとベンダー判断であり、実装ではありません。プラットフォームチームの価値は、バイアスのないプラットフォーム選択会話です、彼らはポートフォリオ全体で 5 回それを行っており、ファウンダーは 1 回行っているのです。
カテゴリ 4：オペレーティングモデルのギャップ
CRM は問題ありません。問題は上流：定義された ICP がない、Buying Persona が曖昧、テリトリーが未定義、報酬プランが間違った行動を罰しています。HubSpot 介入はこれを直しません。プラットフォームチームの仕事はこれをボードにフラグし、ファウンダーをフラクショナル GTM リードと繋ぐことであり、6 か月で書き直されるワークフローを 3 か月チューニングすることではありません。
データを漏らさずポートコ間でパターンを共有する
複利は、プラットフォームチームがポートフォリオ企業間で学びを動かせる場合にのみ機能します。最も速いパスは、プライベートで匿名化されたパターンライブラリです：監査した 11 社のうち 8 社が同じ Lead Source アトリビューションギャップを持っていた、それを直すために出荷したワークフローはこれです。ライブラリが資産です。ポートコは消費者であり、名前付きの貢献者ではありません。ポートコ間でポートコデータは動きません。動くのはレシピ、テンプレ化されたワークフローエクスポート、プロパティスキーマ、Pipeline 定義、であり、クリーンな形で再構築され、ソース企業の識別子から自由です。
現場で見たパターン
DACH 拠点の初期段階ファンドのプラットフォームリードが、HubSpot を使う 11 のポートフォリオ企業を抱え、LP に測定可能な進捗を示すべき四半期があってご相談に来ました。本能は最も乱雑な 2 社に埋め込むことでした。実際のプロジェクトは違いました。3 週間で 11 社すべてに 90 分監査を回しました。トリアージ結果：4 社グリーンフィールドインストール、5 社ブラウンフィールドトリアージ、1 社再プラットフォーム候補、1 社は CRM プロジェクトではなくフラクショナル GTM 採用が必要なオペレーティングモデルギャップ。グリーンフィールドの 4 社は単一テンプレートに対して 8 週間で出荷。ブラウンフィールドの 5 社はそれぞれ 30〜50% のカスタムプロパティ削減でスコープされた keep / edit / delete プロジェクトを得ました。4 か月目までに、プラットフォームチームは 11 ポートコのうち 9 社で測定可能な改善を、以前ビスポーク作業を 1.5 社に入れていたのとほぼ同じヘッドカウントで持ちました。
解決策：ポートフォリオ RevOps プレイブック
ゼロからポートフォリオ RevOps サポートをセットアップするプラットフォームチームへ。
- 支援を提供する前に監査を定義してください。領域ごとに 4〜6 の質問と 1 ページのアウトプットテンプレートを持つ 90 分監査スクリプトを書きます。監査がプロダクトです。
- インテーク時にすべてのポートフォリオ企業で監査を回してください。何かが燃え上がったときの反応的なコールではなく、投資後 30 日プランの一部にします。ケイデンスがデータセットを作ります。
- 4 つのカテゴリにトリアージしてください。グリーンフィールドインストール、ブラウンフィールドトリアージ、再プラットフォーム候補、オペレーティングモデルギャップ。選択を強制し、会社ごとに 5 つ目のバケットを発明しないでください。
- カテゴリ 1 と 2 のためにテンプレ化された介入を構築してください。ポータブル HubSpot インストールテンプレート、keep / edit / delete スプレッドシート、更新 Pipeline スキーマ。これらは再利用可能な資産であり、ビスポークデリバラブルではありません。
- その他すべてに「オフィスアワー」を回してください。プラットフォームチームが任意のポートコ RevOps 質問のために保持する週 2 時間のオープンスロット。ほとんどの問題は埋め込みエンゲージメントを必要とせず、20 分のシニア判断を必要とします。
- プライベートで匿名化されたパターンライブラリを維持してください。ソース企業識別子から取り除かれ、問題カテゴリでインデックスされたワークフロー、スキーマ、プロセス文書。ライブラリは監査データセットを複利します。
- 埋め込み作業をアウトソースしてください。カテゴリ 3 と 4、およびカテゴリ 2 の深いブラウンフィールドプロジェクトは外部エンゲージメントです。プラットフォームチームは希少でシニアなまま留まり、実装の深さは検証されたパートナーから来ます。
ステップ 7 がほとんどのプラットフォームチームが抵抗する場所です。それはまた、モデルが耐久性を持つ場所でもあります。1 つのポートコ内で実装をするプラットフォームリードは、次の 8 社で監査を回せません。
Checkpoint がどう関わるか
DACH と EMEA のベンチャーファンドとファミリーオフィスのために、ポートフォリオ監査と、そこから出てくるテンプレ化された介入を、常設サービスとして回しています。エコノミクスが機能するのは、監査が固定で、4 つの介入がテンプレ化され、プラットフォームチームがシニア判断を社内に留め、私たちが複数のポートコにまたがって実装の深さを運ぶからです。5 社以上のポートフォリオ企業で RevOps サポートをスケールしようとするプラットフォームリードなら、VC ポートフォリオサポートがチームを 1 社ずつ消耗させるのではなく複利できるかについて、ご相談ください。
出典
- Poyar, Kyle. 「PLG and Sales in 2023: How to Combine Them for Efficient Revenue Growth.」 OpenView、2023 年 6 月 13 日。openviewpartners.com
- Lemkin, Jason. The RevOps playbook: how Owner.com's CRO scaled from 0 to $1B ARR. SaaStr。saastr.com