Salesforceキャンペーンメンバーステータスの設計｜イベント反応を営業へ渡す方法
ウェビナーや展示会の申込者をSalesforceへ取り込んでも、キャンペーンごとに「登録」「参加」「出席」「視聴済み」など表記が違うと、横断集計も営業フォローも止まります。さらに、参加状況、資料閲覧、架電結果、商談化まで一つのステータスへ詰め込むと、最後に更新した情報しか残らず、施策への反応と営業の進捗を区別できません。
結論として、キャンペーンメンバーステータスは「行動の名前」ではなく、「次に誰が何をするか」を決める共通言語です。キャンペーン種別ごとに同じ値を使い、Respondedの判定、更新元、営業への引き渡し条件をセットで定義します。イベント参加状況はステータス、クリックや架電履歴は別の活動データとして持つと、集計とフォローを両立できます。
本記事のポイント
- キャンペーンメンバーステータスは行動ログの一覧ではなく、施策への反応と次の担当をそろえる共通言語である。
- Respondedは好意的な反応ではなく、施策に対する意味のある応答として定義し、イベント種別ごとに判定を固定する。
- 参加状況と営業進捗を一つの項目へ詰め込まず、ステータス変更をタスク・活動履歴・担当通知へ接続する。
キャンペーンメンバーステータスとは何か
Salesforceのキャンペーンメンバーは、キャンペーンとリードまたは取引先責任者の関係を表すレコードです。組織設定によっては取引先も対象にできます。メンバーステータスは、その人や会社が当該キャンペーンでどの段階にいるかを表します。リードの営業進捗を示すLead Statusや、商談のOpportunity Stageとは役割が異なります。
Salesforceのキャンペーンメンバー項目の公式説明では、Status、Responded、First Responded Dateが別々の項目として定義されています。つまり、表示する状態名と、反応として集計するか、最初に反応した日はいつかを分けて扱う構造です。
| 管理対象 | 答える問い | 代表的な項目 | 混ぜない情報 |
|---|---|---|---|
| キャンペーンメンバー | この施策にどう反応したか | 招待済み、申込済み、参加済み、欠席 | 営業全体の案件進捗 |
| リード・取引先責任者 | この人・会社とどう関係しているか | 担当者、属性、Lead Status | 個別イベントの参加状況 |
| 活動履歴・タスク | 誰が何を実行し、次に何をするか | メール、架電、面談、期限、担当 | 施策横断の集計用状態 |
| 商談 | 受注に向けてどこまで進んだか | ステージ、金額、完了予定日 | 申込・参加・欠席の履歴 |
この分離が必要なのは、同じ人が複数のキャンペーンへ参加できるからです。Aウェビナーでは参加済み、B展示会では招待済みという状態を、リード本体の一つの項目では表せません。イベントリード全体の要件は、展示会・イベントリード管理の要件一覧と合わせて整理すると、取得項目とSalesforceの役割分担を決めやすくなります。
イベント用ステータスとRespondedをどう決めるか
Salesforceは、イベント向けの例としてInvited、Registered、Attendedを挙げ、DeclinedやNo Showを含めるか検討するよう案内しています。ただし、組織内でキャンペーンごとに別の表記を作ると横断集計できません。キャンペーンメンバーステータスの公式ガイドも、キャンペーン種別ごとに一つの共通セットを決め、文書化することを推奨しています。
最初は5〜7個程度に絞ります。値を増やす基準は「担当者の次の行動が変わるか」「レポートで別集計する必要があるか」です。「申込フォーム送信」と「申込済み」のように意味が同じ値を増やさず、Zoom、展示会受付、フォーム、CSVなど異なる入力元を同じ状態へ変換します。
| 推奨ステータス | 意味 | Responded例 | 次の処理 |
|---|---|---|---|
| 追加済み | 対象者として登録したが、本人の反応は未確認 | いいえ | 招待または案内対象へ入れる |
| 招待済み | 案内を送った | いいえ | 申込期限まで反応を待つ |
| 申込済み | 本人が参加登録した | はい | 確認連絡と参加案内を送る |
| 参加済み | 受付・視聴など参加を確認した | はい | お礼と内容に沿ったフォローへ進める |
| 欠席 | 申込後に参加を確認できなかった | 運用定義による | 録画・資料案内や再招待へ回す |
| 辞退 | 本人から不参加の意思表示があった | はい | 理由に応じて別日程または停止へ回す |
| 個別相談希望 | 営業フォローを明示的に希望した | はい | 担当者と期限付きタスクを作る |
Respondedは「見込みが高い」「好意的だった」という評価ではありません。キャンペーンに対して意味のある応答があったかを集計するフラグです。辞退は売上につながらなくても明確な応答です。欠席をRespondedに含めるかは、申込時の応答を維持したいのか、最終参加だけを数えたいのかで決めます。両方を見たい場合は、Respondedだけに頼らず「申込済み数」「参加済み数」をステータス別に集計します。
CampaignMemberStatusの公式オブジェクト仕様では、各キャンペーンに既定ステータスと、HasRespondedがtrueのステータスが必要です。既定値は「追加済み」のような未反応状態にし、データ取込直後から反応済みとして数えないようにします。
参加状況・行動ログ・営業進捗を分ける
メンバーステータスは基本的に現在値です。資料を閲覧した、アンケートに回答した、架電した、商談化したという行動をすべてステータスへ変換すると、更新のたびに前の状態が見えなくなります。たとえば「参加済み」を「資料閲覧済み」で上書きすると、参加者数の集計が崩れます。
| 情報 | 保存先の考え方 | 理由 |
|---|---|---|
| 招待・申込・参加・欠席 | Campaign Member Status | キャンペーン内の現在地として横断集計しやすい |
| メール開封・リンククリック | MAのエンゲージメント履歴または活動 | 複数回発生し、時系列で見る必要がある |
| 資料閲覧・アンケート回答 | 活動・カスタム項目・回答レコード | 内容や日時を保持し、参加状態を上書きしない |
| 架電結果・次回予定 | Task、活動履歴 | 担当者、期限、完了条件を持てる |
| MQL・SQL・商談化 | リード状態、商談、必要な資格判定項目 | 一つのキャンペーンを越えた営業進捗だから |
Salesforceの公式ヘルプでは、顧客が施策に反応してもステータスは自動では変わらず、手動、一括更新、Account Engagementの自動化などで適用すると説明されています。したがって、申込フォーム、ウェビナーツール、受付アプリから何が届いたらどの状態へ変換するかを、連携仕様として明示する必要があります。
既存リードの照合、活動履歴、担当通知まで含む入力設計は、フォーム入力をSalesforceへ連携する実例が参考になります。連携元の言葉をそのままSalesforceへ増やすのではなく、正規化してから更新することが重要です。
ステータス変更を営業フォローへつなげる6ステップ
営業への引き渡しは、ステータスを更新した事実だけでは完了しません。対象者、担当者、期限、次の行動が作られ、完了を追える状態まで設計します。
- キャンペーン種別と成果を固定する
ウェビナー、展示会、個別相談会、メール施策を分け、それぞれで何を反応とみなすか、最終的に誰へ渡すかを決めます。イベントごとの独自語ではなく、種別ごとの共通値を作ります。 - 既定値と遷移表を作る
取込時の既定値、更新できる次の状態、戻してよい条件を表にします。参加済みを誤って招待済みに戻さないよう、入力元の優先順位と更新時刻も決めます。 - Respondedと集計指標を分ける
意味のある応答をRespondedに設定し、登録率、参加率、相談希望率はステータス別レポートで計算します。一つの反応数にすべての成果を背負わせません。 - 更新元を一つずつ対応付ける
フォーム送信、受付チェック、配信ツールの参加ログ、担当者入力、CSV取込ごとに、対象レコードの特定キー、更新値、重複時の処理、失敗時の再実行方法を決めます。 - 営業タスクの発火条件を決める
「個別相談希望になったら当日中」「参加済みかつ対象企業条件を満たしたら翌営業日まで」のように条件と期限を固定します。SalesforceはレコードトリガーフローでCampaign Memberを更新する例を公開しており、Statusの変更を入口に関連レコードを扱えます。実装時は再更新のループと既存タスクの重複作成を防ぎます。 - テスト用キャンペーンで集計と通知を確認する
追加、申込、参加、欠席、辞退、相談希望を少数レコードで再現し、Responded数、レポート、タスク、担当通知、再取込を確認します。本番イベントを最初のテストにしません。
営業への渡し方を設計するときは、イベント後の架電や次回アクションまで扱うイベントフォローとSalesforce活動履歴の連携例も確認すると、ステータスと活動の境界を具体化できます。FlowやApexを使う場合は、入力・出力・副作用を小さく分けるSalesforce自動化の実装手順が重複更新の防止にも役立ちます。
運用開始後に崩れやすい点を点検する
最も多い崩れ方は、担当者が新しいイベントのたびに独自ステータスを追加することです。「来場」「出席」「参加」「視聴完了」が混在すると、同じ反応を一つのレポートで数えられません。キャンペーンの作成者には共通テンプレートを使ってもらい、新しい値は申請制にします。
稼働中の値名やResponded設定を直接変えるのも危険です。Salesforceの公式ガイドは、レポートや自動化で使っているステータスと応答設定を変更すると、利用箇所で問題が起き、レポート統計の再計算につながると注意しています。変更が必要なら、影響するレポート、Flow、連携マッピングを先に調べ、テスト、移行、旧値の停止を段階化します。
| 点検項目 | 確認頻度 | 異常の例 | 対応 |
|---|---|---|---|
| 値の表記 | キャンペーン作成時 | 参加・出席・来場が混在 | 種別テンプレートへ統一する |
| Responded設定 | 公開前と月次 | 招待済みが反応数へ入る | 判定表と実レコードを照合する |
| 連携エラー | 開催前後は日次 | 申込済みなのに追加済みのまま | 失敗キューから再実行する |
| 営業タスク | 当日または翌営業日 | 相談希望に担当・期限がない | 割当ルールと重複防止キーを見直す |
| 履歴 | 月次 | 誰がいつ値を変えたか分からない | 変更イベントまたは監査用レコードを残す |
キャンペーンメンバーは標準の項目履歴管理でStatusの変更履歴をそのまま追えません。Salesforceのキャンペーンメンバーステータス履歴の公式説明も、標準機能だけでは履歴取得できず、要件に応じたカスタム実装が必要としています。監査が必要なら、変更前後、変更日時、更新元、実行ユーザーまたは連携処理、理由を別レコードや連携ログへ残します。
また、Member Status Update DateはStatusだけでなくCampaign Memberの他項目を更新した場合にも変わるとSalesforceは説明しています。この日付だけを「最後にステータスが変わった時刻」と解釈せず、厳密な履歴は専用ログで確認します。
よくある質問
キャンペーンメンバーステータスとリードステータスの違いは何ですか？
キャンペーンメンバーステータスは、特定の施策に対する招待・申込・参加などを表します。リードステータスは、その人との営業関係全体の進捗を表します。同じリードが複数キャンペーンで別状態を持てる点が大きな違いです。CRM全体の役割はCRMの基本とSFA・MAとの違いで確認できます。
Respondedはどの時点で「はい」にしますか？
本人から意味のある応答があった時点です。イベントでは申込、参加、辞退、個別相談希望などが候補です。単なる対象者追加や招待送信は通常含めません。欠席を含めるかは、申込への応答を数えるのか、最終参加だけを数えるのかで統一定義を作ります。
イベントでは何個のステータスを用意すべきですか？
数よりも、次の行動と集計が変わるかで決めます。多くの運用では、追加済み、招待済み、申込済み、参加済み、欠席、辞退、個別相談希望の5〜7個程度から始めると管理しやすくなります。
申込や参加でステータスは自動更新されますか？
標準では、顧客が反応しただけで自動的に変わるわけではありません。手動、一括更新、Account Engagement、Flow、外部ツール連携など、どの入力がどの状態へ更新するかを実装します。失敗時の再処理と重複更新の防止も必要です。
同じ人が複数イベントへ参加した場合はどうなりますか？
キャンペーンごとに別のCampaign Memberレコードを持つため、イベントごとに異なるステータスを保持できます。人の属性や営業全体の進捗はリード・取引先責任者側、各イベントの反応はキャンペーンメンバー側で管理します。
ステータスの変更履歴は標準機能で確認できますか？
Campaign Memberでは標準の項目履歴管理だけでStatus履歴を十分に追えません。監査や連携障害の調査が必要なら、変更前後、時刻、更新元、理由をカスタムオブジェクト、プラットフォームイベント、連携ログなどへ残します。
関連ページと関連記事
キャンペーンメンバーの値だけを決めるのではなく、イベントリードの取得、Salesforceへの登録、営業活動、CRM全体の正本をつなげて設計すると、集計とフォローが同じデータで回ります。
- 展示会・イベントリード管理の要件一覧：イベントで取得する情報とCRM連携の全体要件を確認できます。
- フォーム入力をSalesforceへ連携する実例：重複確認、レコード更新、担当通知の流れを整理できます。
- イベントフォローとSalesforce活動履歴の連携例：参加後の架電結果と次回アクションの残し方を確認できます。
- Salesforce Flow・Apex自動化の実装手順：更新条件、入出力、例外処理を小さく設計する考え方を確認できます。
- CRMとは何か：キャンペーン、リード、活動、商談を含む顧客管理全体の役割を整理できます。
Salesforceのイベント反応と営業フォローを整えたい場合
イベント申込、参加、欠席、相談希望を共通ステータスへ変換し、Salesforceの担当割当、タスク、活動履歴まで一連の運用として設計すると、集計のためのデータと営業が動くためのデータを両立できます。ファネルAiでは、現在のフォーム、イベントツール、Salesforce項目を前提に、値の統一から連携・通知まで整理できます。
