取引先データの登録・管理についてご相談がございます。 弊社では、Salseforce に基幹システムの取引先データとSansan Datahubを使用して得られる名刺データから取引先をマッチングさせて取引先を管理しようと考えております。 その中で、取引先の二重登録を懸念しております。 運用開始時に関しては、基幹システムからあらかじめ取引先を取り込むので、名刺データから出来上がる取引先データと問題なくマッチングできます。 しかし、取り込みのタイミングによっては、名刺データの取引先と基幹システムの名刺データが二重で登録される可能性があります。 ※前提として基幹システムの取引先データには法人番号のようなデータを持ち合わせておりません。
皆様、どのような構成でデータの取込等を実施しておりますでしょうか。
漠然としたご質問で大変申し訳ございませんが、
ご回答の程よろしくお願い申し上げます。
@竜平 小山さん
こんにちは。
＞ 弊社では、Salseforce に基幹システムの取引先データとSansan Datahubを使用して得られる名刺データから取引先をマッチングさせて取引先を管理しようと考えております。
ちょうど先日、SalesforceとSansan (Data Hub)連携をするためにお客様へ導入支援行いました。わたくしが導入支援した際の経験談で、お話いたしますと以下構成となります（双方向連携されるか分かり兼ねますが、ほぼ小山さんと同じ事例かと思います）
ーーーー
■連携構成
①Salseforce（Sansan提供『AppExchange』＋Sasan Data Hub利用）
②基幹システム
※①②間で、取引先オブジェクトを双方向でデータ連携を実施
③Pardot
④Experience Cloud
■連携するにあたり、取引先データの取扱い・定義
①Sansan名刺取込 or Salesforce画面入力から派生する取引先データ
・・・ゆるい顧客情報。営業が交換する名刺のため、必ずしも本社情報でない拠点・支店といった拠点情報も含まれるもの（加えて、個人事業主の場合も考慮要）
②契約／登記情報、請求書等に使用想定されたベースとなる取引先データ
・・・いわゆる、精緻な登記情報もとにされた正確な顧客情報を管理）
③ビジター、プロスペクトまでの見込情報のため、取引先データは派生しない（Salesforceに準ずるものとする）
④会員サイトによる、会員ユーザ登録で派生する取引先データ（1件、事前に用意しておいた『ダミー取引先』へすべて紐づくようにしておき、後日、運用にて、会員情報の会社情報を正しい、取引先データに紐づけし直す）
※上述の通り、①②だけでなく、③④もあったことから混迷を極めました。
＞取引先の二重登録を懸念しております。
こちらは、残念ながら完全システム自動化まで行うことは、かなり困難であるとの感触・結果でした。導入支援の中で、サービス提供元のSansan社とのやり取りも行いましたが、「重複レポート」を定期的（週次・月次といったかたちで）チェック業務を併せて行う。といったことも推奨されております。
■重複管理の方針
@Keiji Otsuboさんも仰るように、Salesforce上で「重複ルール（一致ルール）」を活用すること。が推奨されております。方法とタイミングは、以下２つです。
ーーーー
①Sansan名刺連携→Salesforce“取込時”に『重複と判断させたい』条件をあらかじめ設定＆仕込んでおく。「取引先（や取引先責任者）」が、新規データとして重複発生することを防止することを行います。※初期設定の推奨ですと、「(Sansanシステム側が持つキーとなる)SOC または SLC」コードというもので、一意情報の判断として「重複レポート」で重複情報を参照可能なようにすることを推奨されます。
②Salesforce“取込後”に、Salesforce上で、個別に「取引先（や取引先責任者）」を手入力で、登録や更新をする際に、あらたに重複発生を防ぐために、新規でもう一つ『重複と判断させたい』条件をあらかじめ設定＆仕込んでおく。 ※具体的には、①と異なる、「(基幹システム側が持つキートなりえる)取引先名・取引先英語名・法人番号」を、一意情報の判断として「重複レポート」で重複情報を参照可能なようにしました。
＞ 運用開始時に関しては、基幹システムからあらかじめ取引先を取り込むので、名刺データから出来上がる取引先データと問題なくマッチングできます。
仰るように、上記「重複管理の方針」が明確に貴社内で定義出来れば、問題ないと思われます（が、重複発生すること。を前提に業務チェック体制をどのようにするか？も同時に検討しておくことをお勧めいたします）※なお、わたくしの経験では、更に、①から②への連携もあったことから混迷を極めました。
＞※前提として基幹システムの取引先データには法人番号のようなデータを持ち合わせておりません。
こちらですが、貴社(Sansan社との)契約状況にもよるかと思いますが、Sansan社のサービス提供で、Sansan Data Hub→Salesforce取込後に、Salesforce上の「取引先、取引先責任者、リード」情報に『帝国データバンク、国税庁、Sansan独自情報』といった住所含む会社情報を自動で設定してもらえるサービスもありますので、その中で、法人番号も付与されます。これらの活用ご検討も良いのではとも思いました。
また、ご存知かと思いますが、初期導入時の設計段階で 貴社の考え方として、名刺情報を取引先データとマッチング＆関連づけ行う上で
（１）SOC（会社情報を本社情報をベースとした、取引先データ作成）とするのか
（２）SLC（会社情報を各拠点・支店情報をベースとした、取引先データ作成）とするのか
早期に、確定しておくと良いかと思われます。
上記の違いは、
（１）１件の取引先データ（本社扱い）に対して、複数名刺が関連づけたい
（２）複数件の取引先データ（各拠点・支店ごと）に対して、それぞれ該当する名刺を関連づけたい
といった場合の使い分けになります。
どちらも、良い悪いは無く、会社の統廃合(旧会社・新会社)や海外名刺を名刺取込した場合に、意図せず、新規取引先データが発生してしまう。など 貴社の考える課題。というのが発生することが想定されますので、このあたりは、どのようなケースで名刺流入（または、Salesforce上で、取引先データの登録を許容するのか？）経路が存在するか。明確にしておくことがある程度、予防することが可能です。
乱文となり、恐縮ですがご参考いただけると幸いです。
