CRMは顧客情報と接点を継続的に管理する基盤、MAはMarketing Automationの略で、見込み客の獲得・育成・選別と施策実行を支援する仕組みです。実際の製品では機能が重なります。製品名で二者択一にせず、管理したいデータと自動化したい業務を分けて判断します。
1. CRMとMAの結論
CRMは「誰と、どのような関係があるか」を部門横断で共有する役割を持ちます。MAは「どの対象へ、どの条件で、どの施策を実行するか」を管理します。MAの施策結果をCRMへ戻し、営業やサポートが同じ顧客像を見られる状態が基本です。
2. 目的の違い
CRMの目的は顧客、企業、商談、問い合わせ、契約などを関連付け、関係を継続して管理することです。MAの目的はフォーム、メール、行動条件、スコア、シナリオなどを使い、マーケティング業務を再現可能にすることです。自動化そのものを目的にしません。
3. 全体像
CRMを顧客データの基盤、MAを獲得・育成の実行層として捉えると、役割の混同を減らせます。両者の間では顧客ID、同意状態、担当、施策反応、商談状態を受け渡します。
4. 管理するデータ
CRMは氏名、企業、連絡先、担当、商談、契約、問い合わせ、活動履歴などを扱います。MAは流入元、フォーム送信、メール反応、Web行動、セグメント、シナリオ状態などを扱います。同じメールアドレスでも人物が同じとは限らないため、統合ルールを決めます。
5. 利用部門
CRMは営業、サポート、マーケティング、管理部門が使う場合があります。MAはマーケティング担当者が中心ですが、営業への通知や引き渡し条件には営業部門の合意が必要です。管理者だけで設計すると、現場の受け取り方とずれます。
6. MAで行うこと
HubSpot公式は、CRMデータを使ったマーケティング自動化として、ワークフロー、フォームとメールの自動化、リードスコアリング、顧客行程の設計を案内しています。これは特定製品の公表機能であり、すべてのMAに同じ範囲があるとは限りません。
7. CRMで行うこと
CRMでは連絡先、企業、商談、タスク、活動、パイプライン、レポートなどを一つの顧客関係へ結び付けます。購入前の反応だけでなく、受注後の契約や問い合わせも扱えるようにします。
8. 機能が重なる理由
現在の製品はCRMにメール配信や自動化を含めたり、MAに顧客管理を含めたりします。そのため「CRM製品だからMAは不要」「MA製品だから顧客基盤も完成する」とは判断できません。契約予定プランの公式機能と制限を確認します。
9. 顧客獲得から営業まで
フォームで同意を得て顧客候補を登録し、MAで対象を分け、反応が引き渡し条件を満たしたら営業へ通知します。営業が対応した結果はCRMに記録し、対象外や保留なら育成へ戻します。入口と出口を両方定義します。
10. スコアの扱い
スコアは関心や適合を整理する補助指標であり、購入意思の事実ではありません。加点条件、減点条件、有効期限、上限、営業へ渡す基準を明記し、過去の閲覧が永続的に高得点を生まないよう見直します。
11. 同意と配信停止
CRMとMAの双方で連絡許可の状態を扱う場合、どちらを正本にするか決めます。配信停止が片側だけで処理されると誤配信につながります。取得経路、目的、日時、停止、削除要求を一貫して管理します。
12. CRMを優先する企業
顧客情報が表計算や担当者ごとに分散し、引き継ぎや問い合わせ対応が課題なら、まずCRMのデータ基盤を整えます。正しい顧客IDと連絡許可がないままMAを動かすと、重複配信や誤った対象抽出が増えます。
13. MAを優先する企業
顧客基盤と同意管理がすでに整い、手作業の配信、対象抽出、通知、育成シナリオが課題ならMA領域を検討します。最初から複雑な分岐を作らず、一つの明確な起点と終了条件で試します。
14. 両方必要な企業
獲得から商談、契約、継続まで一貫して改善する場合は両領域が必要です。一つの統合製品でも別製品の連携でも構いません。データ所有者、同期方向、遅延、重複、削除、障害時の再送を確認します。
15. 導入順
課題と基準値を決め、顧客データと同意を整理し、営業への引き渡し条件を合意します。その後、小さなシナリオを試し、誤配信、二重登録、停止反映、通知、レポートを確認してから対象を広げます。
16. 連携で確認する項目
顧客作成、更新、統合、削除、同意変更、担当変更、商談化の各イベントについて、どちらからどちらへ同期するかを表にします。同期失敗が黙って消えず、履歴と再処理手段があるかも試します。
17. 指標の違い
MAでは到達、反応、対象遷移、営業引き渡しなどを見ます。CRMでは商談、受注、継続、問い合わせなどを見ます。施策接触者と顧客、顧客と商談の母数を混同せず、期間と重複排除を揃えます。
18. 費用比較
表示月額だけでなく、登録対象数、配信量、利用者、追加機能、連携、移行、教育、運用、サポート、データ出力を含めます。価格は地域や契約条件で変わるため、同じ条件の公式見積もりで確認します。
19. 試用シナリオ
資料請求、同意登録、メール送信、反応、営業通知、商談化、対象外への戻し、配信停止までを同じ架空データで通します。デモ担当者の画面を見るだけでなく、自社の担当者が設定と日常操作を実行します。
20. 選定チェック
改善目的、顧客データの正本、同意、利用部門、対象抽出、シナリオ、営業引き渡し、分析、連携、総費用、退出を確認します。確認できない項目は推測で埋めず、契約前の質問として残します。
運用開始後の注意
シナリオは作って終わりではありません。対象件数、停止、重複、エラー、営業の受取結果を定期確認します。商品、組織、同意文面、営業段階が変わったら、条件と同期を再テストします。
自動化が増えるほど、誰が変更できるかが重要です。作成、承認、公開、停止を分け、変更履歴を残します。緊急停止と影響範囲の確認方法を手順化してください。
まとめ
CRMは顧客関係の基盤、MAはマーケティング施策の実行と自動化を主に担います。製品機能は重なるため、名称ではなく正本データ、対象業務、同意、営業連携から必要範囲を決めることが重要です。
データ設計を具体化する
連絡先、企業、商談、施策参加を一つの表へ押し込まず、別の実体として関連付けます。一人が複数企業に所属する場合、同じ企業に複数担当者がいる場合、一人が複数商談へ関わる場合をテストします。メールアドレス変更や退職があっても、過去の活動を別人へ誤って結び付けない設計が必要です。
MAへ渡す属性は目的に必要な範囲へ絞ります。CRMにあるすべてのメモや問い合わせ内容を同期する必要はありません。機密項目、自由記述、削除対象を定義し、同期先でも閲覧権限と保持期間が守られるか確認します。
営業への引き渡しを設計する
引き渡し条件はスコアだけでなく、対象企業、役割、明示された相談内容、連絡許可など複数の事実から決めます。通知された営業担当者が、受領、対応中、対象外、保留を返せる状態にします。返却理由はマーケティング側で分析できる選択肢にし、担当者を評価するためだけに使いません。
営業が対象外と判断した顧客を直ちに同じシナリオへ戻すと、同じ連絡が繰り返されます。待機期間、再参加条件、上限、商談中の除外、購入・解約時の終了を決めます。担当変更や組織再編があったときの通知先も確認します。
障害と変更に備える
API停止や認証切れで同期が止まった場合、未処理件数、最終成功時刻、再送結果を確認できるようにします。停止中にCRMとMAの両方で同じ顧客を編集した場合、どちらを優先するかを事前に決めます。再接続後の大量送信を防ぐため、同期再開と施策再開を分けます。
項目名や営業段階を変更すると、既存の分岐、レポート、連携が壊れる場合があります。変更申請には影響する項目、シナリオ、担当部門、テスト結果、戻し方を残します。四半期ごとに使われていない項目とシナリオを整理し、複雑化を抑えます。
導入判断を記録する
候補ごとに、公式情報のURL、確認日、対象プラン、試用結果、未確認事項、見積条件を残します。「できる」と書かれた機能でも、自社の権限・データ量・連携先では追加契約が必要な場合があります。契約前に必須シナリオが完了した証拠を保存します。
この分野の実務を相談したい方へ
記事で扱っている内容は、当社が実務として支援している領域です。 自社で進めるか外部に任せるかの判断からご相談いただけます。
