マーケティングが資料請求者の一覧を営業へ渡しても、誰から連絡すべきか判断できない。接触しなかった理由や商談結果も戻らず、MAの反応数とSFAの案件数がつながらない。ツールは連携していても、仕事は分断されたままです。
この状態で項目や自動化を増やすと、入力と修正の負担まで増えます。MAやSFAの導入・見直しでは、製品の機能を比べる前に、見込み顧客の獲得から受注までを一つの業務として設計する必要があります。
この記事の結論
MA・SFA設計の要点は、ツールの設定を先に決めることではありません。対象顧客と成果、受注までのステージ、部門間の引き継ぎ、最小データ、入力と例外対応の責任、見直し方法を決め、その運用をツールへ実装します。
この記事の要点
MA・SFA設計とは、顧客と社内業務の流れを定め、その流れを支える機能、データ、責任をツールへ割り当てることです。
一般にMAは、見込み顧客の獲得、施策への反応、情報提供などを支えます。SFAは、担当者への割り当て、接触履歴、次の行動、商談ステージなどを支えます。CRMは、顧客や企業との関係情報を継続して扱う、より広い考え方や仕組みです。
一つの製品が複数の役割を持つこともあり、境界は製品や組織によって変わります。SalesforceによるSFAの説明はリード管理、売上予測、業績分析などを挙げ、HubSpotのライフサイクルステージ資料は既定ステージを変更できるとしています。製品の用語を標準にせず、自社の仕事に合わせます。
設定画面を開く前に、対象と成果、ステージ、引き継ぎ、最小データ、例外時の責任を決めます。
一つの商材や顧客層を選び、何を改善したいかを決めます。対象が混ざると、同じ「見込み顧客」でも営業の動きが異なり、条件が複雑になります。
成果は「MAを使う」ではなく、営業が連絡すべき相手を判断できる、引き継ぎ後の状況がマーケティングへ戻る、受注までの停滞が分かる、といった業務の変化で表します。
各ステージには、入る条件、次へ進む条件、前へ戻す条件を置きます。名称だけをそろえても、担当者ごとに判断が違えば集計できません。
たとえば「営業引き継ぎ候補」は、対象顧客の条件、必要情報、行動反応を満たした状態とします。「商談」は担当者の感覚ではなく、顧客の課題と次の合意事項を確認した状態など、観察できる事実で定めます。全体の分け方は「営業成績が上がらない原因は？」も参考にしてください。
引き継ぎでは、誰を、いつ、どの情報とともに渡し、営業がいつまでに何を返すかを決めます。営業が受け入れない場合は、返却理由と次の担当も必要です。
顧客の適合度と行動反応は分けます。業種や規模が対象に合うことと、資料請求などの反応が強いことは同じではありません。HubSpotのスコアリング資料も、属性による適合度と行動反応を別の軸として扱っています。スコアだけで渡さず、除外条件や必須情報を組み合わせ、受け入れ・差し戻し結果で見直します。
データ項目は、その項目を使う判断から逆算して絞ります。使途のない必須項目は入力負担となり、未入力や仮入力を増やします。
必要となるのは、顧客や企業の識別情報、獲得経路、対象条件の根拠、重要な反応、引き継ぎ日と理由、担当者、次の行動、ステージ変更理由などです。各段階の判断に必要になった時点で更新します。Salesforceのリード実装資料も、用途に応じて表示、編集、必須とする項目や割り当て方法を計画するよう案内しています。
通常どおり進まない記録を誰が確認し、どこまで直せるかを決めます。重複候補、担当者なし、必須項目不足、同期失敗、営業からの差し戻しは、放置すると数字と実態のずれになります。
ステージ定義、日々の入力、例外判断、設定変更の責任者を分けます。相談先と変更履歴を残す場所も決めます。
役割分担は、製品名ではなく、どの判断と記録をどちらが担うかで決めます。
実際の配置は、自社の製品構成に合わせます。大切なのは、同じ意味の項目を二重管理しないことと、変更を判断する責任者を曖昧にしないことです。この運用全体を継続して整える役割は「MOpsとは？役割と始め方」で解説しています。
データ連携では、必要な項目ごとに正本、同期方向、重複判定、更新責任、失敗時の対応を決めます。
正本とは、その項目の最新値を確定する場所です。企業情報はCRM、施策への反応はMA、商談ステージはSFAというように、項目単位で定めます。双方向に更新できる項目を増やすと、どちらの値を優先するか分からなくなるため、更新する場所と同期方向を絞ります。
重複判定では、何を照合キーにし、一致が曖昧なときに誰が確認するかを決めます。同期失敗についても、検知方法、通知先、再処理の担当、未反映中の業務手順まで用意します。連携が動いていることではなく、誤りを見つけて戻せることまでが設計です。
運用は、一つの商材または一つの引き継ぎ経路に絞り、実データで確かめてから広げます。
これは架空の例ですが、ウェビナー参加者を営業へ渡す流れなら、参加だけで自動引き継ぎにはしません。対象企業の条件、参加後の反応、必要項目を満たした人を候補とし、営業が受け入れたか、連絡できたか、差し戻した理由は何かを確認します。実際の結果を見て条件を直します。
機能を増やしても現場で使われない場合は、設定より利用場面と責任の問題かもしれません。「ツールが定着しない原因は？」の点検項目も合わせて確認してください。
評価指標は、成果への前進と運用品質を組み合わせ、変える判断につながるものだけを選びます。
件数だけでは、流れのどこを直すべきか分かりません。分子、分母、対象期間、更新時点をそろえ、定例の場で続行、修正、停止を決めます。営業へ渡した後に商談化しない場合の見方は「商談化しないリードの扱い」で詳しく整理しています。
いいえ。先に業務の開始と終了、ステージ条件、担当、引き継ぎ、必要データを決めます。連携設定は、その合意を実装する工程です。
スコアだけでは決めません。適合度、行動反応、除外条件、必須情報を組み合わせ、営業の受け入れ結果や商談結果を見て基準を更新します。
多いほどよいとは限りません。次の判断や引き継ぎに使う項目だけを必須とし、用途、更新者、更新時点を説明できない項目は見直します。
すべてを自動化する必要はありません。条件が安定し、誤った場合に戻せる処理から自動化し、例外や重要な判断には人の確認を残します。
まず、一つの商材や顧客層について、獲得から受注までを一枚に書き出してください。
各ステージの入口と出口、引き継ぎと差し戻し、必要項目と更新者、正本と同期方向、例外時の相談先、見直す指標と日を記入します。空欄や部門ごとに答えが違う箇所が、設定を増やす前に合意すべき場所です。
自社だけで業務、役割、データ、部門間の接点を整理しにくい場合は、SHIOパートナーズのサービスをご覧のうえ、お問い合わせください。現在の流れを確認し、最初に扱う範囲と運用方法を一緒に整理します。