集客から受注、その後の継続・拡大まで。B2Bの売上を考える実務メディア。Published by Consilegy ↗

CRM・SFA

CRM連携が止まる原因は、機能ではなく照合キーの設計でした

用語

  • CRM(顧客管理システム)
  • SFA(営業支援システム)
CRM連携が止まる原因は、機能ではなく照合キーの設計でした

既存の顧客台帳とCRM(顧客管理システム)をつなぐとき、連携ツールの機能を比べても要件が固まらないことがあります。先に決めるべきなのは、同じ顧客をどう見分け、どちらの値を採用するかです。

2つのレコードを同一の相手と判定する項目が決まっていないことと、項目ごとにどちらのシステムを正とするかが決まっていないことです。

連携先を選ぶ前に、この2つを決めてください。順序を逆にすると、ツールを選び終えてから要件定義が止まります。

「同じ相手」をどう判定するかで、会話が止まった

kintoneで数万件規模の顧客台帳を運用してきた企業が、新規事業でHubSpotを使い、フォーム経由の獲得と配信を回す。既存顧客は台帳側に、新規はCRM側に増えていく。二重入力を避けるため、両者を自動同期する。

要望としては単純です。実際に会話が止まったのは、次の一文でした。「同じ相手だと、どうやって判定しますか」

日本の法人顧客の台帳には、個人のメールアドレスが入っていないレコードが珍しくありません。代表電話と部署宛の住所、担当者名は姓のみ。

この状態で「氏名と会社名が一致したら同一人物」という運用ルールを作ると、同姓の別人が統合されます。

ツールを選ぶ前に、照合項目と正のシステムを決めた

決めたのは3点です。

1. 照合する項目を1つに決める。 照合の仕組みは連携の手段ごとに違います。例としてHubSpotのデータ同期(HubSpotが対応アプリとの間で提供する同期機能)では、照合項目を自分で指定する場合、一意の識別子に選べるのはテキスト型の項目で、一致判定に使われるのは選んだ1項目だけです(HubSpotナレッジベース「Match records in data sync」)。

「氏名と会社名とメールアドレスの3つが揃ったら同一」という設計は、この機構では組めません。1項目に絞れないなら、それは連携の設計ではなく名寄せの設計です。先に片付けます。

なお、kintoneがこのデータ同期の対応アプリに含まれるかは、連携を選ぶ時点で確かめてください。

含まれない場合は、iPaaSや自前の連携で組むことになり、照合の制約はその仕組み次第です。それでも「1項目に絞る」という決め方は変わりません。

SalesforceなどほかのCRMでも、照合の機能の名前と制約は製品ごとに違いますが、決める2点は同じです。

2. 一意のIDを、どちらが発番してどちらが保持するか決める。 CRM側が自動採番するレコードIDを識別子にする場合、それは相手側にも同期済みで両者が共有している状態が前提です。つまり初回は別の項目で当て、その時に生まれたIDのペアで以降を回す、という二段構えになります。

台帳側にはIDの保持用項目を追加し、一般ユーザーは編集できないようにします。

3. 項目ごとに正を決める。 住所は台帳が正、行動履歴はCRMが正、会社名はどちらか。ここを決めずに双方向同期を入れると、両側で更新された項目が上書きし合います。決められない項目は、双方向ではなく一方向にします。

採らなかった案は、中間システムを作って独自の名寄せロジックを持つことでした。判定基準が言語化できていない段階でロジックを書くと、誤統合の責任がシステムに移り、誰も直せなくなります。

初回同期の前に、届く先と課金を確かめる

照合キーが決まっても、数万件をいきなり同期してはいけません。CRMに既存顧客がまとめて作られた瞬間に、作成を起点にした自動処理が動くからです。

  • 作成を起点にしたワークフロー。 ウェルカムメール、営業への担当割り当ての通知などが、既存顧客の数だけ動くことがあります。登録条件を開いて、同期で作られたレコードが入らないかを確かめます
  • 課金の対象数。 HubSpotではマーケティングコンタクトの数で費用が決まる契約があります。同期で作るコンタクトを、マーケティングコンタクトにしない設定で作れるかを確かめます。設定の有無と既定値は、契約と連携の手段によって違います
  • 少数件での試験同期。 本番の前に、数十件に絞って同期し、上の2つが起きないことを確かめてから広げます

連携すると運用は減らず、確認と整理の担当が増える

連携を入れると運用は減りません。増えます。

同期の失敗レコードと除外レコードを日次で確認する担当、CRM側で重複を統合したときに台帳側を後追いで整理する担当、相手側起点で作られたレコードの空欄を埋める担当が要ります。

所要時間は件数と失敗の出方で変わるので、決める時点では、担当者の名前と確認の頻度を書きます。稼働後1か月の実績で、週に何時間かかっているかを測り直します。

台帳側の必須項目が多いほど、CRM起点のレコードは保存に失敗し続けます。連携の前に、受け側の必須項目を見直す作業が入ります。

もう1点、誤解しやすい仕様があります。

HubSpotのデータ同期では、同期対象を絞るフィルタは、初回にどのレコードを同期するかを制御する機能で、一度同期したレコードの継続同期を止める手段ではありません(HubSpotナレッジベース「Connect and use HubSpot data sync」)。

挙動は対応アプリと設定で違うことがあるので、使う連携で確かめてください。フィルタを入れたから安全、とは言えません。

連携で最初に決めるのは、どのツールを使うかではなく、2つのレコードを同一と判定する項目と、項目ごとにどちらのシステムを正とするかです。

今週、連携を検討している案件を1つ開いて、この2つが文書に書いてあるかを確認してください。書いていないなら、比較しているのは連携ツールの機能ではなく、まだ決めていない自社の設計です。

システムをまたいだ顧客データを収益の構造としてどう置くかは、レベニューアーキテクチャとはにまとめています。

関連する記事

照合する項目を決める前段、つまり取り込む側のデータをどう揃えるかは名刺とExcelを取り込む前に、必ず決める3つのことに書いています。取り込みの前処理と連携の照合キーは同じ問題を別の入口から見たもので、片方だけ整えても連携は通りません。

同じカテゴリの記事は「CRM・SFA」にまとめています。