Seyahat için anlık bildirim otomasyonu: 5 iş akışı şablonu

Salı öğleden sonra ve elde tutma incelemesi 14:15'te sona erdi. Rezervasyon-dönüşüm oranınız geçen çeyrekte 1,4 puan düştü — %3,6'dan %2,2'ye. Sadakat ekibi, kurtarma e-postası temposunun çok geç ateşlendiğini düşünüyor. Mobil ekip, terk edilmiş rezervasyon itmesinin fiyat düşüşü uyarılarıyla örtüştüğünü düşünüyor. Kimse bunlardan birini sebep olarak kanıtlayamıyor. Toplantı sonrası Slack başlığında iki saat sonra, herkesin üzerinde anlaştığı tek şey, gösterge panelinin tartışmayı çözmek için yeterince ayrıntılı olmadığıdır.

Seyahat için anlık bildirim otomasyonu bu tartışmanın merkezinde yer alıyor ve elde tutma ekibindeki hiç kimse onu nasıl savunacağından emin değil. Rezervasyon onaylama otomatik itmesi, bir rezervasyon tamamlandığında tetiklenir. Terk edilmiş rezervasyon tetikleyicisi, aynı güzergahı 24 saat sonra tekrar pingler — ve bazen bu güzergah, bilet fiyatı gece değiştiği için, gezginin terk ettiği fiyatta artık değildir. İki yıl önce birinin kurduğu churn-uyarı tetikleyicisi, uygulamadaki DAU düştüğünde hala tetikleniyor, ancak abonenin şu anda seyahatte olduğunu ve aslında churn olmadığını, sadece tatilde olduğunu bilmiyor. Birbirinin farkında olmayan, gezginin seyahat döngüsündeki yerinin tutarlı bir görünümünü tutmayan üç "otomatik" mekanizma.

Bu makale, seyahat anlık bildirim otomasyonunun aslında nasıl görünmesi gerektiğini — iş akışı mimarisi, terk edilmiş rezervasyon tetikleyicisinin üzerine eklenmiş rezervasyon onay yayınları değil — ve zamanlama, fiyat değişikliği anı için çıkış kriterleri, coğrafi konumla tetiklenen seyahat içi işlem ve her birini reklam operasyonları ve sadakat ekibi için savunulabilir bir kalem haline getiren gelir matematiği ile beş seyahat şeklindeki iş akışı planını inceliyor.

Seyahat “otomatik anlık bildirimleriniz” neden fiyat değişikliği anında gelir sızdırıyor

Otomasyon kelimesi, e-ticaret, SaaS ve yayıncılık alanlarında olduğu gibi seyahat alanında da aynı hak edilmemiş işi görüyor. Çoğu seyahat CRM ekibi, seyahat için otomatik anlık bildirimlerden bahsettiğinde, kastettikleri olay tetiklemeli yayın planlamasıdır: bilinen bir olay gerçekleştiğinde, durum, segmentasyon, dokunuşlar arasında bekleme, çıkış koşulları ve kritik olarak - ikinci dokunuş gerçekleştiğinde temel teklifin artık geçerli olmayabileceğinin farkındalığı olmadan bir bildirim tetiklenir.

Bir iş akışı farklı bir şeydir. Bir iş akışı, durumu olan çok adımlı bir yolculuktur. Gezginin rezervasyonu ne zaman terk ettiğini, hangi ücreti gördüğünü, o güzergahta şu anda hangi ücretin teklif edildiğini, seyahat durumunun ne olduğunu ve hangi koşulların yolculuğu iptal ettiğini bilir. Terk edilmiş rezervasyon iş akışı, 24 saat sonra sadece bir hatırlatma bildirimi göndermez. Her dokunuştan önce ücretin hala geçerli olup olmadığını kontrol eder, rezervasyon tamamlandığı anda iş akışından çıkar ve ücret değişirse ayrı olarak çıkar - çünkü ücret şimdi 529 $ iken bir gezgine “399 $ rezervasyonunuzu tamamlayın” göndermek, kurtarılan hiçbir rezervasyonun haklı çıkaramayacağı bir şekilde güveni yok eder.

Son madde farktır. Olay tetikleyicilerinin harici durum hakkında hafızası yoktur. İş akışlarının vardır. Terk edilmiş rezervasyon otomasyonunuz, ücret yükseldikten sonra gezginleri eski ücretle tekrar tekrar sorgulamaya devam ederse, bir otomasyonunuz yoktur. Kontrol etmesi söylenmemiş bir tetikleyiciniz var.

Orta ölçekli bir seyahat CRM ekibi için bu ayrım, bileşik tekrar rezervasyon LTV'si ile ücret değiştirme anındaki güveni sarsan hatalar nedeniyle aşınan bir LTV arasındaki farktır. Paralel çalışan üç tetikleyici, üç sürtünme kanalı üretir. Koordineli çalışan beş iş akışı, gezgin başına seyahat aşaması başına bir yolculuk üretir; bu yolculuk rezervasyon durumu, ücret geçerliliği ve seyahat durumuna göre dallanır ve sınırlanır. Bu anahtar kelime için sayfa bir arama sonuçları, sorunu “5 seyahat kullanım durumu” olarak çerçeveler ve bir araç listesiyle yanıtlar. Salı günkü elde tutma incelemenizin sorduğu soru bu değil.

Bir seyahat anlık bildirim iş akışının anatomisi

Planlardan önce kelime bilgisi. Bir seyahat anlık bildirim iş akışı altı düğüm türünden oluşur. Her birinin ne yaptığını bildiğinizde, her plan bir açıklama değil, bir diyagram olarak okunur.

BAŞLANGIÇ. Giriş noktası. Bir BAŞLANGIÇ düğümü, iş akışının bir abone olayı (booking_initiated, booking_abandoned, fare_changed, geolocation_changed, trip_completed) veya bir kitle filtresi (lifecycle_stage, loyalty_tier, last_active) tarafından nasıl tetikleneceğini tanımlar. Bir iş akışının tam olarak bir BAŞLANGIÇ düğümü vardır.

BEKLE. Bir gecikme. BEKLE düğümü, aboneyi belirli bir süre (seyahat içi etkileşim için dakikalar, terk edilmiş rezervasyon temposu için saatler, seyahat öncesi kadans için günler) veya bir abonenin özniteliğine bağlı wait_until anlambilimi kullanarak belirli bir takvim saatine kadar tutar — departure_date - 7 days, departure_date - 1 day, trip_completion_date + 1 year. Beklemeler, bir iş akışının yalnızca bilinen geçmiş bir olayı değil, bilinen gelecekteki bir olayı nasıl onurlandırdığıdır.

KARAR. İki yönlü bir dal. KARAR düğümü, aboneye özel bir koşulu kontrol eder: rezervasyon tamamlandı mı, ücret hala geçerli mi (abonelik sisteminin güncellediği bir abonenin özniteliğinden okunur), sadakat seviyesi gümüşün üzerinde mi, gezgin şu anda seyahat ediyor mu. KARAR düğümleri olay filtrelerini ve kitle filtrelerini değerlendirir; HttpRequest yanıt gövdelerini doğrudan tüketmezler. Harici durumu bir iş akışına getiren desen, HttpRequest eyleminin harici sistemi tetiklemesi, harici sistemin PushEngage REST API aracılığıyla bir abonenin özniteliğine geri yazması ve KARAR'ın özniteliği okumasıdır.

YOL_AYIR. Yüzde tabanlı bir çatal. YOL_AYIR düğümleri, yapılandırılmış yüzdelere göre aboneleri yollar arasında yönlendirir: terk edilmiş rezervasyon indirim tutarları üzerinde bir A/B testi için %50/50, seyahat öncesi hatırlatıcılar üzerinde üç yönlü bir gönderim zamanı testi için %33/33/34. Kazananı belirledikten sonra, o yolu %100'e yükseltirsiniz.

EYLEM. İşin kendisi. EYLEM düğümleri bir anlık bildirim gönderir, aboneyi bir segmente ekler, özel öznitelikleri günceller, bir rezervasyon sistemine veya SMS ağ geçidine bir HttpRequest gönderir, başka bir iş akışı başlatır veya birini durdurur. PushEngage İş Akışları on bir eylem türünü destekler. Seyahat için en kullanışlı olanlar SendPushNotification, UpdateAttribute, HttpRequest ve Workflow.Start'tır (seyahat öncesini seyahat içi ve seyahat sonrası ile zincirlemek için).

SON / ÇIKIŞ. Terminal. SON doğal sonu işaretler. ÇIKIŞ erken bir sonlandırmayı işaretler — gezgin artık uygun olmadığında Karar'ın HAYIR yolunda, soğuma kuralı tetiklendiğinde veya hedef karşılandığında (rezervasyon tamamlandı, seyahat iptal edildi, ücret geçersiz kılındı).

Aşağıdaki her bir plan, bu altı parçadan oluşur.

Seyahat için beş iş akışı planı

Bunlar şablon değildir. Çalışan planlardır. Her biri tetikleyicisini, çalıştırma türünü, düğüm dizisini, çıkış kriterlerini ve taşımak üzere tasarlandığı seyahat tutma metriğini listeler. Her birini PushEngage İş Akışları oluşturucusuna yerleştirebilir ve ilk sürümü bir saatten kısa sürede gönderebilirsiniz. Eski seyahat anlık bildirim kılavuzu, bu planların uyguladığı daha geniş kullanım durumlarını kapsar.

Plan 1 — Hoş Geldiniz + ilk rezervasyon beslemesi

• Tetikleyici (BAŞLANGIÇ): Olay PushEngage.Subscriber.Added VEYA browse_destination_page_view
• Çalıştırma türü: Tek (90 günlük pencere başına gezgin başına bir karşılama yolculuğu)
• Akış: En popüler destinasyonlarla karşılama bildirimi → 1 gün BEKLE → hangi seyahat türlerinin önemli olduğunu soran destinasyon tercihi bildirimi (plaj, kayak, şehir kaçamağı, iş) → 2 gün BEKLE → KARAR: abone bir rezervasyon başlattı mı? → EVET yolu: iptal ederlerse Blueprint 2'ye bağlan, aksi takdirde rezervasyon_tamamlandıktan sonra gezi öncesi iş akışını devralmasına izin ver → HAYIR yolu: küratörlü üç destinasyon önerisi bildirimi gönder, aktif_tarayıcılar segmentine ekle, SON
• Çıkış kriterleri: Hedef rezervasyon_tamamlandı
• Seyahat metriği: 7. günde göz atma-ilk rezervasyon dönüşüm oranı.

Plan 2 — Fiyat değişikliği çıkışlı terk edilmiş rezervasyon (rezervasyon terk bildirim otomasyonu)

• Tetikleyici (BAŞLANGIÇ): rezervasyon_iptal_edildi özel olayı, rota_kimliği yükü ile
• Çalıştırma türü: Birden Çok Paralel (her iptal edilen rezervasyon kendi iş akışı örneğidir)
• Akış: 1 saat BEKLE → EYLEM: rota_kimliği için rezervasyon sisteminizin ücret kontrolü uç noktasına HttpRequest GET. Rezervasyon sistemi, saniyeler içinde PushEngage REST API aracılığıyla bir abone özniteliğine geri yazar — ücret_durumu = geçerli veya ücret_durumu = geçersiz — → KARAR: hedef kitle filtresi ücret_durumu = geçerli? → HAYIR yolu: “ücretiniz değişti, yeni fiyattan benzer seçenekler şunlardır” bildirimi gönder ve ÇIK (zarif yeniden yönlendirme, güven ihlali yok) → EVET yolu: orijinal ücretle hatırlatıcı bildirimi → 24 saat BEKLE → HttpRequest ücret kontrolünü tekrarla, ardından ücret_durumu = geçerli VE hedef kitle filtresi rezervasyon_tamamlandı = false üzerinde KARAR → EVET yolu: %10 promosyon kodu ile hatırlatıcı #2 → 48 saat BEKLE → daha güçlü bir teklifle son hatırlatıcı → SON
• Çıkış kriterleri: Tetikleyiciden gelen rota_kimliği ile eşleşen rezervasyon_tamamlandı hedefi VEYA ücret_durumu = geçersiz hedef kitle filtresi
• Seyahat metriği: İptal edilen rezervasyon başına kurtarılan rezervasyon değeri. Bu, sayfadaki en savunulabilir gelir çizgisine sahip iş akışıdır. Rezervasyon iptalini azaltmanın 6 ipucu gönderisi, bu planın manuel taktik sürümünü kapsar; iş akışı sürümü, taktiksel bir kurtarmayı marka güvenliğini koruyan bir kurtarmaya dönüştüren ücret geçerliliği çıkışını ekler.

Plan 3 — Seyahat öncesi besleme (kalkış tarihi matematiği)

Bu, bir abone özniteliğine bağlı wait_until anlambilimini gösteren gezi öncesi anlık bildirim iş akışıdır.

• Tetikleyici (BAŞLANGIÇ): rezervasyon_tamamlandı özel olayı (bu, kalkış_tarihi'ni bir abone özniteliğine yazar)
• Çalıştırma türü: Rezervasyon başına Tek
• Akış: BEKLE kalkış_tarihi - 14 gün → “seyahatiniz iki hafta sonra” paketleme önerileri ve hava durumu tahmini ile birlikte bildirim → BEKLE kalkış_tarihi - 7 gün → ek gelir bildirimi (koltuk yükseltme, oda yükseltme, araç kiralama eklemesi, havaalanı transferi) → BEKLE kalkış_tarihi - 1 gün → mobil biniş kartı bağlantısı ile check-in hatırlatma bildirimi → BEKLE kalkış_tarihi → iyi yolculuklar bildirimi, SON
• Çıkış kriterleri: Hedef rezervasyon_iptal_edildi
• Seyahat metriği: Rezervasyon başına ek gelir. 7 gün öncesi dokunuşu, ek gelirler için en yüksek kaldıraç anıdır.

Plan 4 — Seyahat içi coğrafi konum (coğrafi konum anlık bildirim otomasyonu)

• Tetikleyici (BAŞLANGIÇ): Özel olay konum_değişti (cihaz yeni enlem/boylam bildirdiğinde mobil uygulamanız tarafından tetiklenir) VE hedef kitle filtresi seyahat_devam_ediyor = true
• Çalıştırma türü: Birden Çok Paralel
• Akış: KARAR: gezgin varış şehrine ulaştı mı (hedef kitle filtresi, coğrafi konum koordinatlarını bir abone özniteliği olarak saklanan bir hedef coğrafi çitle karşılaştırır)? → EVET yolu: AKSİYON yerel öneriler bildirimi gönder (varış noktasına bağlı oteller, restoranlar, yerel aktiviteler), AKSİYON hava durumu API'sine HttpRequest → hava durumu uyarısı gerekliyse, AKSİYON hava durumu bildirimi gönder → SON → HAYIR yolu: ÇIKIŞ (gezgin transit halinde, varış noktasında değil)
• Sessiz saatler: aboneye-zaman-dilimi-duyarlı. İş Akışları.md §9.4, sessiz saatleri önce abone zaman dilimine, sonra site zaman dilimine, sonra UTC'ye göre çözer. Seyahat içi iş akışları için bu, zaman diliminin markanın ana pazarının değil, varış noktasının yerel saatini onurlandırdığı anlamına gelir. Kritik olmayan bildirimler atla kullanır; güvenlik ve hava durumu uyarıları teslimatı sağlamak için yeniden planla kullanır
• Çıkış kriterleri: Hedef seyahat_tamamlandı
• Seyahat metriği: Seyahat içi etkileşim oranı ve seyahat içi ek gelir. Not: konum_değişti yerleşik bir tetikleyici türü değildir — bu, cihaz konumu güncellendiğinde mobil uygulamanızın ateşlediği bir PushEngage.CustomEvent'tir ve varış noktasındaki kontrol, uygulamanın koruduğu abone öznitelikleri üzerindeki bir hedef kitle filtresidir. Coğrafi konum bildirimleri gönderisi, bu taslağın genişlettiği segmentasyon temelini kapsar.

Plan 5 — Seyahat sonrası inceleme + benzer yeniden rezervasyon

• Tetikleyici (BAŞLANGIÇ): Özel olay seyahat_tamamlandı
• Çalıştırma türü: Birden Çok Sıralı
• Akış: 3 gün BEKLE → varış noktasını ismen belirten inceleme isteği bildirimi → seyahat_tamamlama_tarihi + 365 gün (bir yıl sonra) BEKLE → önceki seyahat türüne dayalı benzer bir destinasyon teklifiyle “bir sonraki seyahatiniz için hazır mısınız?” bildirimi → 7 gün BEKLE → KARAR: gezgin bir rezervasyon başlattı mı? → EVET yolu: Taslak 1 veya 2'ye zincirle → HAYIR yolu: ÇIKIŞ
• Çıkış kriterleri: Yeni rezervasyon_başlatıldı olayı VEYA abonelikten_çıkarıldı
• Seyahat metriği: 12 aylık tekrarlayan rezervasyon oranı. Bu, en uzun süredir devam eden ve en yüksek LTV etkisine sahip olan taslak yaklaşık 13 aydır. Yıl bazında benzerlik gösteren desen, seyahat alıcılarının aslında takip ettiği mevsimsel ritme uyarlanmış, e-ticaretin satın alma sonrası geri kazanımının seyahat muadilidir.

Yaşam döngüsü aşaması segmentasyonu, A/B testi, hedef saat dilimine göre sessiz saatler ve çıkış kriterleri iş akışı içinde yaşar

Seyahat anlık bildirim makalelerindeki baskın desen, bu dört kavramı "en iyi uygulamalar" olarak listelemektir — strateji gönderisinin sonunda, onları kullanan kampanyalardan kopuk, genel madde işaretleri. Bu yanlış bir çerçevedir. Bunlar iş akışının yanında duran en iyi uygulamalar değildir. Bunlar iş akışının kendisidir.

Kavram	En iyi uygulama çerçevesi (yanlış)	İş akışı düğümü çerçevesi (doğru)
Yaşam döngüsü aşaması segmentasyonu	“Gezginleri seyahat aşamasına göre segmentlere ayırın”	Abonenin lifecycle_stage (göz atma / rezervasyon başlatıldı / seyahat öncesi / seyahat sırasında / seyahat sonrası / kayıp) karar düğümü, seyahat öncesi gezginleri ek yönlendirmelere, seyahat sırasındaki gezginleri coğrafi konum iş akışlarına, seyahat sonrası gezginleri inceleme ve benzer yeniden rezervasyonlara yönlendirir.
A/B testi	“Terk edilmiş rezervasyon metinlerinizi her zaman A/B testi yapın”	50/50 dağılımlı bir SPLIT_PATH düğümü, yola göre dengelenmiş aboneler ve testin anlamlılığa ulaşmasının ardından kazananı %100'e çıkaran bir winner_edge_id alanı — çoğu seyahat A/B testi, 2. hatırlatmadaki indirim miktarı üzerinden çalışır.
Varış yeri saat dilimine göre sessiz saatler	“Sabah 3'te bildirim göndermeyin”	timezone: subscriber ve gönderiyi skip eden (kritik olmayan bildirimler) veya sessiz saatlerin bitiminden bir dakika sonrasına reschedule eden bir fallback ayarına sahip iş akışı düzeyinde bir seçenek (güvenlik, hava durumu, kapı değişikliği) — abonenin yerel saat diliminin markanın ana pazarı değil, varış yeri olduğu seyahat sırasındaki iş akışları için kritik
Çıkış kriterleri	“Rezervasyon tamamlandığında terk edilmiş rezervasyon dizisini durdurun”	Her düğümden önce gezgini booking_completed hedefi VE fare_status = invalidated özelliğiyle kontrol eden ve her ikisi de eşleşirse iş akışını iptal eden bir iş akışı düzeyinde kural — ikinci koşul, hiçbir SERP sonucunun açıklamadığı şeydir.

Fark önemlidir çünkü en iyi uygulama madde işaretlerine uymak kolaydır ancak uygulamak zordur. İş akışı düğümleri motor tarafından uygulanır. DECISION her zaman çalışır. SPLIT_PATH her gezgini dengeler. Sessiz saatler geri dönüşü, varış yeri saat dilimini kontrol etmeyi hatırlamadan devreye girer. Çıkış kuralı, kampanya sahibi dikkat etmese bile terk edilmiş rezervasyon iş akışını iptal eder.

Taslak 2'nin terk edilmiş rezervasyon akışı için, bu, bir gezginin rezervasyon yaptığı anda — iş akışının 1. saati, 30. saati veya 73. saati — çıkış kuralının tetiklendiği, o gezgin için iş akışının iptal edildiği ve dün zaten ödeme yapmış birine daha fazla “rezervasyonunuzu tamamlayın” bildirimi gönderilmediği anlamına gelir. Ayrı olarak, ücretin değiştiği ve rezervasyon sisteminin fare_status = invalidated olarak güncellediği anda, iş akışı sorunsuz bir şekilde çıkar ve “ücret değişti, işte benzer seçenekler” kurtarma bildirimi gönderir. Güven ihlali yok. Müşteri hizmetlerine öfkeli bir çağrı yok.

Çok kanallı orkestrasyon: web push, uygulama push, SMS, WhatsApp, e-posta

Seyahat markaları, e-ticaret, SaaS veya yayıncı ekiplerinden daha fazla kanala sahiptir. Masaüstü rezervasyon akışı için web anlık bildirimleri. Marka uygulamasını indiren gezginler için uygulama anlık bildirimleri. Seyahat sırasındaki kritik uyarılar (kapı değişikliği, uçuş gecikmesi, hava durumu) için veri dolaşımına dayanıklı kanal olarak SMS. WhatsApp, yüksek temaslı müşteri hizmetleri ve WhatsApp'ın varsayılan mesajlaşma olduğu bölgelerdeki uluslararası gezginler için. E-posta, seyahat öncesi uzun biçimli seyahat programı kapsayıcısı olarak. Beşini de tek bir iş akışında birleştirmek — abonenin durumuna uyan kanalı seçmek — tutarlı bir yolculuk sunan bir CRM ekibi ile varış yeri saat diliminde bir gezgini uyandıran sabah 3'teki "uçuşunuz zamanında" anlık bildirimini için özür dilemek zorunda kalan bir ekip arasındaki farkı yaratan şeydir.

Birleştirilmiş bir seyahat sırası kapı değişikliği yolculuğu şöyle okunur:

• BAŞLANGIÇ: trip_in_progress = true olan bir seyahat programı için özel olay gate_change
• KARAR: gezgin şu anda markanın mobil uygulamasında mı?
  • EVET: EYLEM uygulama anlık bildirimi gönder (en düşük sürtünme, veri dolaşımına duyarlı teslimat)
  • HAYIR: devam et
• KARAR: gezgin uluslararası dolaşımda mı (country home_country'ye eşit değil) kitle filtresi?
  • EVET: EYLEM Twilio veya Plivo'ya HttpRequest aracılığıyla SMS gönder (SMS hücresel sesi kullanır, veriyi değil - dolaşım verisi sınırlı olduğunda dayanıklıdır)
  • HAYIR: EYLEM web anlık bildirimi gönder (gezgin otel Wi-Fi'sinde olabilir)
• EYLEM: bir sonraki e-posta seyahat programı özetini güncellemek için ESP'ye HttpRequest
• gate_acknowledged veya flight_boarded üzerinde ÇIKIŞ

Tek gezgin kimliği, tek iş akışı, duruma göre seçilen dört kanal. En ucuz geçerli kanal önce gider. En pahalı gönderim başına SMS - yalnızca gezgin uluslararası dolaşımda olduğunda ve mesaj zaman açısından kritik olduğunda gönderilir. Booking.com, mobil mesajlaşmayı yayın pazarlaması yerine "gerçek zamanlı müşteri etkileşimi" olarak çerçeveledi; bu birleştirilmiş iş akışı, iş akışı mimarisi olarak ifade edilen aynı felsefedir.

Bunu ayrı araçlarla çalıştırmak, beş satıcı girişi, kimin şu anda seyahat halinde olduğu konusunda anlaşamayan iki segmentasyon motoru ve gezgin başına kanal başına tek bir gelir atfı anlamına gelir. Bunu tek bir iş akışı motoru içinde yapmak, tek bir gezgin kimliği, tek bir karar mantığı seti ve yolculuğun aslında nerede koptuğunu gösteren tek bir huni raporu anlamına gelir. HttpRequest eylemi (Workflows.md §5.7), çapraz kanal düzenlemesini mümkün kılan şeydir - iş akışı motorunu SMS ağ geçidine, ESP'ye ve rezervasyon sistemine ayrı bir düzenleme aracı gerektirmeden bağlar.

Elde tutma matematiği: seyahat bileti boyutlarında rezervasyon-dönüşüm artışı ve tekrar rezervasyon LTV'si

Seyahat gelirleştirme yüksek biletlidir. Rezervasyon değerleri, 300 ABD Doları kısa mesafeli uçuşlardan 5.000 ABD Doları üzerindeki tatil paketlerine kadar değişir; bu da e-ticaret (50-200 ABD Doları sepetler) ve SaaS (yıllık 99-999 ABD Doları) ile karşılaştırıldığında maliyet hesaplamasını değiştirir. PushEngage Workflows, her düğümde aynı üç sayıyı izler: kuyrukta, tamamlandı, çıkıldı ve aynı düğüm düzeyinde analiz deseni geçerlidir. Kurtarılan her rezervasyon geliri, kurtarılan her sepet gelirini gölgede bırakır, bu da iş akışının kâr ve zarar katkısının savunulmasını kolaylaştırır.

İşte ortalama 1.200 ABD Doları bilet fiyatıyla ayda 5.000 terk edilmiş rezervasyon yapan orta ölçekli bir OTA'daki aktif bir terk edilmiş rezervasyon iş akışı için düğüm düzeyinde analizlerin nasıl göründüğü (örnek sayılar):

Düğüm	Sıradaki	Tamamlanan	Ayrılan	Notlar
BAŞLANGIÇ (rezervasyon_terk_edildi)	0	5,000	0	Tüm terk edilmiş güzergahlar girer
1 saat BEKLE	92	4,900	8	İlk saat içinde müdahale olmadan 8 rezervasyon yapıldı
İŞLEM: HttpRequest fiyat-kontrolü	0	4,900	0	Rezervasyon sistemi fiyat_durumu özniteliğini günceller
KARAR: fiyat_durumu geçerli	0	4,410	490	İlk müdahaleden önce 490 güzergahın fiyatı geçersiz sayıldı — "fiyat değişti" bildirimiyle zarif çıkış
İŞLEM: hatırlatıcı #1 (orijinal fiyat)	0	4,410	0	İlk hatırlatıcı gönderildi
24 saat BEKLE	134	3,950	326	İlk hatırlatıcıdan sonra 326 rezervasyon yapıldı
İkinci fiyat-kontrolü + KARAR	0	3,720	230	Başka 230 güzergahın fiyatı geçersiz sayıldı — zarif çıkış
İŞLEM: hatırlatıcı #2 + %10 promosyon	0	3,720	0	İkinci hatırlatıcı
48 saat BEKLE	78	3,200	442	İkinci hatırlatıcının ardından 442 rezervasyon daha yapıldı
İŞLEM: son hatırlatıcı + daha güçlü teklif	0	3,200	0	Son bildirim
SON	yok	3,200	yok	3.200 kişi rezervasyon yapmadı

Bu kohortta, 776 terk edilmiş güzergah iş akışı içinde rezervasyona dönüştü — %15,5'lik bir kurtarma oranı. Ortalama 1.200 ABD Doları rezervasyon değeriyle, bu ayda 931.200 ABD Doları kurtarılan gelir veya yıllık 11,2 Milyon ABD Doları anlamına gelir. Fiyat değişikliği çıkışları, fiyatı zaten yükselmiş olan "399 ABD Doları'lık rezervasyonunuzu tamamlayın" şeklinde yanıltıcı bir bildirim almaktan ek olarak 720 seyahat ilişkisini kurtardı — iş akışının önlediği 720 müşteri hizmetleri bileti ve marka güveni ihlali, rezervasyon dönüşümündeki artıştan ayrı olarak.

Maliyet hesaplaması seyahat için yeniden çerçeveleniyor. Web bildirimi ve uygulama bildirimi, izin alındıktan sonra gönderim başına ücretsizdir. Twilio üzerinden SMS, ABD içi mesajlar için yaklaşık 0,0079 ABD Doları ve uluslararası mesajlar için 0,05–0,30 ABD Doları tutarındadır — ayda 5.000 terk edilmiş rezervasyon kohortu ve %10'luk seyahat içi SMS payı ile bu, SMS harcamasında kohort başına 40–150 ABD Doları anlamına gelir. WhatsApp Business Platform fiyatlandırması oturum bazlıdır. E-posta, ESP sözleşmesiyle ölçeklenir. İş akışının görevi, önce en ucuz uygun kanalı kullanmak ve yalnızca durum gerektirdiğinde SMS veya WhatsApp'a yükseltmektir. "Terk edilmiş rezervasyon iş akışı, 1.500 ABD Doları her şey dahil kanal maliyetiyle ayda 931 bin ABD Doları tutarında rezervasyon kurtardı" yazan satır öğesi, gelecek yılın bütçe konuşmasını kazandıran türden bir kâr ve zarar beyanıdır.

Seyahat markanız için PushEngage İş Akışlarında oluşturun

Beş seyahat taslağının her biri doğrudan PushEngage Workflows bileşenlerine eşlenir. Eşleme:

Şablon	Kullanılan düğüm türleri	Kullanılan Eylem Türleri	İş Akışı Seçeneği
Hoş Geldiniz + ilk rezervasyon beslemesi	BAŞLANGIÇ, BEKLE, KARAR, EYLEM, SON	Bildirim Gönder, Segment Ekle	Çalıştırma türü: Tek
Fiyat değişikliği çıkışlı terk edilmiş rezervasyon	BAŞLANGIÇ, BEKLE, İŞLEM, KARAR, SON	SendPushNotification, HttpRequest, UpdateAttribute	Çalıştırma türü: Birden Çok Paralel; hedef rezervasyon_tamamlandı VEYA kitle filtresi fiyat_durumu=geçersiz kılınmış ise çıkış
Seyahat öncesi besleme (kalkış tarihi hesaplaması)	BAŞLAT, BEKLE (bekle_ne_zaman), EYLEM, BİTİR	Push Bildirimi Gönder	Çalıştırma türü: Rezervasyon başına Tek; bekle_ne_zaman, departure_date özniteliğine bağlı
Seyahat içi coğrafi konum	BAŞLAT, KARAR, EYLEM, BİTİR	SendPushNotification, HttpRequest, UpdateAttribute	Çalıştırma türü: Birden Çok Paralel; ÖzelOlay + kitle filtresi tetikleyicisi
Seyahat sonrası inceleme + benzer yeniden rezervasyon	BAŞLAT, BEKLE, EYLEM, BEKLE (bekle_ne_zaman), EYLEM, KARAR, BİTİR	Push Bildirimi Gönder	Çalıştırma türü: Birden Çok Sıralı

İş Akışları motoru, her bir taslak için yapı taşlarını kapsayan 60'tan fazla gönderilmiş şablonla birlikte gelir. Şablonların çoğu E-ticaret şeklindedir, ancak seyahate uyarlama basittir: sepeti terk etme şablon mantığı, tetikleyici olayı booking_abandoned olarak değiştirilerek, Taslak 2'den HttpRequest-ve-öznitelik-güncelleme ücret kontrolü deseni eklenerek ve booking_completed ile birlikte bir ücret geçersiz kılma çıkış kriteri kullanılarak terk edilmiş rezervasyon iş akışı haline gelir. Hoş geldin şablonu doğrudan Taslak 1'e uyar. Coğrafi konum damla şablonu - zaten katalogda - Taslak 4'ün seyahat içi iş akışının temelini oluşturur.

Daha geniş seyahat itme bağlamı - niş özel kullanım durumları (oteller, uçuşlar, tatil kiralama) ve mevsimsellik stratejileri - eski seyahat sitesi anlık bildirim oyun kitabı, bu taslakların uyguladığı kampanya türlerini kataloglar.

Acil deneme yolu için, ücretsiz plan size 200 abone, tüm kanallar (web anlık bildirim, uygulama anlık bildirim, WhatsApp, canlı sohbet) ve ilk günden itibaren tam İş Akışları motoru sunar. Bu, bir sonraki terk edilmiş güzergah grubunuzda Taslak 1 ve 2'yi göndermek ve bir sonraki QBR'den önce düğüm düzeyinde analizleri yakalamak için yeterlidir. PushEngage'ın seyahat dikey konumlandırması - fiyatlandırma, entegrasyonlar, müşteri örnekleri - seyahat için PushEngage kanonik açılış sayfasıdır.

Bunun neyi değiştirdiği

Bu makaleden bir şey alırsanız, şunu alın: seyahat için anlık bildirim otomasyonu, eklenmiş bir terk edilmiş rezervasyon tetikleyicisiyle yapılan rezervasyon onayı yayınları değil, iş akışı mimarisidir. Ücret değişikliğinde zarifçe çıkan terk edilmiş rezervasyon yolculuğu, departure_date - 7 days tarihinde tetiklenen seyahat öncesi iş akışı, hedef saat dilimine saygı duyan seyahat içi coğrafi konum iş akışı - hepsi aynı şekildedir. Bir BAŞLANGIÇ, bazı BEKLEMELER, bazı KARARLAR, bazı EYLEMLER, bir ÇIKIŞ. Üç bağımsız tetikleyici bunu yapamaz. Bir iş akışı motoru yapabilir. Tekrar rezervasyon LTV'si oradan bileşiklenir.

Bir sonraki terk edilmiş güzergah grubunuzda ilk taslağı göndermek için ücretsiz planla başlayın.