顧客の重複：統合前に確認すること

重複する顧客をレビューするには、まず各レコードが誰を表し、どの役割を持つかを比較し、その後、統合が必要かどうかを決定します。 販売と請求のレコードはそれぞれ正しくてもかまいません。不足しているのは、両者間の信頼できる対応関係かもしれません。

問題は、管理部門が2つの類似した履歴を見つけ、「最も完全なもの」を残すことを提案する際に発生します。あるレコードには現在の連絡先が含まれ、別のレコードには外部連携で使用される参照が含まれる場合があります。入力されたフィールドの量で選択しても、その競合は解決されません。このガイドは、変更する前にケースをレビューするためのマトリックスと意思決定ログを提供します。

ツールごとに1つのレコードで正しい場合がある

2つのシステムで表現された同じエンティティと1つのシステム内の2つの冗長なレコードを区別してください。前者のケースでは対応関係のマップが必要となる場合があり、後者のケースでは重複の発生源に関する調査が必要です。どちらのケースでも、名前だけで行を削除することは許可されません。

また、各レコードが何を表しているか（組織、連絡担当者、拠点、または取引先アカウント）も定義します。企業で働く人が、その企業の重複ではありません。運用上、2つの拠点を別々に扱う必要がある場合、それらを結合すべきではありません。

このレビューは、移行の準備（英語）に適合しますが、ツールを変更せずに使用することもできます。その結果、2つのレコードを保持し、その関係を説明することができます。

標準化する前にソースを保持する

読み取り専用のコピーで作業してください。各行について、システム、ワークスペース、レコードタイプ、元の識別子、および抽出日を保存します。CRM / W1 / account / A17 は BILL / W1 / account / A17 とは異なるものを識別します。番号を繰り返しても、それが同じ顧客であることを証明するものではありません。

元の値を保持し、スペース、大文字、または既知の名前のバリアントを比較するための補助列を作成します。エンティティを区別する可能性のある接尾辞、部門、または参照を削除しないでください。空のフィールドは「データなし」を意味し、「別の空のフィールドと一致する」という意味ではありません。

各シグナルがどこから来たのかをメモします。共通のコードは、誰がそれを割り当てたかを知っており、その対応を確認した場合により価値があります。誤ったインポートでコピーされたコードは、両方のレコードに同じエラーを伝播する可能性があります。最終編集日も、自動的に値を正しいものにするわけではありません。

3つの結果と4つのケースを持つマトリックス

以下の例は完全に架空のものです。すべてのレコードはW1スペースに属します。ORGおよびEVコードは演習参照であり、税務上の識別子や顧客データではありません。説明されている証拠は、推論を示すためだけに利用可能であると仮定しています。

架空の信頼度パーセンテージを割り当てないでください。「可能性のある」はレビューを開始するものであり、承認された統合ではありません。「曖昧な」はブロックを維持し、何が不足しているかを説明します。同じ人物・組織だと確認した後でも、何かを変更する必要があるかどうかを決定する必要があります。

レコードに注文がないからといって、それが余分であるとは限りません。最近登録されたものであるか、別の機能を果たしている可能性があります。空白のフィールドの数ではなく、証拠に基づいて分類してください。

エイリアスマップは統合を実行しない

担当者が最初のケースを解決したと仮定します。A17とB62はORG-07を表しますが、両方のツールでそのレコードが必要です。決定はそれらを保持し、対応関係を登録することです。独立したシートで、ENTITY-F07があなたの作業参照となる可能性があります。

system,workspace,record_type,source_id,entity_key,review_id
CRM,W1,account,A17,ENTITY-F07,R-01
BILL,W1,account,B62,ENTITY-F07,R-01

これらの列は、Frihetのインポート形式やコネクタへの命令ではなく、独自のテンプレートです。entity_keyは同一性を確認したレコード群をまとめ、source_idは元の参照を保持します。エイリアスは、シートに存在することによってツールを変更することはありません。

人物、企業、拠点を同じキーで平坦化しないでください。また、レビューせずに推移的に結合しないでください。AがBに似ていて、BがCに似ていても、AとCが同じであることはまだ証明されていません。

他の人がレビューできる決定を記録する

各ペアごとにこのレコードをコピーします。決定が変更された場合は、以前の提案を保持し、それを置き換える新しいバージョンを作成します。

レビュー: R-01 / バージョン 1
完全な参照: CRM/W1/account/A17; BILL/W1/account/B62
証拠: EV-01; ORG-07の対応は担当者によって確認済み
競合: 担当連絡先が異なる; EV-05で確認された有効な値
決定: 両方のレコードを保持し、ENTITY-F07の対応を登録する
レビュー担当者: ROLE-OPS
ツールでのアクション: なし
保留: コネクタがその対応をどのように使用するかをレビューする
置き換え元: 以前のレビューなし

コードは架空のものです。実際の使用では、レビューすべき人がアクセスできる証拠を参照し、不要な個人情報をシートにコピーしないようにしてください。後で変更が承認された場合は、実行者、日時、以前の参照、および観測された結果を別途記録します。「承認済み」、「実行済み」、「検証済み」は異なるステータスです。

この履歴はレビュー可能であり、元に戻すことを保証するものではありません。書面での決定を訂正しても、すでに変更されたデータが自動的に再構築されるわけではありません。

統合前にプロバイダーで確認すべきこと

動作は製品とレコードのタイプによって異なります。HubSpotは、統合は元に戻すことができず、識別子、プロパティ、および関連付けが特定のルールに従うことを文書化しています。主要としてマークしたIDが常に無傷で残るとは限りません。

Shopifyもこの操作が元に戻せないこと、および定期購入契約を持つ、または持っていた特定のプロファイルを対象外とすることを警告しています。これらの例は、Frihetや他のプロバイダーの動作を説明するものではありません。

不可逆的な操作を行う前に、以下の質問に答えてください:

• このタイプの組み合わせはサポートされていますか、また適切な権限を持っていますか？
• どの値が保持され、どの値が破棄され、結果のIDは何になりますか？
• 履歴、関係、および外部参照はどうなりますか？
• 同期はどうなりますか: 変更を認識しますか、レコードを再作成しますか、それとも失敗しますか？
• 実際にどのような回復が可能で、あなたのコピーでは何がカバーされませんか？

外部連携の対応範囲（英語）を読み、使用しているコネクタの仕様を確認してください。読み取り機能があっても、レコードの統合結果を連携先に反映できるとは限りません。

その発生源も確認してケースをクローズする

統合が承認された場合は、まず接続されたシステムへの影響をどのように制限するかを合意してください。互換性のあるテスト環境で合成データを使用して試行します。そのような環境が存在しない場合は、プロバイダーとの不明点を解決するまでブロックを維持します。単一のエクスポートだけでは、すべてを復元できることを証明するものではありません。

承認された変更後、フィールドと参照を予測と比較し、バッチを拡大する前に次の同期をレビューします。結果が不明確な場合は、操作を繰り返す前に調査してください。

Frihetの顧客管理では、リストをCSVとしてエクスポートできます。これはレビューの入力として役立つ可能性がありますが、このテンプレートのインポートや顧客の自動統合を前提とするものではありません。

重複が発生した理由（手動登録、インポート、またはコネクタのルールなど、証拠がある場合）をメモしてケースを閉じます。まだ不明な場合は、担当者を指定し、確認を保留にしておきます。明確な関係を持つ2つの保持されたレコードは有効な結果であり、説明可能な履歴のない短いリストはそうではありません。

参照元: 2026年9月14日。操作を行う前に、プロバイダーの最新のドキュメントを確認してください。