▼ この記事の内容
営業支援ツールとMAの連携では、顧客ID、配信状態、営業の受領、返却理由を別々に扱います。同じ条件で候補方式を試し、同期の成否と営業が受け取ったかを混同せずに本稼働を判断します。
MAと営業支援ツールをつなぐとき、画面上で値が同期しただけでは、営業が依頼を受け取って対応できるとは限りません。照合の方法、配信停止の扱い、担当者が不在のときの引き継ぎまで決めて初めて、試行結果を比較できます。
特に、メールアドレスの一致を人物同一と扱ったり、配信停止と営業への連絡可否を一つの状態にしたりすると、確認すべき論点が見えにくくなります。連携方式を選ぶ前に、どの情報を誰が正本として更新するかを表にします。
2026/9/15に確認したHubSpotとSalesforceの公開資料を参照しながら、同じ架空データで試す記入例を示します。利用するプランの料金、反映速度、対応機能は、契約前にベンダーへ確認してください。
営業支援ツールとMAの連携情報を整理する
連携で渡すのは、MA側の反応をそのまま営業へ送ることではありません。同じ相手を照合し、依頼内容と配信状態を引き継ぎ、営業が受け取った結果を別の項目で返せるようにします。
MA、CRM、SFAという名称だけで担当範囲を決めず、顧客の状態と営業の作業を分けて記録します。こうすると、同期エラーと未受領、配信停止と返却を別々に調べられます。
顧客の状態と営業活動を分けて管理する
連携を設計するマーケティング担当と営業担当は、同じ相手のレコードを結び付け、依頼内容と配信状態を渡し、受領・対応結果を別項目に記録します。データ同期が成功しても、営業が依頼を受け取った証拠にはなりません。
マーケティング側の見込み客の分類と、営業側の受領待ち・返却理由は、別の項目で記録します。分類を表す値を、担当者が依頼を受け取った証拠として代用しないようにしてください。
営業側では、依頼を見たか、誰が担当するか、次に確認する期限はいつかを別に持ちます。受領前の状態、受領後の対応、再確認待ちを分ければ、MQLやSQLなどの社内定義を機械的に巻き戻す必要はありません。
営業ツール全体の役割を整理し直したいときは、セールステックの領域別整理も確認すると、今回の連携範囲を置きやすくなります。
営業AI・営業DX セールステックカオスマップ｜課題逆引き7分類
項目ごとの正本と更新方向を決める
ID、配信状態、育成段階、営業受領、返却理由は、更新元と方向を列ごとに決めます。同じ画面に表示される項目でも、意味が違うなら一つの状態として上書きしません。
次は架空の設計例です。項目名と更新方向は、自社の設定に置き換えてください。
| 項目 | 架空の値 | 更新元・方向 | 空欄・矛盾時の処理 |
|---|---|---|---|
| MAレコードID / CRM ID | MA-031 / CRM-082 | 対応表を連携管理者が保守 | メール一致だけで統合せず照合待ち |
| 会社IDと担当者 | AC-014 / 鈴木 | CRMからMAへ | 共有アドレスなら担当者未確定を残す |
| 依頼内容と受信日時 | 導入相談 / 9月15日10時 | フォームから営業依頼へ | 閲覧履歴だけで依頼済みにしない |
| 配信状態・取得元 | 停止 / 停止フォーム | 対象チャネルごとの管理元 | 未指定を同意済みに補完しない |
| 営業受領・担当・期限 | 受領待ち / 田中 / 翌営業日正午 | 営業側から共有一覧へ | 未受領を検出し代理担当を確認 |
| 返却理由・再確認日 | 導入時期未定 / 10月1日 | 営業からマーケティングへ | 空欄のまま再配信しない |
保存期間、アクセス権、具体的な項目名は各社の方針と契約条件で確認します。次に、候補方式ごとに照合経路と例外を確認します。
連携方式と公式仕様を比較する
方式を選ぶ基準は、双方向か一方向かという名前だけではありません。必要なレコード、照合キー、停止状態、例外復旧を試験できるかで候補を絞ります。
以下の比較は運用設計のための整理です。全製品の対応、性能、価格を比較する表ではないため、実際の接続可否は対象製品と契約で確認してください。
同一基盤・標準連携・CSVを運用条件で選ぶ
方式比較表は、利用予定の環境で確認する項目を整理したものです。標準コネクターの具体例として、次節ではHubSpotとSalesforce間のメール照合と、AMPSEAを有効にしたAccount EngagementとSalesforce間のCRM ID照合を確認します。CSVや同一基盤へ同じ照合仕様を当てはめず、各環境の仕様を確認してください。
候補方式は、照合キーと停止状態を確認でき、例外が起きたときに戻せるかで選びます。一方向連携でも目的を満たすなら候補になり、双方向を無条件に優位とはしません。
| 方式 | 照合・対象範囲 | 停止状態 | 権限 | 例外ログ | 再処理担当 | 保留条件 |
|---|---|---|---|---|---|---|
| 同一基盤の機能 | 共有IDと対象機能・レコードを確認 | 共用画面でも配信先の状態と管理元を照合 | 営業とマーケティングが必要項目を閲覧・更新できるか | 状態変更履歴と未受領を確認できる記録を用意 | 基盤管理者が設定差を確認し営業が再受領 | 必要機能が別契約、権限や履歴を確認できない |
| 標準コネクター | 対象レコード・照合キー・マッピング方向を確認 | 初回同期前と停止後更新を試験 | 接続ユーザーの読取・更新対象を確認 | 元ID・先ID・失敗項目・時刻を追えるか | 連携管理者が差分を照合して再送し営業が確認 | 停止状態が対象外、失敗原因や復旧担当が不明 |
| CSV | 更新キー・対象リスト・抽出時刻を固定 | 取込前と送信前に最新の停止状態を照合 | 抽出・取込・送信の実行者と権限を分ける | 取込ファイル版・件数・エラー行・再取込結果を残す | 取込担当が対象行を訂正し確認者が重複を照合 | 送信直前の停止確認や取込履歴を確保できない |
初回の試行では、正常に取り込めた件だけで採用を決めず、重複と未受領も同じ表に残します。実製品の照合規則は、公開仕様と自社の接続設定の両方で確認します。
メールアドレスとCRM IDの違いを確認する
メールアドレスの一致とCRM IDの一致は、同じ人物であることを証明する手続きではありません。どの経路で何を照合するかを確認し、複数候補や共有アドレスは照合待ちとして残します。
HubSpotのSalesforce連携の説明では、メールアドレスによりレコードを一致させ、フィールドマッピングと選んだ同期方向に従って値を同期します。インストールだけで既存の全レコードが作成されるとは限らず、対象条件や作成設定も確認が必要です。HubSpotのSalesforce連携ヘルプ
AMPSEAを有効にしたAccount EngagementとSalesforceの連携に関する公開資料では、コネクターがCRM IDで双方を照合し、フォームやインポートではメールアドレス照合が起こる場合があると説明されています。これは対象環境の説明であり、全環境や全経路へ広げません。SalesforceのAMPSEAヘルプ
候補を比較するときは、照合キー、対象リスト、権限、フォーム・インポートの経路を一緒に記録します。次に、停止状態と営業の受領を別々に試験します。
参考：Sync Salesforce leads and contacts to HubSpot｜HubSpot公式ヘルプ ／ Allowing Multiple Prospects with the Same Email Address｜Salesforce公式ヘルプ
配信停止と営業への引き渡しを別々に管理する
配信停止は配信対象を扱う状態であり、営業が依頼を受け取ったかを表す状態ではありません。設定名が似ていても、用途、更新元、確認する人を分けて扱います。
停止情報の同期仕様を、法律上の同意や全ての連絡の可否へ広げないことも重要です。用途ごとの判断は社内の適用条件を確認し、この表では連携の観察項目に限定します。
配信停止が同期される条件を確認する
停止の同期設定、更新元、初回同期前の扱いを記録し、空欄を積極的同意として補完しません。送信前に確認する項目と、営業依頼を残す項目を別にしておきます。
HubSpotの同期仕様の説明では、SalesforceのEmail Opt Outを外してもHubSpot側で再購読にはならず、未同期コンタクトの停止状態は初回同期まで同期されません。したがって「停止は自動で全部門に反映される」とは扱わず、対象と時点を確認します。
Account EngagementのOpted Out同期には、同期なし、Account Engagement値優先、Salesforce値優先、最後に更新されたフィールド値優先という選択肢があります。最後に更新された値が常に正しいとは決めず、自社で選んだ設定を試行表へ残します。SalesforceのOpted Out同期ヘルプ
参考：Sync Salesforce leads and contacts to HubSpot｜HubSpot公式ヘルプ ／ Account Engagement Opted Out Sync Behavior Overview｜Salesforce公式ヘルプ
MQL・SQLと受領待ち・返却理由を分ける
育成段階と営業処理状態を分けると、返却があっても段階を機械的に戻さずに済みます。受領待ち、受領済み、返却・再確認待ちを、担当と日付を伴う別項目として記録します。
次は架空の運用例です。MQLやSQLの名称・判定条件は各社の定義に従ってください。
| 時刻・イベント | 営業処理状態 | 育成・案件の扱い | 担当の動作 |
|---|---|---|---|
| 9月15日10時 導入相談受信 | 受領待ち | MQL候補、社内基準確認前 | 田中へ依頼内容とIDを渡す |
| 10時15分 内容確認 | 受領済み | 自動的にSQL・案件化しない | 個別連絡の範囲を確認する |
| 10時20分 停止を受信 | 受領済みのまま | 一斉配信対象を停止条件で制御 | 営業依頼を消さない |
| 9月16日 導入時期未定 | 返却・再確認待ち | 段階を機械的に戻さない | 理由と再確認日を記録する |
HubSpotのライフサイクル段階は既定の自動更新では前進方向で、APIやインポート等で以前の段階へ変更する際は既存値をクリアする前提が説明されています。営業返却を同じ値で代用せず、次は重複や遅延を含めて確認します。HubSpotのライフサイクル段階ヘルプ
参考：Use contact and company lifecycle stages｜HubSpot公式ヘルプ
同じ架空データで連携と引き継ぎを検証する
試行では、正常な同期だけでなく、重複、遅延、対象外、未受領を同じデータ集合で観察します。結果を残せば、方式の違いと運用上の不足を分けて本稼働の可否を判断できます。
以下は架空データを使った試行の記入例です。条件と結果を自社の試験内容に置き換えてください。
重複・遅延・対象外を含めて結果を記録する
共有メール、古いCSV、二重依頼、未受領を含めて試し、どの状態を誰が確認するかを記録します。正常に流れたレコードだけを数えると、送信直前や担当不在の問題が残ります。
| 投入する条件 | 合格とする観察 | 架空の記入結果 | 次の判断 |
|---|---|---|---|
| 二人が同じ共有メールを使用 | IDと依頼者を確認でき、誤統合を保留できる | 候補AはCRM ID不明の一件を照合待ちにした | 本人・会社を確認する担当を確定 |
| 停止後に古いCSVを取込 | 古い状態で再送信しない | 候補Aは送信前確認が未整備だった | 本稼働を保留し確認を追加 |
| 同じ依頼イベントを再送 | 二重依頼を検知し復旧できる | 候補Bは一件を保留した | 削除・統合の責任者を決める |
| 同期後に営業が未受領 | 期限超過の受領待ちが見える | 候補Aは翌営業日に一件を発見した | 代理担当と連絡先を設定 |
未試験の項目は未確認として残し、採用判定に使いません。APIの冪等性やログの保存方法は製品既定の保証とせず、対象環境で確かめます。
エラーの再処理と担当者不在時の対応を設計する
例外一覧には、発生日時、元ID、先ID、項目、理由、再処理担当、最終結果を残します。削除や全件再送の前に、停止状態と重複への影響を確認できる形にします。
連携が止まったときは未同期対象を抽出し、差分を照合します。連携管理者だけでなく、営業の代理受領者も決めておくと、担当者不在を同期エラーと取り違えずに済みます。
再処理を担当する人が、どの画面やログを確認できるかは個別に確認してください。次に、初期の準備と毎月の確認作業を分けて費用を比較します。
費用と検証結果を基に本稼働を判断する
本稼働の判断では、同期した割合だけでは足りません。初期の設計・試験と、毎月の例外処理・担当間確認を分け、契約費が未確認のまま総額を決めないようにします。
試行の観察結果は、同じ依頼ID集合を分母にして、同期確認件数と営業受領件数を別々に数えます。条件が揃わない候補は、修正して再試行するか、方式を変更するかを保留できます。
初期設定と毎月の確認作業を分けて見積もる
初期のID・項目整理と試験、毎月の例外処理と担当間確認を別に見積もります。未確認のライセンス費、接続費、対象件数、権限条件は0円として総額を確定しません。
次は比較のための架空計算です。時間と単価は社内評価用の仮定であり、現金支出、価格、ROI、売上増加を示すものではありません。
| 区分 | 架空の作業と算式 | 結果 | 未確認項目 |
|---|---|---|---|
| 初期のみ | 項目・ID整理6時間＋試験8時間＋営業説明2時間 | 延べ16時間 | 設定支援費、移行対象、接続環境 |
| 毎月・例外 | 12件×1件8分 | 96分/月 | 失敗件数、ログ閲覧権限 |
| 毎月・担当間確認 | 30分×月2回×2人 | 延べ120分/月 | 繁忙時の代理と確認枠 |
| 毎月・合計 | 96分＋120分 | 3時間36分/月 | 連携利用料、対象数、上限 |
仮に全員を時給3,000円で置けば、初期は48,000円相当、毎月は10,800円相当です。実際は担当別の時間と単価を合算し、三か月比較なら初期費用を重複計上しません。
同期率と受領率を分けて採否を決める
同期確認と営業受領は、同じ依頼IDの集合を分母にして別々に記録します。同期済みを分母に変える場合も、率の名称と定義を変え、良く見える数字へ置き換えません。
架空の観察では、対象の依頼20件に同期確認18件、営業受領15件がありました。同期確認率は18/20で90%、同じ対象に対する受領率は15/20で75%です。15/18を使うなら約83%と別の定義として示します。
| 判定 | 条件 | 架空の記入 |
|---|---|---|
| 本稼働候補 | 照合、停止状態、受領、再処理、必要な契約費と工数が揃う | まだ候補なし |
| 修正して再試行 | 操作できるが送信前確認や確認枠が不足 | 候補Aは配信前確認を追加後に再試行 |
| 方式を変更・延期 | 誤配信の制御や例外担当を確保できない | 候補Bは重複照合を解決するまで延期 |
担当者間で試行条件を共有するなら、MAと営業支援ツールの連携確認票（PDF）に、照合・停止・受領・例外・費用の未確認点を記入します。
実契約費、権限、処理枠、個人データの扱いは対象環境で確認したうえで、本稼働、再試行、延期を選びます。
まとめ
営業支援ツールとMAの連携では、照合ID、配信状態、営業受領、返却理由、例外を一つの状態に混ぜないことが出発点です。同期の成功だけで営業への引き継ぎ完了とせず、担当と期限を別に確認します。
候補方式は、同じ架空データで重複、遅延、停止、未受領を試し、初期と月次の費用も分けて記録します。未確認の契約条件や権限が残る場合は、本稼働の結論を急がず、必要な確認を加えて再試行します。
