旅行向けプッシュ通知自動化：5つのワークフローブループリント

火曜日の午後、リテンションレビューは2時15分に終了しました。予約コンバージョン率は先四半期から3.6%から2.2%へと1.4ポイント低下しました。ロイヤルティチームはリカバリーメールの頻度が遅すぎると考えています。モバイルチームは、放棄された予約プッシュが価格下落アラートと重複していると考えています。どちらかが原因であると証明できる人はいません。会議後のSlackスレッドで2時間経過しても、全員が同意している唯一のことは、ダッシュボードが議論を解決するには十分に詳細ではないということです。

旅行のプッシュ通知自動化はこの議論の中心にありますが、リテンションチームの誰もそれをどのように擁護すべきか確信が持てません。予約確認の自動プッシュは、予約が完了したときに送信されます。放棄された予約トリガーは24時間後に同じ旅程を再通知しますが、その旅程は、運賃が夜間に変更されたため、旅行者が放棄したときの価格ではなくなることがあります。2年前に設定された解約警告トリガーは、アプリのDAUが低下したときに送信されますが、加入者が現在旅行中であり、実際には解約しているのではなく、休暇中であることを認識していません。互いを認識せず、旅行者が旅行ライフサイクルのどこにいるかの整合性の取れたビューを持たない3つの「自動化された」メカニズム。

この記事では、旅行プッシュ自動化が実際にどのようなものであるべきか（予約確認のブロードキャストに放棄された予約トリガーを追加したものではなく、ワークフローアーキテクチャ）を説明し、タイミング、運賃変更時の終了基準、ジオロケーショントリガーによる旅行中の処理、およびそれぞれを広告運用およびロイヤルティチームにとって擁護可能な項目に変える収益計算を備えた、5つの旅行形状のワークフローブループリントを提供します。

航空券の運賃変更時に「自動プッシュ通知」が収益を漏らしている理由

オートメーションという言葉は、eコマース、SaaS、出版業界で果たしてきたのと同じ、不当に得た仕事を旅行業界でも果たしてきました。ほとんどの旅行CRMチームが旅行の自動プッシュ通知について話すとき、彼らが意味するのはイベントトリガー型の一斉配信スケジューリングです。つまり、既知のイベントが発生すると通知が送信されますが、状態はなく、セグメンテーションもなく、タッチ間の待機もなく、終了条件もなく、そして最も重要なこととして、2回目のタッチが送信されるまでに根本的なオファーが無効になっている可能性があることを認識していません。

ワークフローはそれとは異なります。ワークフローは状態を持つマルチステップのジャーニーです。旅行者が予約を放棄したこと、どの運賃を見たか、現在その旅程でどの運賃が提示されているか、旅行のステータスがどうであるか、そしてどのような条件でジャーニーがキャンセルされるかを知っています。予約放棄ワークフローは、24時間後に単一のリマインダープッシュを送信するだけではありません。各タッチの前に運賃が有効かどうかを確認し、予約が完了した瞬間にワークフローを終了し、運賃が変更された場合は個別に終了します。なぜなら、運賃が現在529ドルになっているときに旅行者に「399ドルの予約を完了してください」と送信することは、回復した予約では決して正当化できない方法で信頼を破壊するからです。

最後の句が違いです。イベントトリガーには外部状態の記憶がありません。ワークフローにはあります。予約放棄自動化が運賃が変更された後も古い運賃で旅行者に繰り返し問い合わせ続けている場合、それは自動化ではありません。それはチェックするように指示されていないトリガーです。

中堅旅行CRMチームにとって、この区別は、リピート予約のLTVが複利で増加するか、運賃変更の瞬間の信頼を損なう間違いによって侵食されるかの違いです。3つのトリガーが並行して実行されると、3つのチャネルの摩擦が生じます。5つのワークフローが連携して実行されると、旅行者ごと、旅行段階ごとに1つのジャーニーが生成され、予約状態、運賃の有効性、旅行ステータスによって分岐および制限されます。このキーワードのページ1の検索結果は、問題を「旅行の5つのユースケース」として提示し、ツールのリスト記事で回答しています。それはあなたの火曜日のリテンションレビューが尋ねている質問ではありません。

旅行プッシュ通知ワークフローの構造

ブループリントの前に、語彙。旅行プッシュ通知ワークフローは6つのノードタイプから構築されます。それぞれの機能を知れば、すべてのブループリントは説明ではなく図として読めるようになります。

START。 エントリーポイント。STARTノードは、サブスクライバーイベント（booking_initiated、booking_abandoned、fare_changed、geolocation_changed、trip_completed）またはオーディエンスフィルター（lifecycle_stage、loyalty_tier、last_active）のいずれかによってワークフローがトリガーされる方法を定義します。ワークフローにはSTARTが1つだけあります。

WAIT。 遅延。WAITノードは、サブスクライバーを指定された期間（旅行中のリアクティビティの場合は数分、予約放棄のペース設定の場合は数時間、旅行前のケイデンスの場合は数日）またはサブスクライバー属性に関連付けられたwait_untilセマンティックを使用して特定のカレンダー時刻まで保持します — departure_date - 7 days、departure_date - 1 day、trip_completion_date + 1 year。Waitは、ワークフローが過去の既知のイベントだけでなく、将来の既知のイベントを尊重する方法です。

DECISION。 双方向分岐。DECISIONノードは、サブスクライバーごとの条件をチェックします。予約は完了したか、運賃はまだ有効か（予約システムが更新するサブスクライバー属性から読み取る）、ロイヤルティティアはシルバー以上か、旅行者は現在旅行中か。DECISIONノードは、イベントフィルターとオーディエンスフィルターを評価します。HttpRequestのレスポンスボディを直接消費しません。外部の状態をワークフローに取り込むパターンは、HttpRequestアクションが外部システムをトリガーし、外部システムがPushEngage REST API経由でサブスクライバー属性に書き戻し、DECISIONが属性を読み取るというものです。

SPLIT_PATH。 パーセンテージベースのフォーク。SPLIT_PATHノードは、設定されたパーセンテージに基づいてサブスクライバーをパスにルーティングします。予約放棄割引額のA/Bテストの場合は50/50、旅行前リマインダーの3方向送信時間テストの場合は33/33/34。勝者が見つかったら、そのパスを100%に昇格させます。

ACTION。 作業そのもの。ACTIONノードは、プッシュ通知を送信したり、サブスクライバーをセグメントに追加したり、カスタム属性を更新したり、予約システムまたはSMSゲートウェイにHttpRequestを発行したり、別のワークフローを開始したり、停止したりします。PushEngage Workflowsは11種類のアクションタイプをサポートしています。旅行で最も役立つのは、SendPushNotification、UpdateAttribute、HttpRequest、およびWorkflow.Start（旅行前、旅行中、旅行後の連鎖用）です。

END / EXIT。 終端。ENDは自然な結論を示します。EXITは早期終了を示します — 旅行者がもはや適格でなくなった場合のDecisionのNOパス、クールダウンルールがトリガーされた場合、または目標が達成された場合（予約完了、旅行キャンセル、運賃無効化）。

以下の各ブループリントは、これら6つの要素から構成されます。

旅行のための5つのワークフローブループリント

これらはテンプレートではありません。これらは実際の設計図です。それぞれにトリガー、実行タイプ、ノードシーケンス、終了基準、および移動するために構築された旅行維持メトリックがリストされています。それぞれをPushEngage Workflowsビルダーに読み込んで、1時間以内に最初のバージョンをリリースできます。従来の旅行プッシュ通知ガイドは、これらの設計図が実装するより広範なユースケースをカバーしています。

ブループリント1 — ウェルカム＋初回予約育成

• トリガー（START）： イベントPushEngage.Subscriber.Addedまたはbrowse_destination_page_view
• 実行タイプ： Single（90日ウィンドウごとに旅行者ごとに1回のウェルカムジャーニー）
• フロー: 人気デスティネーションへのウェルカムプッシュ → 1日待機 → 旅行タイプ（ビーチ、スキー、シティブレイク、ビジネス）に関するアンケートプッシュ → 2日待機 → 決定：購読者は予約を開始しましたか？ → はいの場合：予約が完了したら、予約完了ワークフローに引き継ぎ、それ以外の場合はブループリント2にチェーン → いいえの場合：厳選された3つのデスティネーションのおすすめプッシュを送信し、active_browsersセグメントに追加して終了
• 終了基準: 目標 booking_completed
• 旅行指標: 7日目の閲覧から初回予約へのコンバージョン率。

ブループリント2 — 運賃変更による離脱（予約放棄プッシュ通知自動化）

• トリガー（開始）: カスタムイベント booking_abandoned（itinerary_idペイロード付き）
• 実行タイプ: 並列複数（放棄された予約ごとにワークフローインスタンスが作成されます）
• フロー: 1時間待機 → アクション: itinerary_idの予約システム運賃チェックエンドポイントへのHttpRequest GET。予約システムは、数秒以内にPushEngage REST API経由で購読者属性に書き込みます — fare_status = valid または fare_status = invalidated — → 決定: オーディエンスフィルター fare_status = valid? → いいえの場合: 「運賃が変更されました。新しい価格の類似オプションはこちらです」というプッシュを送信して終了（信頼を損なわない、スムーズな再ルーティング） → はいの場合: 元の運賃でのリマインダープッシュ → 24時間待機 → HttpRequest運賃チェックを繰り返す、その後 fare_status = valid かつ booking_completed = false の決定 → はいの場合: 10%割引コード付きリマインダー#2 → 48時間待機 → より強力なオファー付き最終リマインダー → 終了
• 終了基準: トリガーのitinerary_idと一致する目標booking_completed またはオーディエンスフィルターfare_status = invalidated
• 旅行指標: 放棄された予約あたりの回復予約価値。これは、ページ上で最も正当化可能な収益ラインを持つワークフローです。予約放棄を減らすための6つのヒントの投稿では、このブループリントの手動戦術バージョンをカバーしています。ワークフローバージョンでは、戦術的な回復をブランドの信頼を維持する回復に変える運賃有効性終了が追加されています。

ブループリント3 — 旅行前育成（出発日計算）

これは、購読者属性に関連付けられたwait_untilセマンティクスを示す、旅行前のプッシュ通知ワークフローです。

• トリガー（開始）: カスタムイベント booking_completed（購読者属性にdeparture_dateを書き込みます）
• 実行タイプ: 予約ごと1回
• フロー: 出発日 - 14日まで待機 → 「ご旅行は2週間後です」プッシュ通知（パッキングの推奨事項と天気予報付き）→ 出発日 - 7日まで待機 → 追加収入プッシュ通知（座席アップグレード、部屋のアップグレード、レンタカー追加、空港送迎）→ 出発日 - 1日まで待機 → チェックインリマインダープッシュ通知（モバイル搭乗券リンク付き）→ 出発日まで待機 → ボンボヤージュプッシュ通知、終了
• 終了基準: 目標 予約キャンセル
• 旅行指標: 予約あたりの追加収入。7日前からのアプローチが追加収入にとって最も効果的な瞬間です。

ブループリント4 — 旅行中ジオロケーション（ジオロケーションプッシュ通知自動化）

• トリガー（開始）: カスタムイベント 位置情報変更（デバイスが新しい緯度/経度を報告したときにモバイルアプリによってトリガーされる）AND オーディエンスフィルター 旅行中 = true
• 実行タイプ: 複数並列
• フロー: 決定: 旅行者は目的地都市に到着しましたか？（オーディエンスフィルターは、加入者属性として保存されている目的地のジオフェンスに対して位置情報座標を比較しますか？）→ YESパス: アクション 地元のおすすめプッシュ通知（目的地に関連するホテル、レストラン、現地の活動）を送信、アクション 天気APIへのHTTPリクエスト → 天気アラートが必要な場合、アクション 天気通知を送信 → 終了 → NOパス: 終了（旅行者は移動中であり、目的地にはいません）
• サイレントアワー: 加入者のタイムゾーンを認識します。ワークフロー.md §9.4では、まず加入者のタイムゾーン、次にサイトのタイムゾーン、最後にUTCでサイレントアワーを解決します。旅行中のワークフローの場合、これはタイムゾーンがブランドの本拠地の市場ではなく、目的地の現地時間を尊重することを意味します。重要でないプッシュ通知はスキップを使用し、安全および天気アラートは配信を確実にするために再スケジュールを使用します。
• 終了基準: 目標 旅行完了
• 旅行指標: 旅行中のエンゲージメント率と旅行中の追加収入。注: 位置情報変更は組み込みのトリガータイプではありません — これは、デバイスの位置が更新されたときにモバイルアプリがトリガーするPushEngage.CustomEventであり、目的地でのチェックはアプリが維持する加入者属性に対するオーディエンスフィルターです。位置情報プッシュ通知の記事は、このブループリントが拡張するセグメンテーションの基盤をカバーしています。

ブループリント5 — 旅行後レビュー＋類似顧客再予約

• トリガー（開始）: カスタムイベント 旅行完了
• 実行タイプ: 複数シーケンシャル
• フロー: 3日間待機 → 目的地名を言及するレビューリクエストプッシュ通知 → 旅行完了日 + 365日（1年後）まで待機 → 「次の旅行の準備はできましたか？」プッシュ通知（以前の旅行タイプに基づいた類似の目的地オファー付き）→ 7日間待機 → 決定: 旅行者は予約を開始しましたか？ → YESパス: ブループリント1または2にチェーン → NOパス: 終了
• 終了基準: 新しい 予約開始イベント または 購読解除
• トラベル指標：12ヶ月のリピート予約率。これは最も長く実行されているブループリント（約13ヶ月）であり、LTVへの影響が最も大きいものです。前年比の類似パターンは、eコマースの購入後ウィンバックの旅行版であり、旅行購入者が実際に従う季節の周期に合わせて調整されています。

ライフサイクル段階セグメンテーション、A/Bテスト、目的地タイムゾーン別のサイレントアワー、終了基準はワークフロー内にあります

旅行プッシュ記事全体で支配的なパターンは、これらの4つの概念を「ベストプラクティス」としてリストすることです。これは、戦略投稿の最後に、それらを使用するキャンペーンから切り離された、一般的な箇条書きです。それは間違ったフレームです。それらはワークフローの隣にあるベストプラクティスではありません。それらはワークフローです。

コンセプト	ベストプラクティスとしてのフレーム（間違い）	ワークフローノードとしてのフレーム（正しい）
ライフサイクルステージのセグメンテーション	「旅行ステージ別に旅行者をセグメント化する」	サブスクライバー属性lifecycle_stage（閲覧中/予約開始済み/旅行前/旅行中/旅行後/休眠中）のDECISIONノード。旅行前の旅行者を補足的なプッシュに、旅行中の旅行者をジオロケーションワークフローに、旅行後の旅行者をレビューと類似のリピート予約にルーティングします。
A/Bテスト	「放棄された予約のコピーは常にA/Bテストを実施する」	50/50の割り当て、パスごとの負荷分散されたサブスクライバー、およびテストが有意性に達すると勝者を100％に昇格させるwinner_edge_idフィールドを持つSPLIT_PATHノード。ほとんどの旅行A/Bテストは、リマインダー#2の割引額で実行されます。
目的地のタイムゾーン別のサイレントアワー	「午前3時にプッシュしない」	timezone: subscriberと、送信をskip（非クリティカルなプッシュ）するか、サイレントアワー終了の1分後に再スケジュールするfallback設定を持つワークフローレベルのオプション（安全性、天気、ゲート変更）。サブスクライバーの現地時間帯がブランドの本拠地市場ではなく目的地である場合にクリティカルです。
終了条件	「予約が完了したら、放棄された予約シーケンスを停止する」	各ノードの前に、旅行者をbooking_completedゴールとfare_status = invalidated属性に対してチェックし、いずれかに一致した場合はワークフローをキャンセルするワークフローレベルのルール。2番目の条件は、SERPの結果が説明していないものです。

ベストプラクティスの箇条書きは簡単に同意できるが実施が難しいのに対し、ワークフローノードはエンジンによって実施されるため、違いは重要です。DECISIONは毎回実行されます。SPLIT_PATHはすべての旅行者をバランスさせます。サイレントアワーのフォールバックは、目的地のタイムゾーンを確認することを誰も覚えていなくても機能します。終了ルールは、キャンペーンオーナーが注意を払っているかどうかにかかわらず、放棄された予約ワークフローをキャンセルします。

ブループリント2の放棄された予約フローでは、旅行者が予約した瞬間（ワークフローの1時間後、30時間後、または73時間後）に終了ルールがトリガーされ、その旅行者のワークフローがキャンセルされ、昨日すでに支払いをした人に「予約を完了してください」というプッシュが送信されなくなります。別途、運賃が変更され、予約システムがfare_status = invalidatedを更新した瞬間に、ワークフローは正常に終了し、「運賃が変更されました。類似のオプションはこちらです」というリカバリープッシュが送信されます。信頼の侵害はありません。カスタマーサービスへの怒りの電話もありません。

マルチチャネルオーケストレーション：ウェブプッシュ、アプリプッシュ、SMS、WhatsApp、Eメール

旅行ブランドは、eコマース、SaaS、またはパブリッシャーチームよりも多くのチャネルを運営しています。デスクトップ予約フローではWebプッシュ。ブランドアプリをダウンロードした旅行者にはアプリプッシュ。旅行中の重要なアラート（ゲート変更、フライト遅延、天気）については、データローミングに強いチャネルとしてSMSを使用します。WhatsAppは、ハイタッチのカスタマーサービスや、WhatsAppがデフォルトのメッセンジャーである地域の国際旅行者向けです。メールは、旅行前の長文の旅程コンテナとして使用します。これら5つすべてを1つのワークフロー内で構成すること、つまり加入者の状態に一致するチャネルを選択することが、一貫したジャーニーを提供するCRMチームと、宛先のタイムゾーンで眠っている旅行者を起こしてしまう午前3時の「フライトは定刻通りです」というプッシュについて謝罪しなければならないチームとの違いを生み出します。

構成された旅行中のゲート変更ジャーニーは次のように読み取れます。

• 開始：カスタムイベントgate_change、trip_in_progress = trueの旅程に対して
• 決定：旅行者は現在ブランドのモバイルアプリを利用していますか？
  • はい：アクションアプリプッシュを実行（最も低い摩擦、ローミングデータ対応配信）
  • いいえ: 続行
• 決定：旅行者は国際ローミング中ですか？（countryがhome_countryと等しくない）というオーディエンスフィルター
  • はい：アクションSMSをTwilioまたはPlivoにHttpRequest経由で送信（SMSはデータではなくセルラー音声を使用するため、ローミングデータが限られている場合に強力です）
  • いいえ：アクションWebプッシュを実行（旅行者はホテルのWi-Fiを利用している可能性があります）
• アクション：次のメール旅程の要約を更新するためにESPにHttpRequestを実行
• gate_acknowledgedまたはflight_boardedで終了

1つの旅行者ID、1つのワークフロー、状態によって選択された4つのチャネル。最も安価で実行可能なチャネルが最初に行われます。最も送信あたりのコストが高いSMSは、旅行者が国際ローミング中でメッセージが時間的クリティカルな場合にのみ実行されます。Booking.comは、モバイルメッセージングを放送マーケティングではなく「リアルタイムの顧客インタラクション」として位置づけました。この構成されたワークフローは、ワークフローアーキテクチャとして表現された同じ哲学です。

これを別々のツールで実行すると、5つのベンダーログイン、現在旅行中であることについて意見が一致しない2つのセグメンテーションエンジン、および旅行者ごとのチャネルごとの単一の収益帰属が得られません。これを1つのワークフローエンジン内で実行すると、1つの旅行者ID、1セットの決定ロジック、およびジャーニーが実際にどこで中断されるかを示す1つのファネルレポートが得られます。HttpRequestアクション（Workflows.md §5.7）は、クロスチャネルオーケストレーションを可能にするものです。これは、ワークフローエンジンをSMSゲートウェイ、ESP、および予約システムにブリッジし、個別のオーケストレーションツールを必要としません。

リテンションの計算：予約コンバージョンリフトとリピート予約LTV（旅行チケットサイズ別）

旅行のマネタイズはハイチケットです。予約の価値は、ショートホールのフライトの300ドルからバケーションパッケージの5,000ドル以上まで幅広く、これはeコマース（50ドル〜200ドルのカート）やSaaS（99ドル〜999ドルのARR）に対するコスト計算を変えます。PushEngageワークフローは、キューに入れられた、完了した、終了したという3つの数値を各ノードで追跡し、同じノードレベルの分析パターンが適用されます。回復した予約あたりの収益は、回復したカートあたりの収益をはるかに上回り、ワークフローの損益計算書への貢献を擁護しやすくします。

これは、月間5,000件の予約放棄があり、平均チケット単価が1,200ドルのミッドマーケットOTAにおけるアクティブな予約放棄ワークフローのノードレベル分析の外観です（例示的な数値）：

ノード	キューに入れられた	完了	離脱	メモ
開始（予約放棄）	0	5,000	0	すべての放棄された旅程が入力されます
1時間待機	92	4,900	8	タッチなしで最初の1時間で8件予約済み
アクション：HttpRequest運賃チェック	0	4,900	0	予約システムがfare_status属性を更新します
決定：運賃ステータス有効	0	4,410	490	最初のタッチ前に490件の旅程が運賃無効になりました—「運賃変更」プッシュによる円滑な終了
アクション：リマインダー#1（元の運賃）	0	4,410	0	最初のリマインダーが送信されました
24時間待機	134	3,950	326	リマインダー#1の後、326件予約済み
2回目の運賃チェック+決定	0	3,720	230	さらに230件の旅程が運賃無効になりました—円滑な終了
アクション：リマインダー#2 + 10%プロモ	0	3,720	0	2回目のリマインダー
48時間待機	78	3,200	442	リマインダー#2の後、さらに442件予約済み
アクション：最終リマインダー + より強力なオファー	0	3,200	0	最終プッシュ
終了	該当なし	3,200	該当なし	3,200件予約されませんでした

このコホートでは、776件の放棄された旅程がワークフロー内で予約に転換しました—15.5%の回収率。平均予約額1,200ドルで、月間931,200ドルの回収収益、または年間1120万ドルになります。運賃変更による終了は、運賃がすでに上昇していたにもかかわらず、「399ドルの予約を完了してください」という誤解を招くプッシュを受け取る旅行者関係をさらに720件節約しました—ワークフローが防いだ720件のカスタマーサービスチケットとブランド信頼違反は、予約コンバージョンリフトとは別にあります。

コスト計算は旅行のために再編成されます。Webプッシュとアプリプッシュは、オプトイン後は送信あたりのコストがゼロです。Twilio経由のSMSは、米国国内メッセージあたり約0.0079ドル、国際メッセージあたり0.05〜0.30ドルです—月間5,000件の予約放棄コホートで、旅行中のSMS共有が10%の場合、SMS支出はコホートあたり40〜150ドルになります。WhatsApp Business Platformの価格設定はセッションベースです。EメールはESP契約でスケールします。ワークフローの仕事は、最初に最も安価で実行可能なチャネルを使用し、状態が要求した場合にのみSMSまたはWhatsAppにエスカレートすることです。「予約放棄ワークフローが月間931Kドルの予約を1,500ドルのオールインチャネルコストで回収した」という項目は、来年の予算会議で勝利するような損益計算書です。

旅行ブランドのためにPushEngageワークフローで構築しましょう

5つの旅行ブループリントはそれぞれPushEngageワークフローコンポーネントに直接マッピングされます。マッピング：

ブループリント	使用ノードタイプ	使用アクションタイプ	ワークフローオプション
ウェルカム+初回予約育成	START、WAIT、DECISION、ACTION、END	SendPushNotification、AddSegment	実行タイプ：シングル
運賃変更終了による予約放棄	開始、待機、アクション、決定、終了	SendPushNotification、HttpRequest、UpdateAttribute	実行タイプ：複数並列；目標booking_completedで終了、またはオーディエンスフィルターfare_status=invalidatedで終了
旅行前の育成（出発日計算）	開始、待機（待機時間）、アクション、終了	SendPushNotification	実行タイプ：予約ごと1回。wait_untilはdeparture_date属性に紐付け
旅行中のジオロケーション	開始、決定、アクション、終了	SendPushNotification、HttpRequest、UpdateAttribute	実行タイプ：複数並列。CustomEvent + オーディエンスフィルターのトリガー
旅行後のレビュー + ルックアライク再予約	開始、待機、アクション、待機（wait_until）、アクション、決定、終了	SendPushNotification	実行タイプ：複数シーケンシャル

Workflowsエンジンには、各ブループリントのビルディングブロックをカバーする60以上の出荷済みテンプレートが付属しています。ほとんどのテンプレートはeコマース向けに設計されていますが、旅行への適応は簡単です。カート放棄テンプレートのロジックは、トリガーイベントをbooking_abandonedに切り替え、ブループリント2のHttpRequest-and-attribute-update運賃チェックパターンを追加し、運賃無効化の終了基準とbooking_completedを併用することで、放棄された予約のワークフローになります。ウェルカムテンプレートはブループリント1に直接適合します。ジオロケーションドリップテンプレート（すでにカタログにあります）は、ブループリント4の旅行中ワークフローの基盤となります。

より広範な旅行プッシュのコンテキスト（ホテル、フライト、バケーションレンタルなどのニッチ固有のユースケースや季節戦略）については、従来の旅行サイトプッシュ通知プレイブックに、これらのブループリントが実装するキャンペーンタイプがカタログ化されています。

直ちに試用を開始する場合、無料プランでは200人の購読者、すべてのチャネル（ウェブプッシュ、アプリプッシュ、WhatsApp、ライブチャット）が利用でき、初日から完全なWorkflowsエンジンを使用できます。これは、次のコホートの放棄された旅程でブループリント1と2をリリースし、次のQBRの前にノードレベルの分析をキャプチャするのに十分です。PushEngageの旅行分野でのポジショニング（価格設定、統合、顧客事例）については、旅行向けPushEngageが正規のランディングページです。

これが変えること

この記事から1つだけ持ち帰るとしたら、それはこれです。旅行向けのプッシュ通知自動化は、ワークフローアーキテクチャであり、放棄された予約のトリガーが追加された予約確認のブロードキャストではありません。運賃変更で正常に終了する放棄された予約のジャーニー、departure_date - 7 daysでトリガーされる旅行前のワークフロー、目的地タイムゾーンを尊重する旅行中のジオロケーションワークフロー。これらはすべて同じ形状をしています。1つの開始、いくつかの待機、いくつかの決定、いくつかのアクション、1つの終了。3つのスタンドアロンのトリガーではこれができません。1つのワークフローエンジンならできます。そこからリピート予約のLTVが複利で増加します。

次のコホートの放棄された旅程で最初のブループリントをリリースするには、無料プランから開始してください。