ウェルカムシーケンスは、新しい購読者が次に何をすればよいかを知る手助けをします。SaaSなら、最初のプロジェクトを作成することかもしれません。ECストアなら、商品のラインナップを知ること。ニュースレターなら、何がどのくらいの頻度で届くのかを知ることかもしれません。

まずは、登録時にした約束から考えましょう。その後のメールはすべて、その約束を果たす助けになるべきです。タイミングやメッセージの数は、製品とオーディエンスによって異なります。以下の例は、テストの出発点として使ってください。ウェルカムシーケンスは、AIでメールを自動化するガイドで紹介している、ライフサイクルフローの最初の1つです。

起点となるイベントを選ぶ

起点	最初のメッセージに適した内容	確認すること
アカウントの作成	セットアップの操作を1つ	メールアドレスの確認を先に済ませるべきか
メールアドレスの確認完了	歓迎のあいさつと、製品への直接のリンク	確認メールと内容が重複しないようにする
ニュースレターの購読	届く内容の案内と、役に立つ例を1つ	受信者の同意と、選んだトピック
ストアへの会員登録	商品、購入の案内、または約束したオファー	オファーの実際の条件と有効期限

Brew では、バックエンドから送るカスタムイベントや、Supabase や Clerk などの対応する連携サービスを起点に、フローを開始できます。ペイロードは選択したトリガーのスキーマに沿って組み立て、そのトリガーの実際のIDを使ってください。

SaaSのウェルカムメールの例

メール	タイミングの目安	役割	送信時点の対象条件
ウェルカム	登録後、またはメールアドレスの確認後	最初のプロジェクトの作成を後押しする	新規アカウント
セットアップのサポート	2日目	短い例を1つ見せる	まだアクティベーションしていない
次のステップ	アクティベーション後	次に役立つ行動を紹介する	アクティベーション済み
トライアルのリマインダー	トライアル終了の前	次に何が起きるかを説明する	まだトライアル中で、支払いをしていない
様子伺い	適切な間隔をあけて	サポートを申し出る	引き続き対象で、受信の許諾もある

各メールは、1つの行動を軸に書きましょう。実在するリンク先のURL、明確な件名、誰かが目を通している返信先アドレスを使います。ありきたりな緊急性の演出や、測定していない成果についての主張は避けましょう。

ニュースレターやECストアのウェルカムメールの例

ニュースレターの場合、最初のメッセージでは、約束した資料を届け、配信の頻度を伝え、代表的な記事を紹介できます。その後のメッセージでは、受け取るトピックの設定方法を説明したり、書き手を紹介したりできます。ニュースレターなら、2通目を送る理由づけのために、SaaSのようなアクティベーションのファネルを用意する必要はありません。

ECストアの場合は、まず約束したオファーを届け、それから購入に役立つ案内をします。対象外の商品や有効期限は、正確に書きましょう。購入すると、残りの割引のリマインダーは不要になる場合があるため、対象条件のチェックには購入状況を含めます。

フォローアップを書く前に、終了条件を決める

それぞれのメッセージを止めるべき条件を決めましょう。アクティベーション、購入、オファーの期限切れ、アカウントの削除、配信停止、プランの変更などです。そのうえで、そのルールを、現在の状態を実際に読み取るシステムに実装します。

Brew のイベントトリガー型のフローでは、payload.activated を使う条件は、元のイベントを読み取ります。contact.activated を使う条件は、ノードが実行される時点（「待機」のあとを含む）の、Brew のコンタクトフィールドの現在の値を読み取ります。フィールドを宣言して同期し、その値に依存する各リマインダーの前に条件を置きましょう。コンタクトの更新や、あとから届いたイベントによって、以前に開始した実行が自動的にキャンセルされることはありません。

同期していないアカウントのデータや、特定の購入に左右される対象条件については、自社のアプリケーションでチェックを予約しましょう。メッセージの送信時点で正となるレコードを読み取り、ルールにまだ当てはまる場合にだけ、リマインダーの対象であることを示す別のイベントを送信します。オートメーションを作成するもご覧ください。

シーケンスを作成して確認する

Brew で、トリガー、オーディエンス、望む行動、トーンを説明しましょう。フローギャラリーにある公開例から始めることもできます。ただし、そのタイミングはあくまで参考です。同じスケジュールが自社のオーディエンスにも効果的だという根拠にはなりません。

生成されたフローのグラフと、すべてのメールを確認します。リンク、差出人、パーソナライズの代替値、ドメインの用途を確かめましょう。確認用のメッセージと、販促を含むオンボーディングのメッセージとでは、満たすべき要件が異なる場合があります。米国の「主な目的」による判断基準はFTCのガイドで、認証、迷惑メール率、配信停止のルールは Gmail の送信者の要件で説明されています。

うまくいくケース以外もテストする

登録、重複したイベント、パーソナライズ用のデータの欠落、対象外の受信者をテストしましょう。コンタクトの条件については、待機中に同期対象のフィールドを更新し、リマインダーがスキップされることを確認します。フィールドが欠けている場合もテストしましょう。アプリケーション側で予約したリマインダーについては、チェックの前にアクティベーションや購入を行い、リマインダーのイベントが送信されないことを確認します。配信停止の処理と配信結果も確かめておきましょう。

公開するのは、メッセージと対象条件のチェックを確認してからにしましょう。配信やクリックのデータとあわせて、セットアップの完了や初回の注文など、シーケンスで後押ししたい行動を追跡します。その行動につながっているメッセージは残し、それ以外は見直しましょう。

実装の例については、Cursor からオンボーディングを構築する方法と、製品イベントを使ったトライアル転換のシーケンスをご覧ください。