よくあるRevOpsの落とし穴：6〜18か月でぶつかる7つの壁（と、その乗り越え方）
Turn this article into takeaways for your work.
Each assistant summarizes the article only for you and suggests best practices for your work.
あなたは新入社員のハネムーン期を過ぎている。CROはあなたの名前を知っている。あなたのキューは満杯だ。でも、何かがしっくりこない。セールスが、あなたにはうまく名づけられない何かに苛立っている。あなたのdashboardは開かれていない。VPが3回連続のQBRで同じ予測（forecast）の質問を繰り返し、あなたは彼らがいまひとつ信頼しない答えを返し続けている。
壁へようこそ。どのRevOpsの人も、6か月目から18か月目のどこかでそれにぶつかる。あなたを採用させた仕事（明らかな散らかりを片づける、最初の手早い勝ちをリリースする）は、あなたをシニアまで運んではくれない。次のギアは違っており、誰もプレイブックを手渡してくれない。
そこで、これがそれだ。7つの壁を、たいてい現れる順に、症状、それが起きていると証明する実際の数字、そして今週何をするかとともに。
落とし穴1：誰も読まないSalesforceレポートを作る
症状。 あなたはdashboardをリリースする。VPがSlackで親指を立てる絵文字をくれる。48時間ほど気分がいい。それからビューカウントを確認すると、3で横ばいになっている。あなた、あなたのマネージャー、そして自動更新ジョブだ。
実際の数字。 Lightning Usageレポート（あるいはあなたのCRMの相当するもの）を実行し、過去90日に作ったすべてのdashboardのビューカウントを引っ張る。正直な基準。第2週以降、月間のユニーク閲覧者が5人未満なら、それは死んでいる。オペレーションが作ったdashboardのほとんどがそこに落ち着く。私は80以上のdashboardを持つ組織を監査し、上位5つが全ビューの92%を占めていたことがある。
実際に何と言うべきか。 次に誰かが「Xのdashboardを作ってくれる？」と言ったら、こう尋ねる。「それを開く会議を順に説明してください。部屋には他に誰がいますか？ それが示す内容に基づいて、どんな判断が変わりますか？」30秒で答えられないなら、そのdashboardはまだ存在しない。判断がまだ存在しないからだ。
修正。 誰かが2回頼むまで作るのをやめる。最初の依頼は雰囲気だ。2週間後の2回目の依頼が、本物のニーズだ。読まれない3つのレポートを、具体的な判断に結びついた週次のSlackダイジェスト1つに置き換える。「Q3に向けてパイプライン・カバレッジが2.8倍、3.5倍にする必要があり、不足している4つのセグメントがこれです」。それは読まれる。それは転送される。それがあなたをQBRのスライドに載せる。
落とし穴2：CRMを過剰にカスタマイズする（技術的負債は速く積み重なる）
症状。 SalesforceまたはHubSpotの設定でOpportunityオブジェクトを開く。カスタムフィールドを数える。直感的な反応が「うわっ」なら、あなたはもうわかっている。47個のカスタムフィールド、12個のレコードタイプ、そして誰も書いた覚えも頼んだ覚えもない2024年の検証ルールがある。
実際の数字。 2つの基準。オブジェクトあたり30個を超えるカスタムフィールドがあれば、あなたは負債を抱えている。それらのフィールドの15%超がレコード全体で5%未満の使用率なら、あなたは負債を返済する代わりに利息を払っている。フィールド利用率レポートを引っ張る（Salesforce Optimizerはこれを無料で行う。HubSpotにはField Insightsがある）。数字がすべてを教える。
なぜ重要か。 すべての死んだフィールドは、すべてのレポート、すべてのページレイアウト、すべての新任担当者のオンボーディング、そしてスキーマをマッピングしなければならないすべての連携への税だ。肥大化したCRMは、ただ遅く感じるだけではない（それはあなたの予測（forecast）モデルが、入ってくるデータを信頼できない理由だ）。
修正。 四半期ごとのフィールドクリーンアップの儀式。利用率レポートを引っ張る。90日間編集されていない、レコード使用率10%未満のものはすべて削除リストに載せる。#revops-changesで2週間告知する。削除せず、無効化し、共有のConfluenceページで保つ進行中のCHANGELOGに廃止を文書化する。これを3四半期続けると、組織は汚れていく代わりにきれいになっていき、それだけでRevOpsの人の80%より先んじる。
落とし穴3：死んだ自動化の停止の儀式を飛ばす
症状。 2023年のProcess Builder、Flow、Workatoのレシピ、Zapが、いまだにすべてのレコードで発火している。昨日1つ開いたら、説明フィールドに「TODO：説明を書く」とあった。その半分が何をするのか誰も知らない。誰もオフにしたがらない。何かを壊した張本人になりたくないからだ。
実際の数字。 組織の有効なフローを数える。それから、過去90日に触れられた（編集された、デバッグされた、あるいは開かれただけでも）フローを数える。その差はたいてい40〜60%だ。それがあなたの死んだ自動化の面積であり、その一つひとつが、適切なエッジケースを待つ将来のSev 1インシデントだ。
なぜ難しいか。 自動化を停止するのは、作るより危険に感じる。作る ＝ 目に見える勝ち。停止 ＝ 何かが壊れない限り見えない勝ちで、壊れた場合は目に見える負けだ。だから組織は、ハードドライブがファイルを溜め込むようにフローを溜め込む。
修正。 月次の削除リストレビュー、カレンダーに入れ、本物の会議として扱う。3つのルール。
- 有効なオーナーがいない（その人物がもう在籍しておらず、後任が割り当てられていない）→ 削除候補。
- 12か月編集がなく、かつドキュメントがない → 削除候補。
- ログが月1回未満の実行を示す → 削除候補。
まず無効化し、削除しない。30日待つ。誰も悲鳴を上げなければ、削除し、CHANGELOGに葬送を書く。何をしていたか、なぜ死んだか、何が置き換えたか（もしあれば）。葬送が要点だ。それは組織に、ものを停止するのは普通だと教え、それが根本から肥大化を止める方法だ。
落とし穴4：パイプラインの健全性管理を直さずに予測精度を追う
症状。 CROは±5%の予測精度を求めている。あなたは加重パイプラインモデルを作り、担当者のコールのセンチメントを重ね、もしかするとAI予測（forecast）ツールのパイロットまでしている。その一方で、システム内のオープン商談の38%がクローズ日を過去に持っている。あなたは間違った問題を解いている。
実際の数字。 クローズ日が今日より14日以上過去になっているオープンパイプラインの割合を引っ張る。健全な組織は10%未満に収まる。不健全な組織は30〜45%に収まる。古くなった日付を与えられた予測（forecast）モデルは、ランダムな入力を持つ電卓であり、どれだけモデルを精緻にしてもそれを救えない。
CROとの正直な対話。 「商談の38%が停滞しているパイプラインで、±5%の精度には達せません。計算が文字どおり成り立ちません。健全性管理に6週間ください、それからモデルに6週間。健全性管理のステップを飛ばせば、私たちはただ、より自信満々に間違うだけです」。
修正。 健全性管理が先、モデルが後。担当者のスコアカードに結びついた週次の古いデータレポートをリリースする。停滞商談数、停滞商談の金額、最終アクティビティからの日数。セールスのリーダー陣のチャンネルで見えるようにする。それを予測（forecast）会議の説明責任に結びつける（担当者が商談をcommitし、クローズ日が3週間過去なら、その商談はcommitに入れない）。停滞率が12%を下回ったら、そこでモデルの話をする。信頼できるパイプライン・カバレッジは、信頼できない予測（forecast）の手法に勝る。
落とし穴5：戦略家ではなく「チケット受け係」になる
症状。 あなたは月曜にJiraを開く。43件のチケット。「ピックリストの値を追加」。「地域4の新しいレポート」。「ステージ定義の誤字を修正」。もう金曜だ。あなたはそのうち41件をリリースした。本物のプロジェクトを6週間前進させていない。あなたは疲れ果て、そしてなぜか恥ずかしくもある。
実際の数字。 2週間、自分の時間を追う（Toggl、Clockify、スプレッドシートでも機能する）。プロジェクト業務に20%未満、チケットに80%超が行くなら、あなたは吸収されている。あなたはもうRevOpsではない。CRMヘルプデスクだ。キャリアへの影響は容赦ない。シニアRevOpsの職は、チケットを片づけた人ではなく、プロジェクトをリリースした人で埋まる。
なぜ起きるか。 チケットは生産的に感じる。一つひとつが緑のチェックマークで閉じる。それらはまた無限だ。1人が1つのことにイエスと言うと、どのチームもRevOpsを自分専用の管理者として扱うからだ。
修正。 オフィスアワー方式。カレンダーをブロックする。チケットは週2回、2時間の枠2つでトリアージする（たとえば火曜の午後1〜3時と木曜の午後1〜3時）。その枠の外では、本当に火がついている（本番ダウン、報酬に影響、案件をブロック）のでない限り、キューは閉じている。プロジェクト業務に丸2日を守る。マネージャーにまさにこう伝える。「今四半期にテリトリーモデルと予測（forecast）の再構築をリリースしたいなら、週に2日の守られた日が必要です。それがなければリリースされないものがこれです」。
最初の週は居心地が悪い。4週目には組織が適応する。8週目には、依頼者たちが自分のチケットの30%を自分で解決し始める。摩擦が彼らに先に考えさせたからだ。それがまさに要点だ。
落とし穴6：テリトリーを早すぎる段階で区分けし直す
症状。 あなたは「データがそう言った」からQ2にテリトリーを区分けし直した。担当者が反発する。トップパフォーマー3人が辞めると脅す。CROがQ3に変更を撤回する。あなたはいまや、マイナスのパイプラインを生み、簡単には取り戻せない政治的資本を燃やした変更に、6か月を費やした。
実際の数字。 ミッドマーケットのセールス組織にまたがる社内ベンチマークは、それをテリトリー移行中の15〜25%のパイプライン・カバレッジの破壊と位置づけており、区分けが良ければ6〜9か月かけて、悪ければ12か月以上かけて回復する。そのコストはスプレッドシート上では見えないが、取締役会の資料の上では破滅的だ。
なぜ起きるか。 RevOpsの人はデータに偏りを見て（担当者Aは担当者Bの2.3倍の指名アカウントを持つ）、最適化脳が「直せ」と言う。最適化脳は、テリトリーがまた、関係であり、進行中の対話であり、半分クローズした案件であり、担当者が誰を相手にしているかというメンタルモデルでもあることを忘れる。あなたはスプレッドシート上でアカウントを動かしているだけではない。10か月分の文脈を断ち切っているのだ。
修正。 3つのルール。
- 意味のある区分けし直しの間は最低12か月。それより頻繁に区分けし直す必要があるなら、間違っているのはテリトリーではなく、根底のセグメンテーションのロジックだ。
- 全体展開の前にパイロット。新しいロジックを1つのセグメント（1つの地域、1つの業界の縦割り）で丸一四半期テストする。広げる前に、パイプライン・カバレッジ、案件スピード、担当者の満足度を測る。
- 担当者を部屋に。固定する前に、各セグメントのトップ担当者3人に提案された区分けを通して説明する。彼らは、スプレッドシートが見ない「アカウントXは現在交渉中、動かすな」という問題を捕まえる。
18か月持ちこたえるゆっくりしたテリトリー計画は、6か月で撤回される速い計画に勝る。
落とし穴7：帰属について財務と連携しない
症状。 マーケティングはパイプラインの60%を源泉したと主張する。財務は帳簿を締め、22%と報告する。CROは取締役会で両方の数字を説明しようとしている。あなたは、入っていって片づけなければならない人だ。マーケティングと財務はどちらも技術的には「正しい」。異なる定義、異なる期間、異なる帰属ウィンドウを使っているからだ。
実際の数字。 あなたのCRMの源泉パイプラインの数字が、財務のブッキングと10%以内で照合できないなら、あなたは信頼性の問題を抱えており、まだそれに気づいていない。だが取締役会は気づいており、それはあなたのいない会話の中で「マーケティングの数字は信頼できない」として現れる。
なぜ見た目以上に重要か。 帰属の不一致は、マーケティングと財務の間の信頼の代理指標であり、RevOpsはまさにその真ん中に座っている。これを直すRevOpsの人は、一四半期のうちに社内で最も信頼されるオペレーターになる。建物の中のすべての役職者が、何年もそれについてひそかに苛立ってきたからだ。
修正。 FP&Aとの月次の帰属の同期。1時間、カレンダーに入れ、容赦なく。アジェンダは常に同じ。
- 先月の源泉パイプラインの数字をブッキングに照合する。計算を見せる。
- 翌月の定義を固定する。何をマーケティング源泉とみなすか、何を影響とみなすか、どの期間か、どの帰属ウィンドウか。
- QBRのスライドを一緒に承認する。同じ数字、同じ定義、どちらの側もCROが見る前に同じページに。
2サイクルのうちに、ギャップは38%から8%に縮む。3サイクルのうちに、財務が取締役会の準備であなたをCCに入れ始める。それが、あなたがRevOpsマネージャーであることをやめ、ディレクター候補のオペレーターになり始める瞬間だ。
これらの壁が本当にあなたに告げていること
これらの壁にぶつかるのは、あなたが仕事が下手だということではない。役割の形が見えるくらい長く居続けたということだ。
最初の6か月は、リリースできる人に報いる。明らかな散らかりを片づけ、明らかなdashboardを作り、明らかなチケットを片づける。次の12か月は、選べる人に報いる。何を作らないか、何を停止するか、どの対話を主導するか、CROとCFOのいる部屋でどの数字を擁護するかを選ぶ。
突破する人は、アクティビティの最適化をやめ、CROが実際に発する2つの問いの最適化を始める。「数字はいくつになるのか」と「何が変わったのか」だ。すべてのdashboard、すべてのフロー、すべてのテリトリーの区分け、すべての帰属の議論は、その2つの問いに答える助けになるか、ならないかのどちらかだ。ならないなら、それはノイズであり、キューはノイズで満ちている。
いま自分が最も近い壁を選べ。今週、診断を回せ。来週、修正をリリースせよ。それから戻ってきて、次のを読め。
さらに詳しく
