Salesforce Flow チケット当落メール後のフォロータスク自動化の考え方
目次 クリックで開く
イベント運営や限定キャンペーンにおいて、チケットの「当選・落選」が確定した後のオペレーションは、単にメールを送信して終わりではありません。当選者には入金確認や参加確定の督促タスクを、落選者にはキャンセル待ちの案内や次回イベントへの誘導タスクを、それぞれ適切なタイミングで割り当てる必要があります。
これらのプロセスを手動で行うと、対応の遅れや漏れが発生し、顧客体験（CX）の低下だけでなく、収益機会の損失を招きます。本記事では、Salesforceの「Flow（フロー）」を活用し、ステータス変更をトリガーにフォロータスクを自動生成する、実務に耐えうる設計手法を詳説します。
Salesforce Flowでチケット抽選後のフォローを自動化すべき理由
抽選イベントの運用において、最も負荷がかかるのは「通知直後」です。数千人、数万人規模の応募者に対して一斉に抽選結果を反映させた際、その後のアクションが個人の記憶やスプレッドシート管理に依存していると、必ずミスが発生します。
手動管理による「フォロー漏れ」と「対応遅延」のリスク
例えば、当選後に期日までに入金がないユーザーを特定し、個別に電話やメールでフォローする業務を考えてみましょう。Salesforce上のステータスを一つずつ確認し、手動で「ToDo」を作成していては、入金期限が過ぎてから気づくといった事態になりかねません。
ステータスに応じた「ToDo」自動生成のメリット
Flowを活用すれば、レコードのステータスが「当選」に更新された瞬間に、期日が3日後に設定された「入金確認タスク」を営業担当者や事務局に自動で割り当てることが可能です。これにより、担当者は「次に何をすべきか」を考える必要がなくなり、Salesforceを開いた瞬間に優先順位の高いタスクから着手できるようになります。
こうしたCRMデータの活用は、単なる事務効率化に留まりません。顧客の行動履歴に基づいた適切なアプローチは、成約率やリピート率に直結します。
【図解】SFA・CRM・MA・Webの違いを解説。高額ツールに依存しない『データ連携の全体設計図』でも解説している通り、各ツールの責務を明確に分けることが、自動化の第一歩となります。
実装前に整理すべきオブジェクト設計とデータフロー
Flowを構築する前に、どのオブジェクトにデータを保持し、どのレコードをトリガーにするかを決定する必要があります。
標準オブジェクト（キャンペーン）かカスタムオブジェクトか
一般的には、以下の2つのパターンが多く見られます。
- パターンA：キャンペーンメンバーを使用
Salesforceの標準機能である「キャンペーン」と「キャンペーンメンバー」を利用する方法です。セミナー管理など、標準的なイベント運営に適しています。
- パターンB：カスタムオブジェクト（抽選・申込管理）を使用
「1つのイベントで複数の券種がある」「同行者情報を保持する」など、データ構造が複雑な場合は、独自のカスタムオブジェクトを設計します。
メール送信とフォロータスクを連動させるデータ構造
自動化のゴールは、「メール送信」と「タスク作成」のセット実行です。Flow内では、ステータスが「当選」になった場合にのみ、当選通知メールを送信（Email Action）し、同時に「ToDo」レコードを作成するロジックを組みます。
【ステップ別】フォロータスク自動化Flowの構築手順
ここでは、実務で最も汎用性の高い「レコードトリガーフロー」を用いた構築手順をステップバイステップで解説します。
ステップ1：レコードトリガーフローの起動条件設定
まず、トリガーとなるオブジェクト（例：キャンペーンメンバーまたはカスタム申込オブジェクト）を選択します。
- 設定タイミング: レコードが更新されたとき
- 条件の要件: 「すべての条件に一致 (AND)」
- フィールド: ステータス（Status__c）
- 演算子: 次の値に一致する
- 値: 当選（または落選）
- 更新されたレコードでフローを実行するタイミング: 条件を満たすようにレコードを更新したときのみ
ステップ2：当選・落選の条件分岐（決定要素）の作成
「決定」要素を追加し、ステータスの値に応じて処理を分岐させます。
「当選ルート」と「落選ルート」、そして「それ以外（デフォルト）」を定義します。これにより、1つのFlow内で異なるフォローシナリオを一元管理できます。
ステップ3：一括処理（バルク処理）を意識したタスク作成ロジック
重要： 単一レコードの更新であれば「レコード作成」要素を直接配置しても動作しますが、データローダなどで一括更新を行う場合、ガバナ制限に抵触する恐れがあります。SalesforceのFlowは自動的にバルク化されますが、ループ処理を組む場合は「ループ内でレコード作成を行わない」のが鉄則です。
ステップ4：メールアラートまたはメール送信アクションの組み込み
「アクション」要素からメール送信を設定します。事前に作成した「メールテンプレート」を呼び出すか、Flow内の「テキストテンプレート」を使用して、宛先（メールアドレス）、件名、本文を指定します。
高度な顧客対応を自動化する場合、メールだけでなくLINEを活用するケースも増えています。
高額MAツールは不要。BigQueryとリバースETLで構築する「行動トリガー型LINE配信」の完全アーキテクチャを参考に、通知チャネルを拡張する設計も検討に値します。
実務で差が出る「ガバナ制限」回避とエラーハンドリング
Salesforce管理者として最も避けるべきは、本番環境で「Limit Exceeded（制限超過）」エラーを発生させることです。
ループ内でのDML操作を避けるためのコレクション変数活用
もし、親レコード（イベント）が「終了」になった際に、紐づく数百人の「落選者」に対して一括でタスクを作るようなロジックを作成する場合、以下の手順を踏んでください。
- 「割り当て」要素を使用し、タスクの値を設定した単一レコード変数を作成する。
- その変数を、レコードコレクション変数（リスト）に「追加」する。
- ループの外側で、その「コレクション変数」を使用して一括で「レコード作成」を実行する。
これにより、データベースへのアクセス（DML操作）が1回に集約され、パフォーマンスが劇的に向上します。
処理失敗時の担当者への通知設定（フォルトパス）
万が一、入力規則違反などでタスク作成が失敗した場合に備え、「フォルトパス」を設定します。エラーが発生した際に、システム管理者にSlack通知を送る、あるいはエラーログオブジェクトにレコードを作成するなどの処置を施すことで、サイレントフェイルを防ぐことができます。
Salesforce Flow vs 外部ツール・MA連携の比較
Flowは強力ですが、全てのフォロー業務をFlowで完結させるのが正解とは限りません。配信規模やマーケティング要件に応じて、適切なツールを選定するための比較表を以下に示します。
| 比較項目 | Salesforce Flow | Marketing Cloud / Pardot | 外部MA / LINE連携ツール |
|---|---|---|---|
| 主な用途 | 社内業務プロセス、ToDo作成 | 高度なナーチャリング、大量配信 | マルチチャネル配信、SNS連携 |
| コスト | 標準機能（追加費用なし） | 高額（月額数十万円〜） | 中〜高（ツールによる） |
| 学習コスト | 中（Flowの知識が必要） | 高（専門スキルが必要） | 中（直感的なUIが多い） |
| メリット | リアルタイム性が高く、社内タスク管理に強い | 顧客行動に合わせた複雑な分岐が可能 | UIが使いやすく、開封率が高い |
| デメリット | 大量のメール配信には向かない | 設定が複雑で、導入まで時間がかかる | Salesforceとのデータ同期設計が必要 |
自社の要件が「社内タスクの徹底」にあるならFlowが最適ですが、より広い顧客体験の最適化を目指すなら、
LIFF・LINEミニアプリ活用の本質。Web行動とLINE IDをシームレスに統合する次世代データ基盤のような、モダンなアーキテクチャへの投資も検討すべきでしょう。
チケット抽選結果パターン別 Salesforce Flow設計 × 後続タスク自動化 × 顧客体験設計 早見表
前のセクションでFlowの構築手順を説明しましたが、チケット抽選のビジネスでは「抽選に当選した顧客」だけでなく、「落選した顧客」「キャンセル待ち顧客」「グループ申込で一部当選した顧客」など、結果パターンに応じた後続フローの設計が顧客体験の明暗を分けます。落選者へのフォローを適切に設計するかどうかで、次回の抽選への再エントリー率やブランドロイヤルティが大きく変わります。以下の表は抽選結果パターン別のFlow設計をまとめたものです。
| 抽選結果パターン | Salesforce Flowの処理設計 | 後続タスクの自動化設計 | 顧客体験設計のポイント | ガバナ制限・設計上の注意点 |
|---|---|---|---|---|
| 当選（全席確保） | 当選フラグ更新→チケット在庫の引き当て→支払い期限日フィールドの自動計算（当選通知から72時間後等）→当選通知メール/SMSの即時配信 | 支払い期限72時間前・24時間前・当日の3タイミングで支払い督促タスクをFlowで自動作成。支払い確認後にチケット発券処理へ移行するサブFlowを起動。期限内未払いの場合は自動キャンセル処理とキャンセル待ち顧客への繰り上げFlowを起動 | 当選通知メールには「何時まで」という支払い期限を明確に記載する。期限の7〜14日前通知ではなく72時間前という短期設定が一般的なチケットビジネスでは、支払いリンクを通知メール本文に直接埋め込んで摩擦ゼロの決済導線を設計する | 大規模抽選（1万件以上）では当選判定と通知配信を同時にFlowで処理するとガバナ制限（1日あたりのメール送信数上限：組織の規模に応じて設定）に抵触するリスクがある。Apex Batchまたはスケジュール実行で分割処理する設計が必要 |
| 落選（全枠落選） | 落選フラグ更新→落選通知メールの配信→落選顧客をキャンセル待ちオプションへの誘導フローに分岐。次回公演・関連イベントの案内リストへの自動追加 | 落選通知配信後に「関連コンテンツ推奨タスク」を自動作成してMarketing Cloudのジャーニーに連携。落選から30日・60日後に次回イベント情報の配信をスケジュール。落選履歴をSalesforceに記録して、次回抽選時の優先当選ロジックのインプットにする（リピーター優遇設計） | 落選通知は「残念ですが」という謝罪ではなく「次の機会にご参加ください」という前向きな文言設計が再エントリー率に影響する。キャンセル待ち登録の導線を落選通知に含めて、ページ遷移なしでキャンセル待ちに登録できるCTAを設ける | 落選者リストは個人情報であり、マーケティング利用には申込時の同意取得が前提となる。落選通知後のリマーケティング配信は「イベント関連情報の配信に同意済み」フラグを持つ顧客のみに限定するセグメント設計が必須 |
| グループ申込で一部当選 （4名申込→2名分のみ当選） |
グループ代表者への一部当選通知→当選枚数と落選枚数の内訳を明記→「全員分当選にはならなかった場合どうするか」のオプション選択（①当選分のみ購入②全員落選として辞退）のレスポンスを記録するFlowを設計 | オプション選択のレスポンスをFlowで分岐処理。辞退選択の場合は当選枠を次のキャンセル待ち顧客に自動繰り上げ。購入選択の場合は一部当選の支払いフローに接続。グループ申込の残席をキャンセル待ち枠として処理する | 一部当選は顧客にとって最も困惑するシナリオであるため、通知文に「グループ全員分をご用意できなかった場合の対応方針」を明確に記載する。回答期限を当選通知から48時間以内に設定して、無回答の場合は辞退とみなす設計で在庫の塩漬けを防ぐ | グループ申込のデータモデル設計（申込オブジェクト×申込者オブジェクトの親子関係）が不明確だと、一部当選のFlow処理が複雑化する。グループIDフィールドを申込オブジェクトに設けて、同一グループの申込をFlowで集約できる設計が前提 |
| キャンセル待ち繰り上げ当選 | キャンセル発生イベントをトリガーにキャンセル待ちリストから先頭顧客を取得→繰り上げ当選通知の即時配信→支払い期限を通常より短縮設定（24〜48時間）→期限内未払いは次順位に自動繰り下げ | 繰り上げ当選の支払い督促は通常より高頻度（12時間後・24時間後・終了3時間前）に設定してキャンセル率を最小化。繰り上げ当選の辞退・未払いが3回以上の顧客は次回の抽選優先度を下げるスコアリングロジックをFlowに組み込む | 繰り上げ当選通知は速報性が命であるため、Push通知またはSMSを主チャネルにしてメールをサブに設計する。「今すぐ支払う」ボタンを通知に直接埋め込んで支払い完了までの手順を2タップ以内に設計する | キャンセル待ちの繰り上げ処理は短時間に集中するため、同時実行のFlow数がガバナ制限（並列処理数の上限）に達する可能性がある。大規模イベントでは繰り上げ処理をキューイングして順次処理する設計を採用する |
この表で最も設計が見落とされやすいのが「落選顧客へのリマーケティング動線」です。当選フローの設計に注力するあまり、落選した顧客の次のアクションを設計しないと、落選通知を受けた顧客は完全にブランドとのつながりを失います。落選通知にキャンセル待ち登録・次回イベント情報の案内・関連コンテンツへの誘導を含めることで、落選体験をブランドへの再エンゲージメントの機会に転換できます。Flow×Marketing Cloudの連携でこの動線を自動化することが、ファンビジネスでの長期LTV設計の核心です。
運用の注意点とセキュリティ対策
自動化を本番環境にデプロイする前に、以下の2点は必ず確認してください。
二重実行の防止策（実行済みフラグの管理）
誤って同じレコードのステータスを再度「当選」に更新してしまった際、また同じメールが飛び、同じタスクが作られるのは避けなければなりません。「フォロー実行済みフラグ（チェックボックス）」等のカスタム項目を用意し、Flowの開始条件に「フラグがFalseであること」を加え、処理の最後でTrueに更新する設計が推奨されます。
Sandboxでの徹底したメール送信テスト
当選・落選のロジックが逆転していた場合、取り返しのつかないクレームに発展します。
Salesforce公式ドキュメント（メール送信の制限と有効化）に基づき、Sandbox環境での「メール送信のアクセス権」を調整した上で、実在するテスト用アドレスに対して、期待通りの本文が送信されるか必ず実機確認を行ってください。
また、フォロー後の「入金」まで自動化の範囲を広げる場合は、会計システムとの連携も視野に入ります。
Salesforceとfreeeを繋いでも「サブスク売上」は自動化できない。前受金管理とバクラクを活用した一括請求アーキテクチャで触れているように、入金確認の自動化は、ビジネス全体のキャッシュフロー健全化に大きく寄与します。
Salesforce Flowを用いた自動化は、正しく設計すれば「24時間365日働く優秀な事務局」になります。まずは最もシンプルなタスク生成から着手し、徐々に複雑なシナリオへと拡張していくことをお勧めします。
Salesforce活用・営業DXとデータ連携のご相談
Salesforceの定着支援や営業プロセスの可視化、基幹・会計システムとのデータ連携までをまとめて支援します。現在の設定や連携方式が最適かを確認したい、という導入前後のセカンドオピニオンにも対応しています。
CRM・営業支援
Salesforce・HubSpot・kintoneの選定から導入・カスタマイズ・定着まで一貫対応。営業生産性を高め、商談化率を改善します。