CRMと販売管理を連携するには？顧客・商談・受注データの確認点

何をつなぐか：会社・担当者・商談・受注を分ける

最初に、どの二重入力や探し直しを減らしたいかを、担当者の仕事で説明します。「CRMを連携する」だけでは、商談を閲覧できればよいのか、受注の作成を支援したいのか、取引先の変更を共有したいのかが分かりません。営業が入力する情報から、管理担当が何の判断・登録に使うかを一件でたどります。

CRMと販売管理は、同じ取引の違う部分を扱う

CRMは顧客との関係を管理する仕組みです。会社、担当者、相談の履歴、商談の状況などを営業が使います。販売管理は、受注や出荷、請求など、販売に伴う業務の記録を管理します。製品や会社によって範囲は違うため、「CRMにはこの項目、販売管理にはこの項目が必ずある」と一律には決めません。

会社は取引の相手となる組織、担当者は営業が相談する個人、商談は何について検討しているかという案件、受注は依頼内容を受け付けた記録です。同じ会社に複数の相談先や商談があり、一つの商談から複数の受注が生じる運用もあり得ます。どの関係が自社で必要かを決め、名称が似ている項目を同じものへまとめないでください。

契約先、請求先、営業の相談先を取り違えない

営業が相談する支店と契約する本社、請求を送る部署が違う場合、すべてを一つの住所や担当者で置き換えると困ります。どの会社・拠点・役割を別に持ち、受注でどれを使うかを確認します。関係会社や支店の扱いは、自社の取引と対象製品の構造に合わせます。

今回つなぐ対象を、顧客情報の共有、商談から受注候補の準備、受注の状況を営業へ返す、などに分けます。会計への仕訳、入金、配信の運用まで自動的に同じ範囲へ広げず、残す仕組みと引き渡す情報を明示してください。

見積・受注・出荷・請求など販売業務自体の整理は、販売管理システムの導入要件へ。社内でCRMの仕事を誰へ渡し、受け付けや差戻しをどう扱うかという問題とは分け、本稿では二つの仕組みの記録と更新条件に焦点を当てます。

同じ取引先をどう見分け、記録の関係を結ぶか

番号の一致、名前の一致、同じ取引先だと確認したことは、それぞれ別です。CRMと販売管理で番号が違っても同じ会社を指す場合があり、名前が同じでも別拠点・別会社の場合があります。どの条件で照合し、曖昧なものを誰が確認するかを決めます。

四種類の記録を、同じ取引の中で読み分ける

次は一つの架空取引の記録です。番号は記録の対応を説明するための仮の目印です。例えば会社の番号と商談の番号は、同じ会社に関係していても別のものを識別します。原データ上の機械的なキーや担当者の仮名は見出しにせず、以下では仕事上の役割で呼びます。未決・未確認は、該当なしや金額0を意味しません。

この時点でCRM側の会社・相談先・商談の関係は記載されていますが、販売管理の受注候補がどの会社・商談に対応するかは未確認です。会社名と番号を並べただけで、その関係が確定したことにはしません。「相談中」の商談を、受注確定・売上・入金へ進んだ記録として扱わないでください。

図で見る問い：会社、相談先、商談がCRMにあり、販売管理に受注候補があるだけで、同じ取引として結び付いたと言えるでしょうか。どこまで関係が書かれ、どの対応をまだ確認していないかを見てください。

この解説図を原寸で見る

図の読み方：CRM内の関係があることと、販売管理側の対応が確認できたことは別です。会社同士の対応を調べ、その会社につながる相談先・商談・受注候補を必要な範囲で照合します。対応を確定できない記録は、相手側に新規作成してよいかも含めて保留し、確認担当へ返します。

照合、項目対応、対象の絞り込み、関連付けを分ける

照合は、二つの仕組みのどの記録を同じものとして扱うかを決めることです。項目対応は、その記録のどの項目へ値を渡すかを決めることです。絞り込みは、どの記録を処理対象にするかを決めます。関連付けは、会社と担当者、商談と受注などの関係を結ぶことです。一つが合っていても、他の三つまで正しいとは限りません。

連携前に分けて確認する四つの仕事

HubSpotの公式説明でも、データ同期の照合は項目の対応や絞り込みと区別されています。ただし照合に使える項目や対象は、接続するアプリと記録の種類によって異なります。会社名、メール、ドメインなどを、どの製品でも使える万能な一致条件として指定するのではなく、対象の組合せと設定で確認してください。

一件に決まらないときの戻り先を用意する

一致候補がない場合は本当に新規か、表記揺れや変換漏れかを調べます。複数候補なら、どちらかを推測で選ばず、候補と根拠を確認担当へ示します。同じ名前の別会社、同じメールを共有する窓口、社名変更、担当者の転籍など、自社で起こる例を選びます。

対応が確定した後に両側の番号を保存する方式なら、どこへ残し、初回の条件が変わっても同じ記録へ戻れるかを確認します。統合や削除で番号が使えなくなった場合の追跡方法も必要です。名称を直すたび新規会社が増える、といった結果を避けるには、初回と変更時を分けた確認が欠かせません。

項目ごとの管理元、送る向き、更新条件を決める

同じ会社に対応できたら、次に項目単位で「どちらを根拠に、誰が更新するか」を決めます。全項目を双方向にすれば便利になるとは限りません。双方で編集できる住所や担当者が食い違った場合、どの根拠へ戻り、どの変更を残すかが必要です。

管理元はシステム全体ではなく、意味のある項目ごとに決める

営業が相談に使う連絡先と、管理部門が請求を送る連絡先では、確認する相手と変更の根拠が違う場合があります。請求先を管理担当が確認して更新するなら、営業がCRMの連絡先を変えたことだけで請求先も上書きしてよいかを検討してください。すべての情報を一方だけに寄せる前提にはしません。

項目ごとに、意味、管理元、入力担当、送る方向、相手側の項目、形式やコードの変換、必須条件、変更する時点と確認担当をそろえます。会社名が表示用名称か正式名称か、住所が営業拠点か請求先か、といった定義が合っていることが先です。文字数や日付形式だけを合わせても、仕事上の意味の違いは残ります。

送る向きと、動き始める条件を別に示す

一方向は一方から他方へ値を渡す方式、双方向は双方の変更を扱う方式です。ただし、どの記録・項目・状態を対象とするか、作成と更新の両方に対応するかは別の条件です。会社は双方で対応させても、商談から受注候補を作る条件は片方向、といった設計も候補になります。

いつ渡すかは、保存時、業務上の確定後、担当者が確認した時点、定期処理など、対象の仕事と製品の動作に合わせて決めます。商談の状態名が似ているだけで、受注の登録条件を満たしたとはしません。何が揃ったら受注候補を準備し、誰が受注として確定するかを別に説明します。

同時変更と空欄の扱いを、実例で尋ねる

同じ項目を両側で変えたとき、「後で保存した値を採る」「片方を優先する」「人が確認する」などの候補があります。何を後と判断するのか、取り込み時刻か元の変更時刻か、失う値を追えるかまで確認します。製品の既定動作が自社に合うとは限りません。

空欄を「変更しない」と扱うのか、「相手側を消す」と扱うのかは重要な違いです。未入力、明示的な削除、0、対象外を同じ値へ置き換えず、対象項目ごとの条件を決めます。この架空例の未決・未確認を、自動で空文字や0へ補って送る根拠にはしません。

初回の連携と、その後の変更を分けて考える

初回は、両側に既にある記録をどう対応させるかが中心です。その後は、対応済みの記録のどの変更を扱うかが中心です。初回の照合ができたことだけで、変更・取消・関係の更新まで正しいとは判断できません。

初回：同じ時点の既存記録と、未解決の候補をそろえる

移す対象と基準時点、残す記録、初回の照合条件、重複や欠損の確認担当を決めます。初回に対象外にした記録、候補が複数ある記録、必要項目が足りない記録を、処理済みの一覧に混ぜないでください。元の対象件数と、対応した・新規候補・保留・失敗などの内訳を、対象の意味を揃えて比べます。

会社を対応させてから相談先や商談を結ぶなど、依存する関係の処理順も確認します。会社の値だけコピーされ、相談先が会社へ結び付いていない状態は、記録が存在していても仕事に使えない場合があります。担当者が何を辿れればよいかを、画面や記録で確かめます。

変更：同じ記録へ戻り、どの版の値を採ったか追う

変更後も同じ会社・商談へ戻れる条件、最後に処理した記録や版を追う情報、受け側の反映結果を確認します。氏名や社名の変更で、元の照合項目が変わる場合を試してください。作成に成功したことと、次回の更新が同じ記録へ届くことは別です。

担当者が別の会社へ移った、親会社と支店の関係を直した、商談に別の会社が紐付いた、といった変更では、値と関連先の両方を見ます。古い関係を残すか、履歴として保持するかも、業務の必要性と製品の仕様へ対応させます。

絞り込み条件を変えた後の動作も確認する

初回に同期対象へ入った記録が、後から条件に合わなくなったとき、更新が続くのか止まるのか、既に作られた記録は残るのかを質問します。HubSpotのデータ同期の説明には、初回の対象条件と、対応済み記録のその後の扱いを区別する記述があります。自社の接続も同じと推測せず、対象製品・接続方法で確かめてください。

重複・空欄・取消・結果不明の対応を決める

例外では、「何を自動で進めず、誰が何を調べるか」を決めることが大切です。実際の接続動作や業務判断が未確認のまま、自動作成・上書き・再送を前提にしないでください。

一致候補がない・複数ある：新規作成の前に根拠へ戻る

候補がないなら、表記揺れ、項目変換、対象条件、既存の対応情報を調べます。本当に新しい会社か判断できない場合は、営業や管理担当へ確認します。複数候補では、候補の番号、名称、拠点や取引上の役割を示し、どの根拠で一つを選んだかを残します。

重複を統合する場合も、相談先・商談・受注がどの記録に関係しているかを確認してから計画します。見た目の会社名を一つにするだけでは、関連先や外部番号の対応が残ることがあります。本番記録の削除や統合を、説明だけで実行するものではありません。

空欄・取消・削除：更新しない、消す、履歴を残すを分ける

入力されていない電話番号を渡した場合に、管理側で確認した番号が消えないかを確認します。削除の指示を明示する場合は、誰が許可し、相手側のどの項目・記録へ影響するかを別に決めます。空欄と0、記録そのものの削除を同じ処理にしません。

商談の失注や受注の取消は、同じ会社の削除を意味しません。受注候補、確定受注、請求など、どの段階の記録をどう変更できるかは対象業務と製品の条件によります。元の記録と履歴、影響する関連先を追い、どこから人の確認が必要かを示してください。

途中停止・結果不明：送った記録の状態を調べてから再開する

応答が途切れた場合でも、相手側へ全く届いていないとは限りません。元の記録の番号、送った内容や版、実行を追う情報と、受け側の記録を照合します。一部の項目や会社だけ反映された状態を、全件成功や全件失敗へまとめないでください。

受け側で同じ処理が済んでいると確認できたなら、何を再実行せず結果だけ回収できるかを検討します。未処理と確認できた部分は、その対象と内容を限定して再開します。判別できない部分は保留して調査担当へ渡し、応答不明という理由だけで新規作成や送信を繰り返さない条件が必要です。

この架空例で、まだ決まっていないこと

照合と更新：初回の照合条件、変更時の照合条件、項目ごとの更新方向は未決です。

例外への対応：空欄、重複候補、同時変更、結果不明後の再実行の扱いは未決です。接続する仕組みの実動作も未確認です。

まだ行っていないこと：実際のAPI呼出し、実顧客への書込み、値と関連の照合は行っていません。

これらは未決・未確認の条件を整理した下書きです。本文の要求例は、上の項目をどう検討するかを示す提案で、設定や連携の実行結果ではありません。実顧客の記録へ書き込む試験は行っていません。

権限、監視、切替と停止中の仕事をそろえる

連携を動かす担当だけでなく、業務上の差を見つけ、判断して直す担当まで決めます。接続の監視画面が正常でも、必要な会社が対象から漏れた、相談先だけ古い、といった業務上の不一致は別に残り得ます。

必要な権限と、見せる情報を仕事に対応させる

どの会社・担当者・商談・受注の、どの項目を読み、作成・更新する必要があるかを決めます。連携用の権限が営業担当の画面と同じ範囲とは限りません。不要な情報へ広げず、対象製品が分離できる範囲、認証の管理担当、利用できなくなったときの更新方法を確認します。

運用担当が調査のために見る記録と、営業や管理部門が判断に必要な情報を分け、実顧客の個人情報を試験資料へ不用意に出さないようにします。ここでは対象会社の個別の権限設定や法的な適合を認定していません。

監視は、処理件数と業務の対応を両方見る

送る対象、受け付けた記録、反映した記録、保留やエラー、関連付けが確認できた記録を必要な範囲で区別します。会社・商談・受注を混ぜた合計件数だけでは、どの仕事が進んだか判断できません。同じ対象と時点で内訳を見て、漏れや重複候補を調べます。

警告を誰がいつ確認し、営業・管理担当へ何を返すかを決めます。接続障害はIT、同じ会社かの判断は業務担当、項目の意味は双方、といった相談先を整理してください。応答時間や同期の間隔は製品・利用条件・負荷で変わるため、一般的な時間を保証値として置きません。

切替・停止・再開でも、同じ取引を追う

切替の基準時点、旧側の更新を受け付ける範囲、未処理の変更、番号の対応情報をどこへ引き継ぐかを決めます。並行比較をする場合も、二つの仕組みから同じ本番記録を重ねて作成・更新しない条件が必要です。

停止中に営業や管理部門が別の手段で受け付けた変更は、どの会社・商談のどの内容かを残します。再開後は、既に相手側へ反映した分と未処理分を照合します。再開したという表示だけでなく、関連先を含む必要な記録が揃ったことを担当者が確認できるようにします。

同じ取引で、値・関連先・状態を確認する

機能名や接続先一覧だけで比較せず、同じ架空取引と必要な例外を候補へ示します。営業と管理担当が期待する状態を先に決め、提供会社へ標準機能・設定・追加対応・人の仕事のどれで満たせるかを説明してもらいます。

回答によって、次に確かめることを変える

• 標準で対応できる：対象の版、接続方法、記録の種類、項目、権限と制限を確認します。会社だけの接続が、商談や受注の関連にも対応するという回答ではないことに注意します。
• 設定で対応する：管理元、照合、更新方向、空欄や競合、対象条件を、どの設定で実現するかを確認します。既定値と自社の要求の差、変更したときの影響も説明してもらいます。
• 追加対応が必要：どの条件が不足し、誰がどこを変更するか、初期費用と保守の範囲、項目やAPIが変わるときの対応を確認します。金額や期間は見積条件を揃えてから比較します。
• 人が確認する：誰が、どの候補・差・結果不明を、何の記録で判断するかを決めます。件数が増えた場合や代理担当でも、同じ取引へ戻れるかを確認します。
• 不明・必須条件に合わない：確認できない記録・関連・状態を具体化し、追加質問や範囲・候補の見直しへ戻します。「連携可能」という説明だけで未確認部分を合格にしません。

試験は、接続から値と関連の照合まで通す

1. 前提をそろえる。許可された試験場所と架空データ、製品の版・接続・設定、双方の元の記録、試す役割を定めます。本番の実顧客へ書き込むことを説明の前提にしません。
2. 期待する結果を先に決める。会社と相談先・商談・受注候補の対応、送る項目と保持する項目、未決のものを止める条件を、同じ取引の資料で示します。
3. 初回の対応を調べる。既存の会社を同じものとして扱う場合、新規候補の場合、複数候補の場合を分けます。記録数だけでなく、双方の番号と会社・相談先の関連を確認します。
4. 同じ記録の変更を試す。名称や必要項目の変更、空欄、同時変更、相談先の会社変更、対象条件から外れた場合を選びます。想定外の新規作成、上書き、関連の取り違えがないかも見ます。
5. 商談と受注の境目を確認する。「相談中」が確定受注へ変わらないこと、受注候補を準備するために不足する情報と確認担当を追います。取消や結果不明を試すときも、会社そのものの削除や同じ受注の重複に結び付かないかを確かめます。
6. 期待と実際を同じ単位で照合する。元と先の記録、値・版・関連先・状態を対応させます。差があれば照合条件・項目対応・対象条件・関係のどこへ戻るかを分け、変えた部分と影響する記録を同じ条件で再確認します。

まとめ：一件の関係と更新の根拠から始める

CRMと販売管理を連携する前には、会社・相談先・商談・受注を分け、同じ取引のどの記録が関係するかを描きます。同じ記録の照合、項目の対応、処理対象の絞り込み、記録同士の関連を別々に確認し、項目の管理元、更新方向、送る条件と時点をそろえてください。

初回の既存データの対応と、その後の変更では確認する条件が違います。重複候補、空欄、同時変更、取消や結果不明を誰が判断するかを決め、元と先の値・版・関連先・状態へ戻れるようにします。提供会社の回答を設定・追加対応・人の仕事へ具体化し、同じ架空取引で期待と実際の結果を比べます。