自動化レシピ：一般的な設定

Last updated: September 2, 2026

コピーできる既成の自動化設定で、トリガーの選択、実行時、追加すべき条件、推奨されるアクション、避けるべき落とし穴を含みます。提案のフォローアップ（閲覧、承認、有効期限）、学生への保険ポリシーの開始日と終了日のリマインド、パイプライン段階の変更への対応をカバーします。これは生きたページであり、新しいトリガーや条件がリリースされるたびにレシピが追加されていきます。

このページでは、設定 > 採用 > 自動化で構築できる一般的な自動化設定について説明します。各レシピは同じ構成を持ちます — 何を達成するか、選択するトリガー、実行タイミング、追加すべき条件、推奨アクション、注意点 — これにより必要なものを素早く見つけて、数分で構築できます。

新しいトリガーや条件がリリースされるたびに、ここにレシピが追加されていきますので、これを固定リストではなく成長するライブラリと見なしてください。役立つものを作成し、まだここにない場合は、別のセクションとして追加できます。

利用可能な内容の完全なリストについては、下部のトリガー、条件、アクションのリファレンスを参照してください。

レシピ1 — 提案のフォローアップ

達成できること： 提案を手動で追いかけることなく進められます。学生が提案の有効期限前に促し、見たが行動しなかった場合にフォローアップし、承認した瞬間に内部で引き継ぎます。

選択するトリガー： 追いたい行動ごとに1つの自動化を設定します。これは提案グループから選びます：

  • 提案閲覧 — 学生が提案を初めて開いたとき。
  • 提案承認 — 学生が承認したとき。
  • 提案の有効期限日 — 提案の期限前、当日、または期限後に実行される日付ベースのトリガーです。

実行タイミング：

  • 提案閲覧 は、学生が提案を最初に開いたときに発火し、その後の閲覧では再発火しません。
  • 提案承認 は、実際に承認に遷移したときに発火します。
  • 提案の有効期限日 は、期限日を基準に実行されます — 促しの場合は、数日前に設定します。日付ベースのトリガーを作成するときは、ルールを平易な言葉で再提示し、適切なオフセットと方向を確認できるようにします。

追加すべき条件： 自動化を絞り込み、対象の学生だけに発火させます — 例えば学生の国籍や、提案のフィールド（例：目的地やプログラムタイプ）に基づきます。同じフィールドに複数回条件を設定することも可能です（例：「3つの条件 · いずれか」）。すべての条件を満たす必要がある場合は「すべて」を選び、1つだけで良い場合は「いずれか」を使用します。

推奨されるアクション：

  • 期限前：学生に提案へのリンク付きリマインダーのメールを送信し、担当カウンセラーに電話するタスクを作成します。
  • 承認時：おめでとうメールを送信し、次のステップ（預金、書類）のタスクを作成し、Webhookまたは内部通知を通じてチームに通知します。
  • 閲覧されたが承認されていない：Proposal Viewedの自動化とフォローアップメールを一定時間後に組み合わせるか、有効期限日のお知らせを使ってギャップを埋めます。

注意点： Proposal Viewedは最初の開封時のみ発火します — 5回再度提案を開く学生でも1つのイベントしか生成されませんので、繰り返し閲覧を想定したロジックは作らないでください。 Proposal Acceptedは一度だけ、遷移時に発火します — 学生がオプションAを承認し、その後オプションBに切り替えた場合でも、それは1つのイベントであり、2つではありません。したがって、承認の自動化は切り替え時に再度実行されません。

レシピ2 — 学生に保険ポリシーの日付をリマインド

達成できること： 学生は保険の開始前と終了前に通知を受け取り、アクティブなカバーのもとで旅行し、更新時期を把握できます。また、チームに適切なタイミングで書類を確認する促しを行います。

トリガーの選択： 新しいInsuranceカテゴリーのトリガーピッカーから：

  • 保険開始日 — 到着前や「もうすぐカバー開始」メッセージ用。
  • 保険終了日 — 更新と有効期限のリマインダー用。

実行タイミング： どちらも日付に基づくため、該当日より前、当日、または後に設定します — 例えば、保険開始日の7日前や保険終了日の14日前などです。ビルダーは設定内容を平易な言葉で再表現するため、保存前にオフセットが意図した通りに読まれているか確認できます。

追加条件： Insurance destination countryを使って国別の指示を送信し、Insurance providerを使って提供者ごとに異なる表現や書類を管理します。両方必要な場合は併用し、ルールが正しく設定されているかカードの条件サマリーで確認してください。

推奨アクション：

  • 学生に保険の詳細と持ち物をメールで案内します。
  • カウンセラーに学生の書類確認のタスクを作成します。
  • 終了日には更新促進のメールを送り、カバー延長について話し合うタスクを作成します。

注意点： 保険のトリガーは確定済みの予約のみに適用されます。未確定の予約に付随するポリシーはこれらのトリガーを発火しませんので、保留状態の学生には何も起こりません — このレシピだけに頼らず、他の確認方法も併用してください。

レシピ3 — パイプラインステージの変更に反応

達成できること： パイプラインの動きを自動的にアクションに変換 — 学生がステージに入ったときのウェルカムメッセージ、進行に伴う引き継ぎタスク、ステージから離れたり戻ったりしたときの内部通知を行います。

トリガーの選択: パイプラインステージの変更。

実行タイミング: 学生のパイプラインステージが変更されるたびに。次に、トリガーの条件を使って関心のある変更を決定します。

追加する条件: "ステージに移動"を使用して、学生が特定のステージに到達したときにアクションを実行し、"ステージから移動"を使用して、離れたときにアクションを実行します。2つを組み合わせて、特定の遷移（あるステージから別のステージへ）をキャッチし、国籍、目的地、プログラムなどの他の条件を追加して、ルールを適切な学生に限定します。

推奨されるアクション:

  • 新しいステージに移動: ステージに適したメールを送信し、次のタスクを担当者に作成します。
  • アクティブなステージから逆方向に移動: マネージャーに通知するか、レビュータスクを作成します。
  • いかなるステージの変更でも: Webhookを発火させて、レポートやCRMが同期されるようにします。

注意点: 一括再割り当てはトリガーされません。 ステージが一括で変更された場合、自動化は実行されないため、大規模な整理や移行はログに静かに記録されます。フォローアップメールやタスクが作成されないことを前提に、一括ステージ移動を計画し、それらは手動で処理してください。

関連