MAやSFA設計のポイント

「MAを導入したけれど、結局はメルマガ配信ツールにしかなっていない」
「SFAを入れたものの、入力されているのは最低限の案件情報だけ」
こんな状況に心当たりはないでしょうか。
マーケティングオートメーション(MA)や営業支援システム(SFA)は、本来、
マーケティングと営業をデータでつなぎ、経営の意思決定を支える"ハブ"になるべきツールです。
ところが、役割や設計があいまいなまま使い始めてしまうと、
-
メール一斉配信ツールとしてしか使われていない
-
MAひとつにマーケ・営業・CSのすべてを詰め込み、運用が破綻している
-
各施策は回っているのに、経営視点での「全体像」が見えない
といったあるある状態に陥りがちです。
この記事では、MAとSFAの役割の違いを整理しながら、
「自社のビジネスプロセスに合わせてどう設計すべきか」という視点をお伝えします。
MA・SFAが活きない理由
まず、なぜ多くの企業でMAやSFAがうまく活用されていないのかを整理してみます。
-
メール配信ツールとしてしか使われていない
「MA=メールマガジンを送るためのツール」と認識されていると、
スコアリングやシナリオ設計、レポートなど、本来の強みが活かされません。
結果として、「ちょっと高機能なメルマガツール」として扱われ、
投資対効果が見えにくくなります。 -
MAひとつにマーケ・営業・CSを全部詰め込む
MAだけで見込み顧客管理も商談管理も既存顧客フォローもやろうとすると、
セグメントやキャンペーン、フィールドが増えすぎて運用が破綻しがちです。
ルールが複雑になり、属人化も進みます。 -
全体のストーリーがない
施策単位ではPDCAが回っていても、
「このメルマガがどれだけ商談・受注に効いているのか」
「この展示会リードがLTVにどれだけ貢献しているのか」
といった“経営視点の問い”には答えられないケースが多いのではないでしょうか。
根本原因は、ツールの前に「役割と設計」が整理されていないことにあります。
MAとSFAをつなぐ頭脳としてのMOpsについては、こちらの記事でも詳しく解説しています。
まず役割を整理する
最初の一歩は、MAとSFAの役割をシンプルに定義し直すことです。
MA(マーケティングオートメーション)
見込み顧客を育成し、ホットな状態で営業に渡す「興味関心の醸成と初期接触がしやすい行動追跡」の役割。
SFA(営業支援システム)
初回連絡以降のパイプラインを管理し、商談化や受注までの確度とボトルネックを可視化する役割。
このように、MAは「商談前」、SFAは「商談以降」を担当するイメージです。
そのうえで、次のポイントをはっきりさせておきます。
-
誰が(マーケ・インサイド・営業・CSのどの担当が)
-
どこまでのプロセスを
-
どのツールで見るのか
この線引きをしないまま「とりあえず連携させましょう」と進めると、
あとから修復しづらい“カオスなシステム”ができあがってしまいます。
MA設計のポイント
役割が定まったら、MA設計のポイントを押さえていきましょう。
1. リード定義と重要な行動追跡を先に言語化する
-
新規リード
-
既存顧客
-
休眠顧客
など、リードの種類と状態をどう定義するかを最初に決めます。
あわせて、
-
行動(メールクリック、ウェブサイトのキーページ閲覧、セミナー参加など)
-
属性(企業規模、業種、役職など)
をどう評価するかのルールも言語化しておくことが重要です。
2. シナリオ設計を「顧客の購買プロセス」から逆算する
「資料DLした人には3通メールを送ろう」から始めるのではなく、
顧客の購買プロセスを整理します。
-
課題に気づく
-
情報収集する
-
比較検討する
-
社内稟議・決裁
といったステップごとに、どんな情報を届ければ前に進みやすいかを考え、
そのうえでステップメールやナーチャリングシナリオを設計します。
3. 経営が見たい指標からレポートを設計する
MAのレポート機能は細かく見ようと思えばいくらでも見られますが、
重要なのは「経営・事業責任者が意思決定に使えるかどうか」です。
-
チャネル別の案件化率
-
リードソース別の受注貢献
-
ナーチャリング経由の商談単価・LTV
など、「どの打ち手が売上に効いているか」を示す指標から逆算して、
必要なトラッキング・タグ・フィールドを設計していきます。
SFA設計のポイント
続いて、SFA側の設計ポイントです。
リード受け渡し基準と商談ステージを定義する
MAからSFAへリードを渡す基準(MQL→SAL)を明確にします。
-
連絡しやすい重要な行動を検知した
-
指名・部署・電話番号などの必須項目が埋まっている
-
BANT情報の一部が取れている など
同時に、商談ステージも粒度をそろえて定義します。
-
初回連絡
-
アポイント取得
-
ヒアリング完了
-
提案済み
-
見積提示済み
-
受注/失注
ステージごとに「何が起きたら次に進むか」を決めておくことで、
パイプラインの見方が全社で共通言語になります。
案件単位で追う項目を標準化する
案件詳細に何を書くかを営業任せにしていると、SFAは「個人の日報置き場」で終わってしまいます。
そこで、案件を前に進める判断と、パイプラインを横串で比較するために最低限必要な項目をあらかじめ決めておきます。
-
予算(Budget)
-
決裁者・社内キーパーソン(Authority)
-
顕在化している課題・期待値(Needs)
-
導入希望時期・決裁タイミング(Timing)
-
競合状況
-
成約見込みランク
といった情報を、SFAのフィールドとして定義し、入力ルールまでセットで標準化することがポイントです。
ここでの目的は「BANTを全部ヒアリングすること」そのものではなく、
-
どの条件の案件が、どのステージで止まりやすいのか
-
勝ちパターン/負けパターンがどんな共通点を持っているのか
-
MA側でどんなリードを増やすとパイプラインが太るのか
といった問いに、後からデータで答えられる状態をつくることにあります。
営業担当の頭やメモ帳にしかない情報を、SFA上に共通フォーマットで残せていれば、
個人ではなく「組織としての学び」として蓄積され、次の施策・次の設計に活かせるようになります。
「個人の管理しやすさ」と「組織の分析しやすさ」を両立する
エクセル感覚で自由にメモできることは大事ですが、
それだけだと集計・分析ができません。
-
必須項目と自由入力項目のバランス
-
選択式(プルダウン)項目の設計
-
営業側の操作ステップを最小限にするUI工夫
などを通じて、「入力のしやすさ」と「分析のしやすさ」を両立させていきます。
全体最適と部門連携をどう作るか
MAとSFAをそれぞれ最適化しても、「全体のストーリー」がつながっていなければ意味がありません。
1. 項目・タグ・ステージを連携させる
-
MAのリードステータス
-
SFAのリード・案件ステージ
-
CSツール側の契約ステータス
など、名前が似ているのに中身が違う状態は混乱のもとです。
なるべく同じ分類軸・名称でそろえ、同じ言葉で会話できる状態を作ります。
2. 共通KPIを基準にする
部門ごとにバラバラな指標で追っていると、議論がかみ合いません。
-
案件数
-
受注率
-
平均単価
-
LTV
といった共通KPIを軸におき、その内訳として各部門のKPI(リード数、アポ数、利用率など)を位置づけると、会話がしやすくなります。
3. プロセスを一枚絵にし、データの流れを設計する
マーケ→インサイド→営業→CSまでのプロセスをフロー図にし、
-
どの時点でどのツールにレコードが作られるか
-
どこで誰にバトンが渡るか
-
どのデータがどこにコピー/同期されるか
を設計します。
ここまで可視化しておくことで、「この変更はどこに影響するか」を判断しやすくなります。
※全体プロセスのフローイメージ
自社に合うツール選択の考え方
最後に、「どのツールを選ぶか」という話です。
ここでも陥りがちな罠がいくつかあります。
-
有名・高機能=自社に最適、とは限らない
導入実績が多くても、自社の商談数・リード数・人員規模に対してオーバースペックなこともあります。
「本当に必要な機能は何か」「どのレベルまで使い切れれば十分か」を冷静に見極めることが重要です。 -
MOps的な役割を誰が担うかを決めてから選定する
どんなツールを入れても、設計・運用・改善を担う"頭脳"がいなければ定着しません。
-
社内でMOps的な人材を育てるのか
-
外部パートナーに一部を委託するのか
方針を決めたうえで、「その体制で回せるツールかどうか」を基準に選定します。
-
-
将来の拡張性を見据えつつ、最初はシンプルに始める
最初からすべての機能を使いこなそうとすると、ルールが複雑になりすぎて頓挫します。
-
まずは主要チャネルと基本スコアリングだけに絞る
-
最初の半年〜1年で運用を安定させてから、順次機能を拡張する
といったステップで進めるのがおすすめです。
-
ツールではなく「設計」から考える
MAやSFAは、それ自体が目的ではなく、
「売上と顧客体験をどう変えるか」を実現するためのインフラです。
-
MAは、経営のハブとしてマーケ〜営業の前工程を可視化するツール
-
SFAは、初回連絡〜受注のパイプラインを管理し、ボトルネックを見つけるツール
この役割を明確にしたうえで、自社のビジネスプロセスに合わせて設計すれば、
ツールは単なるメール配信や案件管理を超えて、「経営の意思決定を支える武器」へと変わっていきます。
これからMAやSFAの導入・見直しを検討される際は、
まずツール名や機能比較ではなく、
-
自社のプロセスをどう設計したいのか
-
そのためにどんな役割を担うツールが必要なのか
という順番で考えてみてください。