重複レコード管理: RevOpsがCRMの分断をどう防ぐか

重複レコードは、単にCRMを雑然と見せるだけではありません。

それらは顧客の真実を分断します。あるアカウントには営業活動があります。別のアカウントには更新リスクがあります。3つ目のアカウントには請求担当者がいます。すでに会社がパイプラインに入っているにもかかわらず、リードがアカウントの外に存在しています。マーケティングは3人としてカウントします。営業は2人のオーナーを見ます。カスタマーサクセスは履歴を見逃します。

そして収益システムは、断片化されたコンテキストから意思決定を始めてしまいます。

重複レコード管理とは、アカウント、コンタクト、リード、商談のデータを1つの運用上の実態に結びつけておくために、RevOpsが行う取り組みです。これは単なるクリーンアップ作業ではありません。ルーティング、スコアリング、レポート、オーナーシップ、引き継ぎ、顧客体験、収益への信頼のための管理システムです。

ForresterのRevOpsテクノロジー連携に関する調査は、重複が収益エンジン全体にわたってルーティング、レポート、自動化、顧客コンテキストに影響するため関連性があります。ForresterのRevOps責任モデルも、重複ポリシーが機能を横断すべき理由を裏づけています。

運用上の重要事実

• 重複はレコードの雑然さではありません。顧客のコンテキストを分断します。
• アカウントの重複は、パイプライン、請求、更新、オーナーシップに関わるため、通常コンタクトの重複よりも大きなリスクを伴います。
• マージルールは、クリーンアップが始まる前に文書化されるべきです。
• インポート、コンバージョン、エンリッチメント、インテグレーションの管理策は、一度きりの重複排除プロジェクトよりも重要です。
• 重複作成率の低下は、マージ件数の多さよりも強いシグナルです。

重複レコードが収益上の問題である理由

重複レコードは5つの方法で運用上のダメージを生みます。

最もコストのかかる重複は、必ずしも分かりやすいものとは限りません。オープンなパイプラインのないアカウントの重複でも、更新のコンタクト、サポート履歴、請求関係、ソースアトリビューションを持っている場合、依然として危険です。

だからこそ重複管理は、CRMデータ衛生やCRMフィールドガバナンスと同じ運用レイヤーに属します。重複排除の取り組みは、その背後にあるフィールド、ワークフロー、オーナーシップのルールが明確なときにのみ持続可能です。

主な重複タイプ

RevOpsは、ルールを選ぶ前に重複のタイプを定義すべきです。

異なる重複タイプには、異なる検出シグナル、ビジネスオーナー、マージの判断が必要です。

リードとコンタクトの重複

新しいリードが、すでにコンタクトとして存在する人物であるにもかかわらず、フォーム経由で入ってきます。システムがマッチングしなければ、アカウントオーナーがすでにその関係を持っているのに、その人物は新しいリードとしてルーティングされるかもしれません。

これは次の場合によく起こります。

• 既知のコンタクトが個人用メールアドレスを使う
• コンタクトが異なるドメインで新しいフォームを送信する
• マーケティングオートメーションがCRMのコンタクトを確認せずにリードを作成する
• リードコンバージョンのルールが不完全である
• 重複検出が完全一致のメールのみをチェックしている

リードとコンタクトの重複は、ルーティングと対応に影響します。すでに営業と会話中の人物が、まったく新しいインバウンドリードのように扱われると、気まずい顧客体験を生むこともあります。

コンタクトの重複

メールのばらつき、インポート履歴、エンリッチメント、手動作成のために、同一人物が2回存在します。

コンタクトの重複はアクティビティ履歴を分断します。あるレコードにはウェビナー参加履歴があります。別のレコードには営業メールがあります。また別のレコードにはサポートメモがあります。マーケティング、営業、カスタマーサクセスがそれぞれ異なるバージョンを見ると、チームは関係性の記憶を失います。

コンタクトのマージポリシーは次を保持すべきです。

• 検証済みの business メールアドレス
• 有用な場合の代替メールアドレス
• 同意とサブスクリプションのステータス
• アクティビティ履歴
• キャンペーン履歴
• アカウントとの関係
• コンタクトの役割

コンタクトの重複はアカウントの重複よりもマージしやすいことが多いですが、それでもフィールド生存ルールが必要です。

アカウントの重複

命名の違い、ドメイン、子会社、地域、レガシーインポート、請求構造のために、同じ会社が複数のアカウントとして存在します。

アカウントの重複は、ほとんどのB2Bチームにとって最もリスクの高い重複タイプです。次に影響します。

• パイプライン
• 予測
• テリトリーのオーナーシップ
• アカウントベースドマーケティング
• 顧客ヘルス
• 更新リスク
• 請求と契約
• サポート履歴
• 経営陣向けレポート

ビジネスレビューなしにアカウントレコードをマージすると、何年にもわたってコンテキストを損なう可能性があります。

商談の重複

2つの商談が同じ購買行動を表しています。

商談の重複はパイプラインを水増しし、予測を混乱させ、マネージャーの点検を難しくします。これは、複数のレップが同じアカウントの異なるコンタクトに対応している場合、更新が拡大と混同されている場合、あるいはインバウンドリクエストがアクティブな案件がある中で2つ目の商談を作成してしまう場合によく起こります。

商談の重複は、意思決定が単なる技術的なものではないため、営業マネージャーのレビューが必要です。マネージャーは、本当に2つの購買行動があるのか、それとも1つの案件が断片化しただけなのかを判断する必要があります。

システム横断の重複

CRM、マーケティングオートメーションプラットフォーム、カスタマーサクセスプラットフォーム、請求システム、データウェアハウスは、それぞれ同じ顧客を異なる形で表しているかもしれません。

これらの重複は、1つのシステムの内部からは見えないことがあります。

例: CRMは「Acme」を使い、請求は「Acme LLC」を使い、カスタマーサクセスは「Acme North America」を使い、データウェアハウスはプロダクト利用状況を「acme.com」にマッピングしています。それぞれのレコードは各システム内では正当かもしれませんが、共有の識別モデルなしには、収益チームはその顧客を照合できません。

システム横断の重複は、単なるCRMクリーンアップの問題ではなく、信頼できる収益データの情報源の問題です。

マッチングポリシーを構築する

重複管理はマッチングルールから始まります。

一般的なマッチングシグナル:

• メールアドレス
• メールドメイン
• 会社のウェブサイト
• 会社名
• 電話番号
• LinkedInプロフィール
• 請求ドメイン
• アカウントオーナー
• 国または地域
• 親アカウント
• 利用可能な場合の納税者番号や顧客ID

それぞれのシグナルには限界があります。メールは個人には強力ですが、人々がエイリアスを使う場合には弱くなります。ドメインはB2Bアカウントには有用ですが、コングロマリット、代理店、大学、リセラー、複数ブランドを持つ会社には弱くなります。会社名は必要ですが、表記や法人格の違いがノイズを生みます。

信頼度レベルを使いましょう。

重要なレコードについて、あいまいなマッチングを自動マージにしないでください。まずフラグを立て、それからレビューします。

オブジェクトごとに異なる方法でマッチングする

マッチングポリシーは、すべてのオブジェクトに1つのルールを使うべきではありません。

この区別が重要なのは、コンタクトの誤ったマージは煩わしい程度ですが、アカウントの誤ったマージはパイプライン、更新、請求、過去のレポートを損なう可能性があるからです。

クリーンアップの前にマージルールを定義する

レコードのマージは、単に重複を削除することではありません。

RevOpsにはフィールド生存ポリシーが必要です。レコードが競合したとき、どの値が残るのか。

例:

• アカウントオーナー: 最も古いオーナーではなく、アクティブなオーナーを残す。
• リードソース: 元のソースを保持し、最新のソースは別に保存する。
• ライフサイクルステージ: 最も進んだ有効なステージを残す。
• 顧客ステータス: 請求またはサブスクリプションシステムが優先されるかもしれない。
• コンタクトのメール: 検証済みのビジネスメールを残す。
• アクティビティ履歴: 可能な限りすべてのアクティビティを保持する。
• メモ: 上書きせず追記または保持する。
• 同意: 最も制限的で有効な同意ステータスを残す。
• 予測カテゴリー: マネージャーが承認した現在の値を残す。

マージルールが不明瞭だと、クリーンアップがコンテキストを破壊しかねません。

フィールド生存表を使う

高リスクのマージには、フィールド生存表が推測を防ぎます。

この表は、クリーンアップスプリントが始まる前に存在すべきです。そうでなければ、マージのたびに新しい議論が生まれます。

入力時点で重複を防ぐ

最良の重複プログラムは、重複がCRMに入る前にそれを防ぎます。

管理策には次が含まれます。

• 既存のコンタクトに対するフォームマッチング
• リード作成前のアカウントドメインマッチング
• インポートのバリデーション
• アカウント作成のためのドメインまたは会社ウェブサイトの必須化
• 手動レコード作成時の重複警告
• リードとアカウントのマッチング
• アカウント階層のルール
• 上書き前のエンリッチメントレビュー
• 既知のコンタクトのコンバージョンルール

予防が重要なのは、クリーンアップだけでは重複を作り続けるシステムに追いつけないからです。

フォームキャプチャを管理する

人々が常に同じメールアドレスや会社名で送信するとは限らないため、フォームは多くの重複を生み出します。

良いフォームキャプチャのプロセスは次を行うべきです。

• メール形式のバリデーション
• 適切な場合の会社ウェブサイトまたはドメインの取得
• 元のソースの保持
• 新しいリード作成の前に既知のコンタクトとマッチさせる
• アカウントマッチングのために個人メールをフラグする
• すべての会社名のバリエーションから新しいアカウントを作らないようにする
• 不確実なマッチをレビューにルーティングする

これは、デモリクエスト、価格リクエスト、営業への問い合わせ、パートナーからの問い合わせ、カスタマーサポートリクエストといった、意欲の高いフォームで特に重要です。

インポートを管理する

インポートは、数分で数千件の重複を生み出す可能性があります。

すべてのリストアップロードの前に、次を必須にします。

• インポートのオーナー
• リストのソース
• インポートの目的
• フィールドマッピング
• 重複チェック
• 既存レコードの更新ルール
• 必要に応じた同意またはコンプライアンスに関するメモ
• エラー時のロールバック計画

「純増の新規名簿」だけをインポートの目標にしないでください。重複を生むリストは、キャンペーンのボリュームを良く見せながら、収益システムを弱めてしまう可能性があります。

エンリッチメントを管理する

エンリッチメントはレコードのマッチングに役立ちますが、誤ったマッチも生み出す可能性があります。

よくあるエンリッチメント起因の重複問題:

• 汎用的な会社ドメインが誤ったアカウントにマッピングされる
• 営業の合意なしに子会社が親アカウントにマージされる
• コンタクトの役職が古いデータで上書きされる
• アカウント名が正規化された結果、既存の階層が壊れる
• 個人メールが誤った会社にマッチする

エンリッチメントは、疑いのない権威としてではなく、シグナルとして使いましょう。

インテグレーションを管理する

システムが識別について合意しない場合、インテグレーションは重複を生み出します。

接続されているすべてのシステムについて、次を文書化します。

• どのレコードを作成できるか
• どのレコードを更新できるか
• どのフィールドを上書きできるか
• どのマッチングキーを使うか
• マッチが見つからない場合どうなるか
• 同期エラーは誰が担当するか

これは収益オペレーションのシステムオブレコード設計に属します。システムが識別について合意しなければ、重複のクリーンアップは長続きしません。

アカウントの重複は慎重に扱う

アカウントの重複は、商談、契約、チケット、請求、プロダクト利用状況、カスタマーサクセスのワークフローにしばしば結びついているため、特別な注意に値します。

アカウントレコードをマージする前に、次を点検します。

• オープンな商談
• クローズウォンの履歴
• 更新日
• 請求関係
• 顧客ステータス
• 親アカウントまたは子アカウント
• アカウントオーナー
• サポートチケット
• カスタマーサクセスのヘルス
• アクティブなシーケンスまたはキャンペーン
• プロダクト利用データ
• 契約主体

戦略的アカウントについては、人によるレビューを必須にします。誤ったマージは、何年にもわたってレポートと顧客コンテキストを損なう可能性があります。

マージすべきでない場合を判断する

重複のように見えても、別々のままにすべきレコードもあります。

例:

• 異なる購買チームを持つ親会社と子会社
• グローバルアカウントと地域の事業単位
• パートナーレコードとエンドカスタマーレコード
• 代理店とクライアントアカウント
• 同じ会社の似た名前を持つ2人のコンタクト
• 異なるプロダクトや部門のための別々の商談
• 請求に両方が必要な法人と ブランド主体

強力な重複プログラムには「マージしない」というポリシーが含まれます。そのポリシーは、マージポリシーと同じくらい重要です。

アカウント階層を管理する

一部の重複問題は、実際には階層の問題です。

大規模なアカウントには次が必要かもしれません。

• グローバル親アカウント
• 地域の子アカウント
• 子会社アカウント
• 請求主体
• パートナーとの関係
• 購買センター
• プロダクトライン別の商談

RevOpsがすべての関連する主体を1つのアカウントレコードに無理やり押し込もうとすると、CRMは整然と見える一方で運用モデルは悪化するかもしれません。

問うべきは「これらのアカウントはマージできるか」ではありません。より良い問いは「営業、カスタマーサクセス、財務、レポーティングがすべて機能するために、これらのアカウントはどんな関係を持つべきか」です。

重複を運用ケイデンスとしてレビューする

重複のクリーンアップは、四半期ごとのパニックを待つべきではありません。

週次レビューは、アクティブなリスクに焦点を当てるべきです。

• 信頼度の高い新しい重複リード
• オープンな商談を持つ重複アカウント
• アクティブなシーケンスにある重複コンタクト
• 現在の予測にある重複商談

月次レビューは、パターンを点検すべきです。

• ソース別の重複率
• インポート別の重複率
• インテグレーション別の重複率
• 地域またはセグメント別の重複率
• マージエラー
• マッチングなしに手動作成されたレコード

四半期レビューは、ポリシーを更新すべきです。

• マッチングの閾値
• フィールド生存ルール
• アカウント階層の標準
• インポートルール
• エンリッチメントポリシー
• 管理者権限

重複はシステムの振る舞いです。レコードだけでなく、システムをレビューしてください。

重複スコアカード

有用なスコアカードには次が含まれます。

• オブジェクト別の重複率
• 週ごとに新しく作られた重複
• 週ごとにマージされた重複
• 重複のソース
• 重複レビューにかかる平均時間
• オープンパイプラインを持つ重複アカウント
• アクティブなキャンペーンにある重複コンタクト
• マージエラー率
• インポート時にブロックされたレコード
• 戦略的アカウントの重複バックログ

最も重要な指標は、RevOpsが何件の重複をマージしたかではありません。重複の作成が減っているかどうかです。

重複レビューキューを構築する

重複管理は、散在するレポートに留まるのではなく、リスクのあるレコードがレビューキューに流れ込むときにより良く機能します。

そのキューは次を示すべきです。

• 重複タイプ
• 信頼度レベル
• 影響を受けるオブジェクト
• 作成のソース
• オーナー
• パイプラインまたは顧客ステータス
• 最終活動日
• 推奨されるアクション
• レビュー担当者
• SLA

これにより、RevOpsは緊急の重複リスクを通常のクリーンアップから切り分けられます。

このキューはCRM管理者だけが所有すべきではありません。RevOpsがキューを運用できますが、あいまいなレコードはビジネスオーナーが解決すべきです。

マージ前にトリアージする

すべての重複が即座の対応に値するわけではありません。

トリアージを使います。

1. アクティブなパイプラインや顧客ステータスはあるか? あればマージ前にレビューする。
2. 請求、契約、同意のデータはあるか? あればそのデータのオーナーを関与させる。
3. マッチは高信頼度か? そうでなければ自動でマージしない。
4. ソースやアクティビティ履歴に影響するか? あればマージ前に保持する。
5. これらのレコードは重複ではなく階層を表しているか? そうであればマージではなく関係性を作る。

トリアージは、速度と安全性を同時に守ります。リスクの低い個人の重複は素早く進められます。戦略的アカウントの重複は、ビジネスコンテキストが明確になるまでペースを落とすべきです。

ソース別にスコアカードを読む

重複の合計は有用ですが、ソースレベルの分析の方が優れています。

これにより、RevOpsは予防をどこで改善すべきかが分かります。

実践的なクリーンアップスプリント

クリーンアップは段階的に行います。

1. オブジェクトとリスクで重複をセグメント化する。
2. 信頼度の高い個人の重複から始める。
3. オープン商談を持つアカウントの重複は別途レビューする。
4. 戦略的アカウントに触れる前にマージルールを定義する。
5. ソースとアクティビティ履歴を保持する。
6. 未解決のあいまいなレコードを追跡する。
7. 重複がどう入り込んだかを特定する。
8. 予防の管理策を追加する。

クリーンアップスプリントは、重複がマージされた時点で終わりではありません。RevOpsが何がそれを生み出したか、そして再発を防ぐために何を変えたかを説明できたときに終わります。

例: オープンパイプラインを持つ重複アカウント

Acme Inc.が2つのアカウントとして存在すると仮定します。1つのレコードにはオープンな商談があります。もう1つには3人のコンタクト、過去のミーティングメモ、以前のパイロットからのカスタマーサクセスリスクのメモがあります。

単純なマージは明白に見えるかもしれませんが、RevOpsは行動を起こす前に、オーナーシップ、商談履歴、ソースフィールド、アクティビティ、アカウント階層を点検すべきです。誤ったレコードが残れば、チームはアトリビューションや過去のコンテキストを失うかもしれません。商談のオーナーが静かに変わってしまうと、営業マネージャーは可視性を失うかもしれません。

クリーンアップの判断には、システム管理者だけでなくビジネスオーナーも含めるべきです。

例: 既存アカウントからの重複リード

既存のターゲットアカウントのVPが、個人メールアドレスでデモフォームを送信します。CRMがそのレコードをマッチさせなければ、そのリードは標準的なインバウンドキューに入るかもしれません。新しいレップがフォローアップする一方で、指名されたアカウントオーナーはすでにアクティブな商談を持っています。

これは単なる重複問題ではありません。ルーティング、アカウントオーナーシップ、顧客体験の問題です。

予防には、ドメインマッチング、個人メールの扱い、リードとアカウントのマッチング、戦略的アカウントのための例外経路が必要かもしれません。インバウンドの量が多いチームにとって、これはリードルーティングの自動化に結びつくべきです。ルーティングロジックは、その前段にある識別ロジックと同じくらいの質しか持てないからです。

例: 商談の重複

既存の顧客が2つ目のプロダクトについて問い合わせます。あるAEが拡大商談を作成します。あるCSMは同じ購買行動を更新拡大として記録します。マーケティングの影響は1つの商談に付きますが、予測は両方を表示します。

CRMは今や現実よりも多くのパイプラインを示しています。

修正策は盲目的なマージではありません。営業マネージャーは、これが1つの購買行動なのか、2つの購買行動なのか、あるいは拡大を伴う更新なのかを判断すべきです。RevOpsはアクティビティとソースのコンテキストを保持し、その分断を許したオポチュニティ作成ルールを更新すべきです。

商談の重複クリーンアップは、特にインバウンドの需要が既存アカウントのためのパイプラインを生む場合、リードから商談へのプロセスに結びつけるべきです。

例: システム横断の顧客重複

ある顧客は、CRMでは「Northstar Health」、請求では「Northstar Health LLC」、カスタマーサクセスでは「Northstar Enterprise」として存在します。

それぞれのシステムは局所的には機能します。しかし経営陣向けダッシュボードは、手動でのマッピングなしに受注、更新リスク、プロダクト利用状況を照合できません。

これは通常のCRMマージではありません。顧客の識別の問題です。RevOpsには、共有の顧客キー、システムのオーナーシップ、法人格、アカウント階層、レポート主体に関する意思決定のためのプロセスが必要です。

ライフサイクルステージ別の重複管理

重複のリスクはライフサイクル全体で変化します。

これが、重複管理が単なる管理者のクリーンアップではなく、RevOpsの運用モデルに属する理由です。

文書化すべきポリシー上の判断

RevOpsは難しい判断を文書化すべきです。

• リードは既存のコンタクトに自動コンバートできるか
• 異なるメールを持つコンタクトはマージできるか
• 戦略的アカウントのマージは誰が承認するか
• 顧客ステータスはどのシステムが優先されるか
• 子会社はどう扱われるか
• 地域のアカウントは別レコードか子アカウントか
• マージ後にソース履歴はどうなるか
• マージのミスは誰がレビューするか
• 上書き前にビジネス承認が必要なフィールドはどれか

これらの判断があれば、クリーンアップスプリントのたびに一からやり直す必要がなくなります。

重複ガバナンスの役割

重複管理には明確な役割が必要です。

RevOpsは重複ポリシー、マッチングの閾値、マージのワークフロー、スコアカードを所有すべきです。営業マネージャーはあいまいなオーナーシップの競合を判断すべきです。マーケティングオペレーションは、アトリビューションに影響するマージの前にリードソースとキャンペーン履歴をレビューすべきです。カスタマーサクセスは、アカウントマージの前にアクティブな顧客アカウントをレビューすべきです。サブスクリプションまたは請求データが関わる場合、財務は顧客と請求のレコードをレビューすべきです。

システム管理者だけにすべてのビジネス上の意思決定を強いるべきではありません。管理者はレコードをマージできます。しかし、どの顧客履歴、オーナー、ソースの値が残るべきかを常に決められるわけではありません。

マージ監査証跡

高リスクのマージには監査証跡を残すべきです。

次を記録します。

• マージされたレコード
• 承認者
• 理由
• 残ったオーナー
• フィールド生存の判断
• ソースの保持
• 日付
• 下流で生じた問題

これは形式だけの事務作業ではありません。マージがレポートの問題を生んだとき、RevOpsは何が変わり、なぜそうなったかを知る必要があります。

よくある重複管理の間違い

積極的すぎる自動マージ。 速すぎるクリーンアップはコンテキストを破壊しかねません。

ソースシステムを無視する。 インポートやインテグレーションから重複が繰り返し発生します。

フィールド生存ルールがない。 マージの判断が一貫しなくなります。

すべての重複を同じように扱う。 戦略的アカウントの重複は、ウェビナーリードの重複と同じではありません。

予防なしのクリーンアップ。 同じ問題が翌月また発生します。

あいまいな重複にオーナーがいない。 誰も判断できないため、リスクのあるレコードが未解決のまま放置されます。

マージの判断に階層を無理やり当てはめる。 親、子、子会社、パートナー、請求主体は、1つのレコードではなく関係性を必要とするかもしれません。

マージ量だけを測定する。 マージ件数が多くても、重複の作成がまだ増え続けているという事実を隠してしまうことがあります。

良い状態とはどのようなものか

良い重複管理は、CRMをより落ち着いたものにします。

レップは1つのアカウントを見ます。マネージャーは1つのパイプラインを点検します。マーケティングの影響は正しいレコードに積み上がります。カスタマーサクセスは完全な履歴を得ます。財務は重複した顧客名を照合する必要がありません。自動化は正しいコンテキストから発火します。

顧客は同じ関係性を二度説明する必要がありません。

良い重複管理は、時間とともに例外も減らします。重複のバックログは縮小しますが、さらに重要なのは、重複の作成率が下がることです。それは、キャプチャ、インポート、マッチング、階層、システムのオーナーシップがともに改善していることを意味します。

重複管理成熟度モデル

ほとんどのチームは、インポート、リードコンバージョン、アカウント作成を管理することで、クリーンアップから予防へと移行できます。識別ガバナンスへの移行はより時間がかかります。CRM、マーケティングオートメーション、請求、カスタマーサクセス、BIにまたがる整合が必要だからです。

重複解決パケット

重複のクリーンアップは、ランダムな管理作業としてではなく、統治されるべきです。

各重複カテゴリーについて、次を定義します。

• マッチングルール。
• 信頼度の閾値。
• 生存するレコードを決めるフィールド。
• 自動で上書きしてはならないフィールド。
• レビューのオーナー。
• マージ承認ルール。
• 監査ログの要件。
• ロールバックの経路。

これにより、重複のノイズを減らしながらも、アカウント履歴、アトリビューション、オーナーシップ、予測データを守れます。

FAQ

重複管理は誰が所有するのですか?

RevOpsがポリシーと運用ケイデンスを所有すべきです。システム管理者がマッチングルールを維持します。営業、マーケティング、カスタマーサクセス、財務は、ビジネスコンテキストが重要な自分たちの領域であいまいな判断を所有すべきです。

なぜ重複はそれほど有害なのですか?

重複はコンテキストを分断します。コンテキストが分断されると、そのレコードを使うすべてのワークフロー、ルーティング、スコアリング、レポート、予測、引き継ぎ、更新、顧客コミュニケーションの信頼性が下がります。

重複は自動でマージすべきですか?

はい、ただし信頼度が高くビジネスリスクが低い場合に限ります。検証済みメールを持つ完全な個人マッチは、多くのシステムで安全かもしれません。戦略的アカウント、アクティブな顧客、オープンな商談、請求レコード、同意データは通常レビューが必要です。

最良の重複指標は何ですか?

ソース別の新規重複作成率を追跡してください。マージ量はどれだけクリーンアップが行われたかを教えてくれます。作成率は、システムがより健全になっているかどうかを教えてくれます。

さらに詳しく

• 必須フィールドと有用なフィールド
• 収益データディクショナリ
• 収益プロセス監査
• RevOps指標