日本語

場当たり的な継ぎ接ぎのないMAPとCRMのアーキテクチャ:MOps再構築プレイブック

フィールドマネージャーを開いたら、247個のカスタムフィールドを数えました。その半分は2023年に退職した人が所有者です。リードからコンタクトへの同期は、前任の管理者が第2四半期に「直した」とき以来壊れています。ピックリストのうち2つには、存在すべきでないフリーテキストの値があります。ライフサイクルステージがMarketoとSalesforceの両方によって書き込まれるため、レコードの14%が同期サイクルごとにMQLとLeadの間を行き来しています。

MOpsへようこそ。

このスタックを引き継いだばかりの方、あるいは「次のキャンペーンが終わったら」きれいにすると自分に言い聞かせながら2年間それを眺めてきた方、これがそのプレイブックです。3つ前の仕事のときに誰かが手渡してくれていたらと願う、そのプレイブックです。目標はきれいな図ではありません。目標は、データポイントごとに1つの信頼できる唯一の情報源、フィールドごとに1人の所有者、そして午前3時にあなたを起こさない連携です。

MAPからCRMへのデータフロー:実際の契約

ほとんどのチームは、MAPからCRMへの連携をブラックボックスのように扱います。そうではありません。それは契約であり、誰もその契約を書き留めていないなら、あなたが持っているのは場当たり的な継ぎ接ぎです。

契約には4つの部分があります。これらを間違えれば、ほかの何も意味をなしません。

リード対コンタクト:何が引き継がれ、何が消えるか

LeadがSalesforce(またはCRMが何と呼んでいようと)でContactに変換されるとき、明示的にマッピングしていない限りデータを失います。ほとんどのCRMのデフォルトの挙動:

  • 対応するContactフィールドを持つ標準のLeadフィールド:引き継がれる
  • 対応するContactフィールドを持たないカスタムのLeadフィールド:消える
  • アクティビティ履歴:通常は保持される、時に孤立する
  • MAP側のスコアリングフィールド:MAPがLeadのみに書き込むか両方のオブジェクトに書き込むかに完全に依存する

汚れた秘密は、MOpsチームの80%がデモグラフィックと行動のスコアをLeadオブジェクトのみに書き込み、そしてSDRがLeadを変換してスコアが消えると驚いたふりをすることです。MAPがMarketoかPardotなら、スコアリングフィールドはLeadとContactの両方に書き込むべきです。あるいは、作成時にLeadをContactに変換すべきです(HubSpotがデフォルトとする「すべてContact、Leadなし」モデル)。

1つを選んでください。それを文書化してください。出血を止めてください。

ライフサイクルステージ:MAPが書き、CRMが読む。決して両方ではない。

これは、このプレイブック全体で最も重要なルールです。両方のシステムがライフサイクルステージに書き込めるなら、競合状態が発生します。行き来するレコードが生まれます。Closed-Wonの更新の3分後に配信停止のWebhookが発火したために、MAPがちょうどMQLに降格させたばかりのContactで、SDRが商談を成約させる、ということが起きます。

書き手を選んでください。MAPは行動シグナルを最初に見るため、通常は正しいです。CRMはライフサイクルステージを読みます。それを奪い合うことはしません。営業が上書きする必要がある場合(例:手動で誰かをSALと印付けする)は、別のフィールド(sales_stage_override__c)を作り、MAPの自動化にその上書きを尊重させます。2つのシステムに同じ列について議論させてはいけません。

同期のタイミング:リアルタイムが常に良いとは限らない

デフォルトの衝動は「リアルタイムにする」です。これは半分の確率で間違っています。

リアルタイム同期が理にかなうのは:

  • フォーム入力(SDRのキューが更新される前にリードがCRMに届かなければならない)
  • ルーティングを駆動するライフサイクルステージの遷移
  • Closed-Wonのステータス(収益アトリビューションは待てない)

バッチ同期(15分、1時間、夜間)が理にかなうのは:

  • 一括のスコア再計算
  • リストメンバーシップの切り替え
  • アクティビティ履歴の補完
  • 1時間あたり1,000件を超えるレコード更新を発火させるあらゆるもの

なぜこれが重要なのか。「10分ごと」はスコアリング同期にとって考えうる最悪の設定だからです。SDRが信頼できないほど遅く、キャンペーン配信中にAPI上限をクラッシュさせるほど速く、そして月次の突合クエリが捕まえるまで競合状態を見えなくするのにちょうどよい頻度なのです。

1つだけ覚えておくなら:引き継ぎにはリアルタイム、健全性にはバッチ。

MQLの引き継ぎ:1つのフィールド、1人の所有者、1つの定義

止まってください。Salesforceを開いてください。名前に「MQL」が入ったフィールドを検索してください。少なくとも3つはあるほうにコーヒーを賭けます:

  • MQL_Date__c(Marketoが設定)
  • Marketing_Qualified__c(2022年のワークフロールールが設定)
  • Lifecycle_Stage = 「MQL」(HubSpotが設定)

1つを選んでください。残りの2つを削除してください。MQLの引き継ぎは、1つのフィールド、1人の所有者(MOps)、1つの定義(日付が付いたConfluenceドキュメントに書き留められたもの)です。営業がそのフィールドを信頼しないなら、それはフィールドの問題ではなく定義の問題です。4つ目のフィールドを追加しても、定義の問題は決して直りません。

フィールドの肥大化の問題

フィールドの肥大化は、MAP+CRMスタックが死ぬ原因です。たった1つの劇的な障害ではありません。誰も所有しないフィールド、誰も開かない1つのレポートで使われ、誰も文書化しなかった1つのワークフローで設定されるフィールドが、ゆっくりと蓄積していくことです。

どうやって247個のカスタムフィールドに至ったか

すべてのフィールドには誕生の物語があります。おおよそ:

  • 30%は本物で、使われていて、所有されている。これらは問題ありません。
  • 25%は2022年のキャンペーンのために作られ、いまだ書き込まれているが、何からも読まれていない。
  • 20%は退職した営業リーダーが作り、廃止されたダッシュボードにマッピングされていたが、フィールドはまだすべてのページレイアウトに残っている。
  • 15%はわずかに名前の違う重複(Industry__c、industry_v2__c、Account_Industry__c)。
  • 10%は連携の「ゴーストフィールド」で、18か月前に切断された連携によって自動的に作られたが、フィールドは残ったまま。

誰もフィールドを削除しません。削除はリスクに感じられるからです。だからこそ、プロセスが必要なのです。

90日のフィールド監査フレームワーク

これを四半期ごとに実行してください。金曜に4時間を確保してください。MOpsで最もレバレッジの高いクリーンアップ作業です。

ステップ1:使用状況レポートを引き出す。 すべてのカスタムフィールドについて、数えます:

  • 非nullの値を持つレコード数(直近90日の書き込み)
  • そのフィールドを参照するレポート数
  • そのフィールドを参照するワークフロー/自動化数
  • それに書き込む連携数

4つすべてがゼロなら、そのフィールドは死んでいます。タグを付けます。

ステップ2:所有者を見つける。 すべてのフィールドには名前が紐づく必要があります。「作成者」を引き出し、その人がまだ在籍しているか確認します。いなければ、そのフィールドをチームに回します。誰かがそれを主張しますか。7日以内に誰も主張しなければ、それは孤児です。

ステップ3:削除リストを作る。 3つのバケット:

  • 完全削除:使用ゼロ AND 所有者なし。次のスプリントで削除。
  • 非推奨化:多少の使用はあるが、所有者が冗長だと同意する。説明欄に非推奨と記し、レイアウトから隠し、90日後の削除を予定する。
  • 文書化:アクティブ、所有あり、これ以上の対応なし。説明が空欄なら書く。

ステップ4:定着させる。 フィールド作成ポリシーを追加します。すべての新しいカスタムフィールドには、説明、所有者、「レビュー期限」の日付が必要です。説明なし = フィールドなし。CRM管理者にそれを強制してもらいます。やってくれないなら、そのワークフロー1つの管理者権限を自分で取得します。

50個のフィールドには到達しないでしょう。おそらく100個には到達できます。それが目標です。

人の入れ替わりに耐える命名規則

スタックを引き継ぐ次の管理者が、フィールドが何をするか5秒で推測できないなら、その名前は間違っています。リネームしてください。

私が使っている、3回の転職を生き延びた命名規則:

  • mkt_*:MAPが書き込む。マーケティングが所有。
  • sfdc_*:Salesforceのネイティブフィールド、または営業所有のカスタムフィールド。
  • ext_*:外部連携(Clearbit、ZoomInfo、6senseなど)が書き込む。他の全員にとっては読み取り専用。
  • ops_*:運用/計算フィールド(地域、セグメント、アカウントティア)。
  • プレフィックスなし:あなたが作っていない標準フィールド。

ピックリストの規律は、あなたが思う以上に重要です。「USA」「U.S.A.」「United States」「US」「America」がすべて同じデータセットに入っているフリーテキストの国フィールドは、レポートを台無しにします。ピックリストを固定してください。営業が反論したら、USAの収益が5つのバケットに分かれているセグメントレポートを見せてください。

5秒ルール:新しい管理者がフィールドマネージャーを開き、cust_dt_2_v3__c が何をするか5秒で推測できないなら、そのフィールドの名前は間違っています。リネームしてください。そう、2つのレポートが壊れます。レポートを直してください。未来のあなたが感謝の手紙を送ってくるでしょう。

MAPの選定:Marketo対HubSpot対Pardot対Rework

MAP連携の苦痛の半分は、会社に合わないMAPを選ぶことから来ます。私の考え方はこうです。

Marketo(現Adobe)

次の場合にMarketoを選びます:

  • 専任のMAP管理者がいる(「Marketoも担当するマーケティングマネージャー」ではない)
  • キャンペーンプログラムが本当に複雑(マルチタッチのナーチャリング、アカウントベースの施策、数十のセグメント)
  • エンタープライズ(従業員1,000人以上)か、エンタープライズ型のデマンドジェネレーションを運用している
  • 価格と学習曲線に耐えられる

50人のスタートアップなら、Marketoを選ばないでください。プラットフォームの8%を使い、価格の100%を払い、Salesforceへの連携が1人のFTEを食い尽くします。

HubSpot

次の場合にHubSpotを選びます:

  • マーケティングがGTMの動きを主導する
  • チームがUIで暮らしている(API呼び出しやSQLではなく)
  • ミッドマーケット(従業員50〜500人)
  • CRMとMAPを同じベンダーから欲しく、HubSpotのCRM(SMBには十分だがエンタープライズでは手薄になる)で問題ない

HubSpotの強みは、CRMとMAPが1つのシステムであることで、場当たり的な継ぎ接ぎの問題が部分的に消えることです。弱みは、HubSpot CRMを使い切ってSalesforceを後付けすると、余計な手間を伴って連携の問題を作り直してしまうことです。

Pardot(Marketing Cloud Account Engagement)

次の場合にPardotを選びます:

  • Salesforceネイティブの組織で、Salesforce管理者がマーケティングオートメーションも所有している
  • 凝ったプログラムロジックが必要ない
  • ライフサイクルステージとスコアリングをSFDCオブジェクトに密に結合させたい

Pardotの強みは、SFDC連携がネイティブ(SFDCの内部に存在する)であることです。弱みは、MAP自体が古いことです。チームが現代的なUXを必要とするなら、彼らはあなたに抵抗するでしょう。

Rework

次の場合にReworkを選びます:

  • 小〜中規模のB2B(従業員20〜500人)
  • 営業とマーケティングが1つのパイプラインを共有していて、2つのツールがそれを奪い合うのを避けたい
  • 専任のMAP管理者がおらず、欲しくもない
  • 別々のMAP+CRM連携を維持するより、リードキャプチャ、スコアリング、ルーティングを内蔵した1つのCRMを持ちたい

この特定の問題に対するReworkの売り込み:維持すべきMAPからCRMへの連携が存在しない、なぜなら別個のMAPが存在しないからです。リードキャプチャ、スコアリング、ライフサイクルステージ、パイプラインが1つのシステムに存在します。Marketoのエンタープライズ向けプログラムの複雑さの一部をあきらめます。その代わりに、場当たり的な継ぎ接ぎをあきらめられます。

1人のMOpsゼネラリストを抱える30人のB2B SaaSチームなら、Marketo+SFDCスタックはライセンスで年間およそ8万ドル、加えて維持に0.5 FTEかかります。同じワークフローをReworkで運用すると、CRMティアで1ユーザーあたり月12ドル(30人のチームで年間約1万ドル)で、MAP連携は「維持する」から「存在しない」になります。

それが万人にとっての正解ではありません。それを認める以上に多くのチームにとっての正解です。

ゼロから再構築するという判断

ある時点で、パッチを当てるほうが再構築よりコストがかかるようになります。難しいのは、その時点を見極めることです。

40%ルール:MOpsチームの時間の40%超が連携の修正、ゴーストフィールド、突合クエリに費やされていて、それが2四半期連続で続いているなら、パッチの限界点を過ぎています。再構築してください。

その他のシグナル:

  • 3つ以上の「信頼できる」ライフサイクルフィールドが存在し、どれが正しいか人々が議論している
  • 同期エラーが1日あたりレコードの0.5%を超えている
  • 新しいMOps採用者が最初の些細でない変更をリリースするのに90日以上かかる
  • 重要なフィールドの監査証跡が「Sandraに聞いて、彼女が覚えている」である
  • MAP-CRM連携に2つを超えるカスタムミドルウェアのコンポーネント(Workatoのレシピ、Zapierのzap、カスタムApex)がある

再構築は「すべて吹き飛ばす」作業ではありません。並行構築です。新しいインスタンス(または既存インスタンス内のきれいなスキーマ)を立ち上げ、キャンペーンを1つずつ移行し、検証し、それから古いものを非推奨にします。90〜180日かかります。それは、今後18か月分のパッチよりも速いのです。

上司には、これはプロジェクトではなく投資だと伝えてください。投資は複利で増えます。パッチはそうではありません。

連携のヘルスモニタリング

健全なMAP-CRM連携にはテレメトリがあります。それが見えなければ、直すこともできません。

すべてのMOpsリードが動かしておくべき3つのアラート:

1. 同期エラー率アラート。 1時間のウィンドウで、試行したレコードの0.5%を同期エラーが超えたら発火します。これは、営業が気づく前にAPI上限の問題、検証ルールの衝突、ミドルウェアの障害を捕まえます。

2. ライフサイクルの行き来アラート。 24時間以内にあるレコードのライフサイクルステージが3回を超えて変わったら発火します。これは、2つのシステムが同じフィールドを奪い合っている競合状態を捕まえます。

3. フォームからCRMまでのレイテンシアラート。 あるフォーム送信がCRMに届くまで90秒を超えたら発火します。SDRは、他のどの指標よりもこの指標に基づいてシステムを信頼します。

毎朝午前6時に日次の突合クエリも実行し、あなた(信頼できるようになるまではあなただけ)にメールするべきです。私がSalesforce + Marketoで実行するクエリ:

-- 直近7日間で、CRMに対応するものがないMAP内のレコード
SELECT email, lifecycle_stage, last_modified
FROM map_leads
WHERE crm_id IS NULL
  AND created > DATEADD(day, -7, CURRENT_DATE)
  AND lifecycle_stage IN ('MQL', 'SAL');

その結果セットにあるものはすべて、営業担当者に届くべきだったのに届かなかったリードです。クエリが1日に5行を超えて返すなら、あなたがまだ知らない連携の問題があります。

ダッシュボードのバリアント:エラータイプ別の同期エラー数、MQL引き継ぎレイテンシのP50/P95、各ライフサイクルステージの総レコード数の週次ビュー。それをMOps用Confluenceスペースのホームページにしてください。VPが「システムは健全か」と尋ねたら、ダッシュボードを指して、データとともに「はい」か「いいえ」と答えます。

1つの信頼できる唯一の情報源、1つのMQL定義、1人の所有者

このプレイブックに1つだけ持ち帰るものがあるとすれば、それはこれです。MAP+CRMスタックのすべてのデータポイントには、ちょうど1つの信頼できる唯一の情報源、1人の所有者、1つの定義があります。それ以外はすべて場当たり的な継ぎ接ぎです。

営業担当者がMQLは「本当はMQLではない」と反論するとき、それはフィールドの問題ではありません。定義の問題です。定義を直してください。それを文書化してください。営業リーダーシップに書面で承認してもらってください。そうすれば、フィールドは無関係になります。なぜなら、それが何を意味するか全員が同意しているからです。

2つのシステムが同じフィールドに書き込むとき、1つを選んでください。もう1つは読み取り専用になるか、別の上書きフィールドを持ちます。競合状態は、ワークフローを増やしても良くなりません。

カスタムフィールドに所有者がいないとき、それを削除してください。3か月後に誰かがそれがないことに気づいたら、実際に誰が使っていたかが分かります。たいていの場合、誰も気づきません。そしてあなたは、それを引き継ぐ次の管理者のために、システムをよりシンプルにしたことになります。

場当たり的な継ぎ接ぎは複利で増えます。今四半期にあなたが取るすべての近道は、来年に後任が引き継ぐ問題です。時に正解は再構築することです。時に正解は、そもそも連携を必要としないスタックに切り替えることです。そしてほぼ常に、正解は、追加するより多くを削除することです。

それが仕事です。

さらに詳しく