新任RevOpsマネージャーの最初の30/60/90日

あなたは月曜に着任する。火曜の午後までに、CROは（廊下で、何気なく、何か月も考えてきたことを人が頼むときのやり方で）いつ予測精度の数字をコミットできるかとあなたに尋ねている。彼は30日目を期待している。

あなたはSalesforceを開き、14個の商談ステージを見つける。そのうち3つは「Negotiation」の何らかの変種の名前だ。さらに2つは18か月間使われていないが、「マーケティングの古いレポートがそれに依存している」ので誰もオフにしない。Opportunityオブジェクトには47個のカスタムフィールドがある。およそ3分の1は5%未満の頻度でしか入力されていない。クローズ日が過去になっている11,000件のオープン商談がある。そのうち6件は2022年のものだ。

RevOpsへようこそ。

ほとんどのオンボーディング計画が飛ばす真実がこれだ。最初の90日は、これらのどれかを直すためのものではない。それを直す権利を勝ち取るためのものだ。第1週に「手早い勝ち」をリリースすれば、その後2年間、なぜ予測の数字がずれているのかを説明し続けることになる。まず監査し、次に提案し、小さな勝ちを1つ届け、下半期のマンデートを勝ち取る。それがこの戦法だ。

なぜRevOpsではほとんどの30/60/90プランが失敗するのか

汎用のオンボーディングテンプレートは、あなたがきれいなシステムに入っていくと想定している。新任のマーケティング採用者にはキャンペーンブリーフが手渡される。新任のAEにはテリトリーとquotaが渡される。新任のRevOps採用者には、6人の前任オーナー分の技術的負債と、「ついに予測を直せる誰か」を8か月待ってきたCROが手渡される。

最初の3週間で何か目に見えるものをリリースしなければというプレッシャーは、途方もない。そしてそれが罠だ。システムを理解する前にあなたが加えるすべての変更は、将来のバグだ。あなたが端から端まで追跡していない自動化への「手早い修正」は、自分自身の四半期末レポートに仕掛けた小さな爆弾だ。

1〜30日目の仕事は、ものを直すことではない。60〜90日目にリリースする修正が実際に持ちこたえるよう、いま手元にあるものを地図化することだ。

1〜30日目 ── 監査せよ、行動するな

監査のフェーズには5つのワークストリームがある。順番にではなく、並行して回そう。

Salesforceステージの監査

ステージのピックリストを開く。すべての値を書き出す。それぞれの隣に、3つの列を埋める。公式の定義、担当者が考えている入力基準、担当者が考えている終了基準。それから2人のAEと座り、各ステージが何を意味するか尋ねる。担当者と公式の定義が食い違うステージが少なくとも4つ見つかる。同じチーム内の担当者によって異なる意味を持つステージが2つ見つかる。すべてを記録する。何も直さない。

そこにいるついでに、手早いレポートを引っ張る。過去90日で各ステージを通過した商談がいくつあったか。トラフィックがほぼゼロのステージは、誰も使っていないステージだ。不釣り合いにトラフィックの多いものは、2つか3つのステージを合わせた働きをしている。ピックリストが何と主張していようと、それがあなたの本当のパイプライン構造だ。

カスタムフィールドの棚卸し

Opportunity、Account、Contact、Leadのすべてのカスタムフィールドのリストを引っ張る。それぞれについて、過去12か月の入力率を計算する。20%未満のものはすべて死んだフィールドだ。80%超のものはすべて荷重を支えている。中間の帯（20〜80%）が、政治の宿るところだ。一部はあなたがまだ理解していない自動化によって入力されている。一部は、あなたが削除したら辞めてしまうたった1人の担当者によって入力されている。

まだ削除を提案するな。棚卸しを作るだけだ。75日目にそれが必要になる。

自動化の地図

すべての有効な自動化をリスト化する。ワークフロールール、Process Builderのフロー、最新のフロー、Apexトリガー、検証ルール、スケジュールされたジョブ。それぞれについて、最終更新日、最終更新ユーザー、そして本来何をするはずかを記す。2023年に退社した管理者が最後に更新した自動化が少なくとも1つ見つかる。入力基準が名称変更されたフィールドを参照しているため、もはや発火しないワークフロールールが少なくとも1つ見つかる。

担当者が積極的に不満を言うものに印をつける。それらがあなたの31日目のターゲットだ。

連携のカタログ

Salesforceに何が接続されているか。マーケティング側のHubSpotまたはMarketo。シーケンス用のOutreachまたはSalesloft。通話用のGong。予測（forecast）用のClariまたはBoostUp。エンリッチメント用のZoomInfoまたはApollo。課金システム。それぞれについて、データがどの方向に流れるか、どのフィールドが同期するか、どのくらいの頻度かを文書化する。それから、それを設定した管理者（その人物がまだ在籍していれば）に、本来何が起きるはずだったのと実際に何が起きているのかを尋ねる。その2つのギャップが、あなたの重複アカウントが宿るところだ。

5回の予測会議に同席する

これが最初の30日であなたがする最も重要なことだ。話すな。メモを取れ。ステージの定義についてマネージャーと担当者が食い違うところを見よ。どの案件が土壇場で予測（forecast）から引き抜かれ、どの案件がサンドバッグで押し込まれるかを見よ。CROが「これは本当にcommitか？」と尋ねたときのボディランゲージを見よ。予測（forecast）会議は、あなたが引き継いだひとつひとつのSalesforceの判断が、リアルタイムでストレステストにかけられる場だ。

5回の会議が終わるころには、あなたはセールスのリーダー陣全体が思っている以上に、自社のパイプラインについて知っているだろう。それはあなたが賢いからではない。彼らが機能不全に気づかなくなったからだ。あなたは気づいていない、いや、まだ慣れていないのだ。

30日目の成果物

修正リストではない。現状を記した、6〜10ページの文書で、最後にCROへの3つの質問をつける。良い質問の例。「Negotiationの何らかの変種の名前を持つステージが3つあります。契約を結ぶステージはどれですか？」「Opportunity Stage Reasonフィールドは4%の頻度で入力されていますが、パイプラインレビューはそれを参照し続けています。必須にすべきですか、それとも廃止すべきですか？」「予測（forecast）会議は火曜の午前9時に行われます。3人のマネージャーのうち2人が出席しません。これはツールの問題ですか、プロセスの問題ですか？」

修正リストを持ち込むな。CROはそれを求めてくる。一線を守れ。監査が成果物だ。

31〜60日目 ── 小さな勝ち1つ、提案1つ

地図は手に入れた。さあ、1つをリリースし、1組のルールを提案し、手法のチェックを回す。それだけだ。30日で3つ。15ではない。

壊れた自動化を1つ停止する

担当者が最も不満を言うたった1つの自動化を選ぶ。たいていはステージを戻すルーティングルールで、フィールドが変わると商談を後ろに押し戻し、予測（forecast）のスナップショットを壊すものだ。触れる前に端から端まで追跡する。それを停止しても下流のレポートが壊れないことを確認する。セールスリーダーの承認を書面で得る。無効化する。何がなぜ変わったかを説明する1段落のメモをチームに送る。2週間、影響がないか見守る。

自動化を1つ。3つではない。要点は修正ではない。要点は、何も壊さずに統制された変更をリリースできると証明することだ。

ステージの定義を1つ修正する

1日目の監査で最も食い違いの多かったステージを選ぶ。セールスリーダーと座り、入力基準、終了基準、そして一文の定義を書き直す。20分の金曜トレーニングを回す。担当者が実際に作業する場所に表示されるよう、Salesforceにフィールドレベルのヘルプテキストとして定義を追加する。予測（forecast）の手法ドキュメントでそのステージを更新する。

14個すべてのステージを直したい誘惑に抵抗する。ステージ改革のチャンスは一度きりだ。90日目以降のために取っておく。

パイプラインの健全性管理ルールを提案する

1ページの提案を書く。30日間アクティビティのない商談は自動でレビュー対象に印がつく。クローズ日が過去になっている商談は次の予測（forecast）会議の前に必須更新となる。直近のステージ変更なしに180日を超えた商談は自動で「停滞」ステータスに移される。まだ実装するな。CROと2人のセールスマネージャーに通して説明する。修正を加えて「はい」までもっていく。賛同が、ルールそのものより重要だ。

手法の現実チェックを回す

先四半期からclosed-wonの商談を10件、closed-lostの商談を10件引っ張る。それぞれのステージの進行を再構成する。案件は本当に、データが示す期間ずっと「Proposal」にとどまっていたか。それとも担当者が予測（forecast）会議のつじつまを合わせるため、同じ日に3つのステージを一気に更新したのか。この演習からは、どのdashboardよりも自社の予測精度について多くを学べる。パターンを文書化する。それがあなたの90日目の弾薬だ。

61〜90日目 ── 指標を所有し、計画を提示する

いまこそ数字にコミットする。その前ではない。

予測精度のオーナーシップを取る

CROにこう伝える。「来四半期から、四半期末にコールした数字の±10%にコミットします」。今四半期ではない。あなたはまだ手法を所有していない。90日目までに展開し終える手法に基づいて、来四半期だ。それが、達成できる数字と、コミットを後悔する数字との違いだ。

dashboardを作る。3つのビュー。今週コールした数字対先週コールした数字、四半期末にコールした数字対実際に着地した数字、そして担当者レベルのコール品質スコア。CROが取締役会の準備中に30秒で読めるくらいシンプルにする。

90日レポートを作る

5つのセクション。見つけたこと（監査）、リリースしたこと（1つの自動化、1つのステージ定義、提案の形にした健全性管理ルール）、まだ壊れていること（直さなかった棚卸し）、そのコスト（直していない問題の推定売上影響、保守的な数字）、そして必要なもの（下半期計画とその要望）。

長さ。最大10枚のスライド、加えて完全な監査文書の付録。提示する前に声に出して読む。歩いて説明するのに90秒を超えるスライドがあれば、切る。

下半期のシステム計画を提案する

これがその瞬間だ。1〜60日目に物事を吹き飛ばさなかったことで、あなたはそれを勝ち取った。ステージの統合を提案する。14個のステージを6個へ。50日目に起草したデータ健全性管理のSLAを提案する。連携のクリーンアップを提案する。どのツールを更新し、どれを切るか。カスタムフィールドの棚卸しからフィールド廃止リストを提案する。

順番をつける。Q3にすべてをやろうとするな。現実的な下半期計画はこうだ。7月にステージ改革、8月に健全性管理SLAの展開、9月に連携のクリーンアップ、10月にフィールド廃止。月に1つの大きな変更。それより速いものはすべて、一四半期のうちに現場によって覆される。

運用サイクルを固定する

セールスリーダーとの週次の予測（forecast）の運用サイクル。マーケティングと財務との月次のパイプライン評議会。CROとの四半期ごとの技術スタックレビュー。90日の節目を離れる前に、それらをカレンダーに入れる。運用サイクルが、他のすべてを定着させる。

停滞商談の現実チェック

あなたは、closed-lostにすべき5,000〜15,000件のオープン商談を引き継ぐことになる。一部は2022年のものだ。一部は2年前に退社した担当者が所有している。それらを着任2週目で一括クローズしたい誘惑は、抗いがたい。それは想像しうる最も目に見えるクリーンアップだ。あとでdashboardは美しく見えるだろう。

やるな。

「新しいRevOpsの人が2週目でパイプラインを吹き飛ばした」という見え方は、何年もあなたについて回る。それらの停滞商談の一部は本物だ。5年在籍しているAEはそのうち40件を持ち、どれが実際に生きているかを知っている。マーケティングのパイプライン源泉のレポートは、その過去データに依存している。財務のブッキングモデルは、それらのレコードの一部を比較コホートとして使っている。

75日目まで待つ。CROの承認を得てクリーンアップを提案する。文書化されたプロジェクトとして回す。対象に含める基準、2週間前に通知されるオーナー、例外のための30日間の猶予、ロールバック用のクリーンアップ前状態のスナップショット。実行する前に3回伝える。それからきれいに回す。

クリーンアップそのものには20分かかる。待つことで守る信頼は、築くのに何年もかかる。

よくある落とし穴

「価値を示す」ために第1週に変更をリリースする。 システムを理解する前にあなたが加えるすべての変更は、将来のバグだ。最初の30日でのあなたの価値は、修正ではなく監査だ。

30日の予測精度のコミットメントにイエスと言う。 押し返す。60日目までに手法を、その次の四半期に精度の数字をコミットする。それ以外はすべて、外して代償を払う数字だ。

Salesforce、HubSpot、Outreachを同時に直そうとする。 順番をつける。Salesforceが先だ。システム・オブ・レコードだから。マーケティングオートメーションが2番目。シーケンサーが3番目。それ以外はすべて、本筋から逸れた寄り道だ。

5年在籍しているAEと関係を築かない。 彼らはどのフィールドが荷重を支えているか知っている。どの自動化が、2021年にあるVPが要求して忘れたために存在しているかを知っている。どのステージがどのマネージャーにとって何を意味するかを知っている。第1週に彼らにコーヒーをおごれ。第4週にもう一度おごれ。

CROの切迫感を自分の職務記述書と取り違える。 CROは予測精度を求めている。あなたの仕事は、それを生み出すシステムを作ることだ。15日目には、その2つは同じものではない。90日目に同じものになる。

30日監査チェックリスト

これを1日目から30日目までの作業ドキュメントとして使う。

公式の定義、担当者が認識する入力基準、担当者が認識する終了基準、90日間のステージのトラフィックを記したステージ一覧
Opportunity、Account、Contact、Leadについて、過去12か月の入力率を記したカスタムフィールドの棚卸し
最終更新日、最終更新ユーザー、現在の挙動、担当者の不満を記した自動化の一覧
同期方向、フィールド、頻度、既知の問題を記した連携カタログ
予測（forecast）会議の観察ログ：ステージ、担当者がコールした金額、マネージャーがコールした金額、実際のクローズ、ギャップの理由
データフローの地図：lead source → MQL → SQL → 商談 → Closed-Won → 更新、各ステップでのシステム・オブ・レコードつき
1か月目の終わりにCROへの3つの質問

おわりに

最初の90日は、RevOpsを直すためのものではない。RevOpsを直す権利を勝ち取るためのものだ。

行動の前に監査せよ。31〜60日目に統制された勝ちを1つリリースし、できることを証明せよ。61〜90日目を使って予測精度の指標を所有し、下半期のマンデートを勝ち取れ。14ステージから6ステージへの移行、フィールドの廃止、停滞商談のクリーンアップ。それらは下半期の勝ちであって、Q1の勝ちではない。

燃え尽きるRevOps採用者は、30日目に予測精度の数字を、45日目にステージ改革をリリースしようとした者たちだ。7年続く者たちは、「30日目までに監査を、60日目までに手法を、90日目までに下半期計画を出します」と言い、CROがもっとを求めてきたときに一線を守った者たちだ。

一線を守れ。それから届けよ。

RevOps プレイブック