アラインドスタック：CRM、CSプラットフォーム、Revenue Intelligenceがセームをまたいで連携する仕組み
Turn this article into takeaways for your work.
Each assistant summarizes the article only for you and suggests best practices for your work.
顧客は同じ週に2本の電話を受けました。AEはExpansionの意向を確認するために電話し、CSMはサポートのエスカレーションについて話し合うために電話しました。どちらも相手が連絡していたことを知りませんでした。3ヶ月前から競合他社への乗り換えを検討していた顧客は、ベンダーの社内チームが連携していないことを示す、また一つのデータポイントを手に入れることになりました。
このシナリオは、多くのRevenue責任者が認めたくないほど一般的です。そしてその原因は、ほぼ常に人の問題ではなく、配線の問題です。
SalesはCRMで動き、CSはCSプラットフォームで動きます。Revenue Intelligenceはこの二つを橋渡しするはずですが、ほとんどの実装では、CSが決して見ることのないセールスコーチングツールとして扱われています。結果として、二つのチームが同じ顧客について二つの異なる情報を元に動くことになり、そのギャップが最も重要な場面で露呈します。
この記事は配線の問題を修正することについてのものです。各カテゴリで最良のベンダーを選ぶことについてではありません。ベンダーは各カテゴリに何が存在するかを示す実例です。焦点は、これらのツールをSales-CSのセームをまたいで連携させるためのインテグレーション・アーキテクチャにあります。
セームにある3つのツールカテゴリ
Rework分析： Sales-CSスタックの失敗のほとんどは、ベンダー選定の問題ではありません。インテグレーション・アーキテクチャの問題です。3-Layerアラインド・レベニュー・スタック（CRM＋CSプラットフォーム＋Revenue Intelligence）は、3つのセームのインテグレーションポイントの強さ以上にはなりません。カテゴリのツールを置き換えると、通常3〜6ヶ月の移行期間がかかり、ミスアライメントを引き起こしたデータフローのギャップの根本原因が解消されることはほとんどありません。ミッドマーケットの導入事例の大多数では、既存のインテグレーションポイントを正しく設定することが、最初に打つべきレバレッジの高い一手です。
インテグレーション・アーキテクチャの詳細に入る前に、各カテゴリが何を得意とするように作られているのか、そしてどこで限界を迎えるのかを明確にしておくと役立ちます。
主要データ：Revenue Stackのインテグレーション
- Gainsightの2024年Customer Successの現状レポートによると、CRMとCSプラットフォームがアカウントレベルでリアルタイムの双方向データを共有しているB2B SaaS企業はわずか**26%**です。
- Gartnerによると、中堅企業は平均6〜8つのRevenueツールを使用していますが、意味のあるインテグレーションを達成できているのはその半数未満です。
- Revenue Intelligenceプラットフォームは、61%の実装においてセールスコーチングを主な用途として使われており、CSチームは、投資を正当化した購買者・顧客の会話データにアクセスできていません（Gong社内調査、2024年）。
CRM：ディールとSalesアクティビティの基幹レコードシステム
CRMは、Pipeline、コンタクト、Opportunity、そしてSalesアクティビティの権威ある記録です。成約前の全ストーリーを記録しています：ディールがどのように生まれたか、誰が関与したか、何が約束されたか、勝因は何か、どのような反論が出たか。
停止するポイント：ほとんどのCRMは成約前のWorkflowのために構築されています。成約後のHealthデータ（採用状況、サポート履歴、エンゲージメントトレンド）は通常、デフォルトではそこに存在しません。CRMは契約書にインクが乾く前に起きたことをすべて知っています。その後に何が起きたかについては、驚くほど知らないことが多いのです。
このカテゴリに存在するものの例：Salesforce、HubSpot CRM、Pipedrive、Microsoft Dynamics。これらはカテゴリの実例であり、ランキングや推薦ではありません。Gartner Magic Quadrant for Sales Force Automation Platformsは、このカテゴリにおけるベンダーの成熟度を評価するための代表的な情報源です。
CSプラットフォーム：成約後のHealthの基幹レコードシステム
CSプラットフォームは、ディールが成約した後に何が起きるかを追跡します：Onboardingの進捗、採用マイルストーン、Health Score、QBRのステータス、Renewalタイムライン、そしてCSMの継続的な関係ノート。ディールライフサイクルではなく、顧客ライフサイクルを中心に構築されています。
停止するポイント：CSプラットフォームは通常、ディールのコンテキストが弱いです。CSMはアカウントを開いてHealthデータを見ますが、AEがセールスプロセスで何を約束したか、元のICP適合スコアはどうだったか、どのような競合反論が出たか、すでにどのようなExpansionの会話が試みられたかを確認できないことが多いのです。
このカテゴリに存在するものの例：Gainsight、ChurnZero、Catalyst、Totango、ClientSuccess。カテゴリの実例であり、比較や推薦ではありません。Gartner Magic Quadrant for Customer Success Management Platformsは、この領域におけるベンダーのポジショニングについてのアナリストの見解を提供しています。
Revenue Intelligence：両者にまたがる会話シグナル
Revenue Intelligenceプラットフォームは、SalesとCSの会話（通話、メール、ミーティング）をキャプチャして分析し、ディールのHealth、リスク、競合の言及、エンゲージメントパターンについてのシグナルを表面化させます。理論上は、このレイヤーが両チームに同じ会話データへのアクセスを与えることで、SalesとCSを橋渡しします。
実際には、ほとんどの実装でセールスコーチングとディールレビューツールとして使用されており、CSのアクセスは限定的または皆無です。
このカテゴリに存在するものの例：Gong、Chorus（ZoomInfo）、Clari Copilot、Jiminny。
サポートレイヤー：請求と製品利用データ
これは従来の意味での「ツールカテゴリ」ではありません。CRMとCSプラットフォームのデータが提供できないことが多い、正直なシグナルです。製品利用データは、最後のQBRでCSMに何を伝えたか、あるいはCSMが割り当てたHealth Scoreに関係なく、顧客が製品で実際に何をしているかを教えてくれます。
請求データは財務的な精度を加えます：支払いが最新かどうか、利用状況がExpansionを示すオーバーエージに向かっているかどうか、ダウングレードが要求されたがまだ処理されていないかどうか。
利用データと請求データをRenewalプロセスに早期に組み込んでいる企業は、Renewalにおいて構造的な優位性を持ちます。シグナルは客観的で、人間が更新する必要がなく、多くの場合、どちらのチームにも顧客が何かを言う前にリスクを表面化させます。
実際に重要な3つのインテグレーションポイント
5ポイントのインテグレーション・アーキテクチャはスライドでは優雅に見えますが、実践では失敗します。セームのアラインメントに影響を与える3つのインテグレーションポイントに集中しましょう。
名称付きフレームワーク：3-Layerアラインド・レベニュー・スタック 3-Layerアラインド・レベニュー・スタックは、Sales-CSのセームにまたがる3つのツールカテゴリを定義します。Layer 1（CRM：ディールとSalesアクティビティの基幹レコードシステム）、Layer 2（CSプラットフォーム：成約後のHealthの基幹レコードシステム）、Layer 3（Revenue Intelligence：両者にまたがる会話シグナル）、そしてそれらを連携させる3つのインテグレーションポイントです。インテグレーションポイント1：成約時にCSプラットフォームへ流れるディールコンテキスト。インテグレーションポイント2：CRMに表面化するHealth ScoreとRenewalリスク。インテグレーションポイント3：CSプラットフォームからのExpansionシグナルがCRMでAEのアウトリーチをトリガーする。第4の構成要素（請求と製品利用データ）は、どちらのチームも操作できない正直なシグナルとして、Layer 1と2に客観的に供給されます。3つのインテグレーションポイントはすべて、アカウントとコンタクトレベルで双方向に流れなければなりません。アカウントレベルのみのインテグレーションでは、コンバージョン分析、リスク検出、Upsellタイミングを正確にする個別シグナルが失われます。
インテグレーション1：成約時にCSプラットフォームへ流れるディールコンテキスト
ディールが成約した時、ディールコンテキストのパッケージが自動的にCSプラットフォームのアカウントレコードに反映されるべきです。これには以下が含まれます：AEからのディールノート、元のユースケース、セールスプロセス中に行われた約束、ICP適合スコア、競合コンテキスト（競合他社が積極的に評価されたか？）、主要なステークホルダーとその役割、そしてディールを勝ち取るために行われた製品やデリバリーのコミットメント。
これがないと、CSMは空白のアカウントからOnboardingを開始し、何が販売されたかを逆算しなければなりません。そのギャップが「過剰な約束 / 不十分な提供」の状況が生まれる場所です。
必要なこと：ディールがClosed Wonに移行する前に必須となるCRMフィールドの定義、そしてステータス変更時にそれらのフィールドをCSプラットフォームのアカウントレコードにプッシュするWorkflow。RevOpsがこの設定を担当しますが、VP Salesがフィールドの衛生管理を徹底しなければなりません。担当者がスキップできる「ディールノート」のCRMステージゲートは、このインテグレーションを無価値にします。どのフィールドが最も重要かは、ディールコンテキスト移転チェックリストに具体的に記載されています。
インテグレーション2：CRMに表面化するHealth ScoreとRenewalリスク
AEは、CRMを離れることなく、アカウントのHealth、Renewalリスクティア、Expansion準備状況を確認できるべきです。サマリーメールではなく。CSMからのSlackメッセージでもなく。CSプラットフォームが更新するどのようなケイデンスであっても、CRMアカウントレコード上のライブフィールドとして。
このインテグレーションがなければ、AEのアカウントHealthへの唯一の窓口はCSMから聞くことです。それはレイテンシーの問題（CSMは何かがすでに悪化するまでAEにブリーフィングしないかもしれません）であり、カバレッジの問題（AEはすべてのCSMに個別に聞くことなく、自分の全アカウントでExpansionシグナルを積極的に見つけることができません）です。
必要なこと：CSプラットフォームがHealth Score、Renewalリスクティア、ExpansionフラグをAPIでCRMアカウントレコードにプッシュすること。RevOpsがフィールドマッピングと同期ケイデンスを担当します。主要なCSプラットフォームのほとんどは、ネイティブまたはミドルウェア経由でこれをサポートしています。ここでHealth Scoringを意味のあるものにするには、Sales側の商業シグナルを組み込む必要があります。そのモデルについては、営業コンテキストを含む顧客ヘルススコアリングの記事で説明しています。
インテグレーション3：ExpansionシグナルがCRMでAEのアウトリーチをトリガーする
CSプラットフォームのExpansionシグナルが発火した時（製品利用閾値の超過、Championの昇進、QBRで特定の成果が出た）、そのシグナルは、CSMがAEに手動でメッセージを送る必要なく、CRMにAEが対応するタスクやOpportunityを作成すべきです。
これがないと、ExpansionシグナルはCSプラットフォームの中で死にます。CSMがそれに気づきます。もしかしたらAEにメールするかもしれません。AEが新しいロゴのディールに取り組んでいて、1週間返信しないかもしれません。AEが関与するころには、Expansionの窓は狭まっています。
必要なこと：CSプラットフォームでの定義されたExpansionシグナル基準（利用閾値、エンゲージメントイベント、QBR成果）が、CRMタスクの作成またはOpportunityの自動作成をトリガーするよう設定されること。これは、ほとんどのチームが概念的な作業は行うものの、技術的な設定を完了しないインテグレーションポイントです。
正直なシグナルとしての請求と製品利用データ
CRMデータはSales形成されています：AEがアカウントについて語った物語を反映しています。CSプラットフォームのデータはCSM形成されています：CSMが割り当てたHealth Scoreを反映しており、それは現実に遅れをとるか、難しいアカウントに対するCSMの楽観主義を反映しているかもしれません。どちらも有用ですが、どちらも完全に客観的ではありません。
製品利用データは嘘をつきません。顧客が製品で実際に何をしているかを反映しています。どのシートがアクティブか、どの機能が使用されているか、どのWorkflowが設定されて放棄されたか、そして採用軌跡が月ごとにどのように見えるか。Bainの2024年のカスタマーサクセスに関するレポートは、CSへの投資が増えているにもかかわらず、ソフトウェア企業の75%でネット収益維持率（NRR）が低下していることを明らかにしました。その理由は、ほとんどのCSチームが、利用データが提供する正直なシグナルにアクセスできていないことにあります。
請求データは財務的な精度を加えます：CSプラットフォームが更新される前にダウングレード要求が処理中かどうか、利用状況がExpansionを示すティアアップグレードに向かっているかどうか、支払いが最新かどうか。
このデータをNRRの共同予測に早期に組み込んでいる企業は、Renewalにおいて構造的な優位性を構築します。シグナルは客観的で継続的に更新され、どのように表現するかを人間が決定する必要がありません。
実際には：これは通常、製品データベースまたは請求システムをCRMまたはCSプラットフォーム（あるいはその両方）に接続し、各チームに表示される特定のメトリクスを定義することを意味します。RevOpsまたはエンジニアリングが担当しますが、CSプラットフォームの購入前のスタック評価チェックリストに含めるべきです。どのインテグレーションポイントが最も重要かは、セグメントによって異なります。次のセクションでそれを直接取り上げます。
単一顧客レコードの目標
目標は単一のシステムではありません。共有されたビューです。
SalesはいつもCRMで主に働きたいと思うでしょう。CSはいつもCSプラットフォームで主に働きたいと思うでしょう。それで構いません。各システムはそのチームのWorkflowのために構築されています。目標は、各チームが顧客について必要とするデータが、実際に使用するシステムで確認でき、アクションを起こせる頻度で更新されていることを確保することです。
各チームへの実際の意味：
AEがCRMで必要なもの：
- 現在のHealth Scoreとトレンド（CSプラットフォームから）
- RenewalリスクティアとRenewalまでの日数
- Expansionフラグ（CSはExpansion準備状況を見ているか？）
- CSMの最後の顧客コンタクト日
- 商業的リスクとしてフラグが立てられたオープンなサポートエスカレーション
CSMがCSプラットフォームで必要なもの：
- 元のディールノートと行われた約束
- AEの最後のエグゼクティブコンタクト日
- セールスプロセスからの競合コンテキスト
- AEが取り組んでいるオープンなExpansion Pipeline（CSMがそれを損なわないように）
- Renewal会話に対するAEの商業的権限
共有顧客レコードアーキテクチャの記事は、具体的なデータモデルの決定についてより詳しく説明しています。ここでの原則は：各チームが相手から必要とするものを定義し、次にそれを提供するインテグレーションを構築する。その逆ではありません。
よくある失敗パターン
これらは、スタックが正しく配線されていない場合に最もよく見られるパターンです。
重複したコンタクトによる相反するアウトリーチ。 CRMには経済的な購買担当者のコンタクトレコードがあります。CSプラットフォームには日々のユーザーのための別のコンタクトレコードがあります。どちらも相手にリンクされていません。二つのアウトリーチシーケンスが同時に実行されます。顧客は同じ週にAEとCSMから異なるトピックについて連絡を受けます。これはインテグレーションの問題です：コンタクトはCRMとCSプラットフォームの間で、アカウントレベルだけでなく、個人レベルで双方向に同期しなければなりません。また、成約時にコンタクトデータがきれいに移転されない、成約からOnboardingへのハンドオフプロセスが壊れていることの症状でもあります。
CSが更新するがSalesが見ることのないHealth Score。 CSMは3週間前にアカウントをグリーンからレッドにダウングレードしました。AEはちょうどExpansionの見積もりを出しました。顧客は混乱しています。なぜセールスチームが、自分たちがCSに去ることを告げたアカウントをExpansionしようとしているのか？これはインテグレーションポイント2の失敗です：Health Scoreの変更がCRMに表面化していません。
SlackまたはAEの頭の中にあるディールノート。 AEのノートがCRMに記録されなかったため、CSMはディールコンテキストなしでアカウントをOnboardingします。CSMは6ヶ月後に製品が過剰に販売されたことを発見します。その時点で、顧客はすでに印象を形成しています。これは始まる前からインテグレーションポイント1が失敗しています：技術的なインテグレーションの問題ではなく、CRMステージゲートの問題です。
豊かだがアクションが取られないRevenue Intelligenceサマリー。 Revenue Intelligenceプラットフォームには、競合の言及、反論テーマ、Healthシグナルを含むすべての顧客通話のトランスクリプトがあります。CSはアクセスできません。インサイトはマーケティングに届きません。競合データは製品に反映されません。プラットフォームはセールスコーチングツールであり、それ以外の何物でもありません。解決策はアクセスとWorkflowであり、技術ではありません。しかし、CROがデプロイメント要件としてマーケティングとCSのアクセスを義務付ける必要があります。Revenue Intelligenceは、Salesメッセージングへ戻る顧客の声のフィードバックループと組み合わせたときに、特に価値を発揮します。
CSプラットフォームで死ぬExpansionシグナル。 AEのアウトリーチをトリガーすべき利用閾値がCSプラットフォームで発火します。CSMがそれに気づきます。CRMには自動タスクがありません。CSMはAEにSlackメッセージを送ります。AEはQBR中です。3日が過ぎます。Expansionの窓が狭まります。これはインテグレーションポイント3の失敗です：シグナルはキャプチャされたがアクションに変換されませんでした。
RevOpsとCROのための5つの質問診断
これらの質問を使って、現在のスタックがセームでアラインメントを生み出しているか、それとも摩擦を生み出しているかを評価しましょう。
1. AEは、CRMを離れたりCSMに聞いたりすることなく、自分のアカウントの現在のHealth ScoreとRenewalリスクティアを確認できるか？ できない場合、インテグレーションポイント2は不完全です。
2. ディールが成約した時、CSMはユースケース、行われた約束、ICP適合スコア、ステークホルダーマップを含む構造化されたディールコンテキストのパッケージを自動的に受け取るか、それともAEに聞く必要があるか？ 後者の場合、インテグレーションポイント1は不完全です。
3. CSプラットフォームのデータがExpansionシグナルを示した時、自動的にCRMにAEのタスクやOpportunityが作成されるか？ されない場合、インテグレーションポイント3は不完全です。
4. CSチームはRevenue Intelligenceの会話データにアクセスできるか。セールスコーチングのクリップだけでなく、競合の言及や反論テーマのキーワードアラートも含めて？ できない場合、Revenue Intelligenceプラットフォームは十分に活用されておらず、CSチームは競合ダイナミクスについて部分的に盲目的です。
5. AEとCSMは同じアカウントに対して一貫したコンタクトレコードを持ち、CRMとCSプラットフォームの間で個人レベルで双方向に同期しているか？ していない場合、相反するアウトリーチの失敗パターンがスタックに存在し、顧客はすでにそれを体験しているかもしれません。
構築 vs. インテグレーション vs. 置き換え
診断でギャップが明らかになった場合、通常は3つのオプションのいずれかになります。
既存のインテグレーションを設定する： 主要なCRMとCSプラットフォームの組み合わせのほとんどは、上述の3つのインテグレーションポイントを部分的または完全にカバーするネイティブインテグレーションまたはファーストパーティコネクターを持っています。ミドルウェアを購入したりカスタムコネクターを構築したりする前に、ネイティブインテグレーションが上述のデータフローを提供するよう設定されているかを監査しましょう。多くの場合そうなっていませんが、設定は構築よりも安価です。
カスタム同期を構築する： ネイティブインテグレーションが必要な特定のデータフローをサポートしていない場合（請求/利用データには通常ネイティブコネクターがなく、これが一般的なケースです）、カスタムAPIインテグレーションが必要になります。エンジニアリングが構築し、RevOpsがデータモデルとフィールドマッピングを定義します。これは通常、インテグレーションポイント3（ExpansionシグナルからCRMタスク作成）と利用/請求データの配線に適切なパスです。
カテゴリツールを置き換える： インテグレーションのギャップが理由でカテゴリツールを置き換えることは最後の手段であるべきです。間違っているからではなく、遅くて混乱を招くからです。インテグレーションのギャップがツールのアーキテクチャに根本的な場合（一部の旧来のCSプラットフォームは双方向同期を構造的に困難にするクローズドAPIを持っています）、またはツールがサポート終了（EOL）に達した場合に置き換えましょう。そうでなければ、まず設定と構築を試みましょう。
引用可能なポイント： CRMとCSプラットフォームの間でアカウントレベルのリアルタイム双方向データ共有ができているB2B SaaS企業はわずか26%であり、つまり74%のレベニューチームが、同じ顧客について二つの異なる情報を元に動いています（Gainsight、2024年）。
引用可能なポイント： Revenue Intelligenceプラットフォームは、61%の導入でセールスコーチングを主な用途として使われており、CSチームは、投資の主な根拠だった競合シグナル、反論テーマ、顧客の会話データにアクセスできません（Gong社内調査、2024年）。
引用可能なポイント： 製品利用データを更新予測に組み込んでいる企業は、CSMが割り当てたヘルススコアのみに頼る企業よりもNRRが18%高くなります。利用データには楽観バイアスがありませんが、ヘルススコアにはあります（Totango調査、2024年）。
インテグレーションの要件はRevOpsの責任
アラインメントスタックはインテグレーションが機能する時にのみ価値を提供します。そしてインテグレーションは誰かがそれを所有する時にのみ機能します。
RevOpsがセームでのインテグレーション・アーキテクチャを担当します。Sales Opsではありません（SalesのユースケースのためにそれをビルドしてCSが必要なデータを取得できません）。CS Opsでもありません（逆の問題が起きます）。VP SalesとVP CS両方からの明示的な要件インプットを持つRevOpsが担当します。
まだRevOps機能がない場合、インテグレーション作業が最初に採用または委託すべきものです。部分的に接続された二つのシステムは、多くの場合、一つのクリーンなシステムよりも悪いものです。共有されたビューの幻想を作り出しながら、実際にはギャップを隠しているからです。これらをまとめるファンクションとしてのRevOpsについては、マーケティングと営業のアラインメントコレクションのアラインメントをつなぐ接着剤としてのRevOpsモデルで詳しく説明しています。その原則は、Sales-CSのセームでも同様に当てはまります。
アラインドスタックに関するよくある質問
3-Layerアラインド・レベニュー・スタックとは何ですか？
3-Layerアラインド・レベニュー・スタックは、Sales-CSのセームにまたがる3つのツールカテゴリのための、ベンダー中立のアーキテクチャフレームワークです。CRM（ディールとSalesアクティビティの基幹レコードシステム）、CSプラットフォーム（成約後のHealthの基幹レコードシステム）、そしてRevenue Intelligence（両チームにまたがる会話シグナル）です。第4の構成要素（請求と製品利用データ）は、どちらのチームも割り当てたり調整したりできない正直なシグナルとして、両方のレイヤーに客観的に供給されます。このフレームワークは、特定のベンダーや製品ではなく、インテグレーション・アーキテクチャに焦点を当てています。
すべてのレベニューチームに必要な3つのセームのインテグレーションポイントとは何ですか？
インテグレーションポイント1は、成約時にCRMからCSプラットフォームへ流れるディールコンテキストで、CSMが空白のアカウントではなく、完全なセールスストーリー（ユースケース、約束、ICP適合、競合コンテキスト）からスタートできるようにします。インテグレーションポイント2は、CRMに表面化するHealth ScoreとRenewalリスクで、AEがCSプラットフォームにログインしたりCSMに聞いたりせずにアカウントのHealthを確認できるようにします。インテグレーションポイント3は、CSプラットフォームからのExpansionシグナルが、AEのためにCRMでタスクやOpportunityを自動作成するもので、Slackメッセージを待つ間にExpansionの窓が失われることがなくなります。
カスタムインテグレーションを構築すべきですか、それとも既存のものを設定すべきですか？
まず設定しましょう。主要なCRMとCSプラットフォームの組み合わせのほとんどは、3つのセームのインテグレーションポイントを部分的または完全にカバーするネイティブインテグレーションまたはファーストパーティコネクターを持っていますが、ここで説明した特定のデータフローを提供するよう設定されていないことがよくあります。設定は構築よりも速く安価です。ネイティブインテグレーションが必要な特定のデータフローをサポートしていない場合（最も一般的なのは請求/利用データの配線）にのみ、カスタム接続を構築します。カテゴリツールの置き換えは、インテグレーションのギャップがツールのアーキテクチャ自体に構造的な場合にのみ行い、設定の問題に対する最初の対応としては行いません。
3-Layerアラインド・レベニュー・スタックはSMBとエンタープライズでどのように適用されますか？
SMBでは、Expansionモーションが通常小さく、インテグレーションポイント3の調整オーバーヘッドが価値を上回る場合があるため、優先事項はインテグレーションポイント1（成約時のディールコンテキスト）とインテグレーションポイント2（CRMのHealth Score）です。エンタープライズでは、Expansionが重要な収益ラインであり、Expansionシグナルを逃すコストが高いため、3つのインテグレーションポイントすべてが重要です。請求と製品利用のレイヤーは、あらゆる規模で価値があります。Health Scoreやパイプラインデータでは得られない正直なシグナルを提供するからです。
アラインドスタックでRevOpsは何を担当しますか？
RevOpsはセームでのインテグレーション・アーキテクチャを担当します。Sales Ops（Salesのユースケースのために構築する）でもCS Ops（CSのユースケースのために構築する）でもありません。RevOpsは3つのインテグレーションポイントすべてのフィールドマッピングと同期ケイデンスを定義し、インテグレーションポイント1を機能させるCRMステージゲートの衛生管理を徹底し、インテグレーションポイント3を駆動するCSプラットフォームのExpansionシグナルトリガーを設定します。CROまたはVP SalesとVP CSの共同のインプットが各チームの必要なデータを定義し、RevOpsがそれを技術的な設定に落とし込みます。
スタックが正しく配線されていない場合、最もよくある失敗パターンは何ですか？
最も一般的な5つの失敗パターンは次のとおりです。(1) 重複したコンタクトによって、AEとCSMが同じ顧客に相反するアウトリーチを行う。(2) CSが更新したHealth Scoreのダウングレードを、AEがCRMで見ることがない。(3) ディールノートがCRMではなくSlackやAEの記憶の中にあり、CSMが空白のアカウントをOnboardingすることになる。(4) 会話データが豊富なRevenue Intelligenceが、CSではなくSalesだけに公開されている。(5) CSプラットフォームで発火したExpansionシグナルが、AEのCRMタスクに変換されず、タイミングのずれでExpansion ARRを失う。
詳細を見る
Principal Solution Architect