أتمتة إشعارات الدفع للسفر: 5 مخططات سير عمل

إنه بعد ظهر يوم الثلاثاء وانتهى استعراض الاحتفاظ في الساعة 2:15 مساءً. انخفض معدل تحويل الحجز لديك بمقدار 1.4 نقطة في الربع الأخير - من 3.6٪ إلى 2.2٪. يعتقد فريق الولاء أن وتيرة رسائل البريد الإلكتروني للاسترداد تتأخر كثيرًا. يعتقد فريق الجوال أن إشعار الدفع للحجز المهجور يتداخل مع تنبيهات انخفاض الأسعار. لا يمكن لأحد إثبات أن أيًا منهما هو السبب. بعد ساعتين من خيط Slack بعد الاجتماع، الشيء الوحيد الذي يتفق عليه الجميع هو أن لوحة المعلومات ليست مفصلة بما يكفي لتسوية الجدل.

تقع أتمتة الإشعارات الفورية للسفر في مركز هذا الجدل، ولا أحد في فريق الاحتفاظ متأكد من كيفية الدفاع عنها. يتم إطلاق الدفعة التلقائية لتأكيد الحجز عند اكتمال الحجز. يعيد مشغل الحجز المهجور تنبيه نفس خط سير الرحلة بعد 24 ساعة - وفي بعض الأحيان لا يكون خط سير الرحلة هذا بالسعر الذي تخلى عنه المسافر، لأن الأجرة تغيرت بين عشية وضحاها. لا يزال مشغل تحذير التوقف عن الاستخدام الذي أعده شخص ما قبل عامين يتم تشغيله عندما ينخفض ​​عدد المستخدمين النشطين يوميًا على التطبيق، ولكنه لا يعرف أن المشترك حاليًا في رحلة وليس يتوقف عن الاستخدام بالفعل، فقط في إجازة. ثلاثة آليات "مؤتمتة"، لا يعرف أي منها بالآخر، ولا يمتلك أي منها رؤية متماسكة لمكان وجود المسافر في دورة حياة الرحلة.

تستعرض هذه المقالة كيف يجب أن تبدو أتمتة الإشعارات الفورية للسفر بالفعل - بنية مسار العمل، وليس بث تأكيدات الحجز مع مشغل حجز مهجور مضاف - وتشحن خمسة مخططات مسارات عمل مصممة للسفر مع التوقيت، ومعايير الخروج للحظة تغيير الأجرة، والتعامل أثناء الرحلة المشغل بواسطة تحديد الموقع الجغرافي، ورياضيات الإيرادات التي تحول كل منها إلى بند قابل للدفاع عنه لعمليات الإعلانات وفريق الولاء.

لماذا تتسبب "الإشعارات الفورية المؤتمتة" الخاصة بك في خسارة الإيرادات في لحظة تغيير الأجرة

لقد كان لكلمة الأتمتة نفس العمل غير المكتسب في السفر كما هو الحال في التجارة الإلكترونية، والبرمجيات كخدمة، والنشر. عندما تتحدث معظم فرق إدارة علاقات العملاء في مجال السفر عن إشعارات الدفع الآلية للسفر، فإن ما يعنونه هو جدولة البث المشغلة بالأحداث: يتم تشغيل إشعار عند حدوث حدث معروف، بدون حالة، بدون تقسيم، بدون فترات انتظار بين اللمسات، بدون شروط خروج، وبشكل حاسم - بدون وعي بأن العرض الأساسي قد لا يكون صالحًا بحلول وقت تشغيل اللمسة الثانية.

سير العمل هو شيء مختلف. سير العمل هو رحلة متعددة الخطوات مع حالة. إنه يعرف متى تخلى المسافر عن الحجز، وما هو السعر الذي شاهده، وما هو السعر المعروض حاليًا على هذا المسار، وما هي حالة رحلته، وما هي الشروط التي تلغي الرحلة. لا يقوم سير عمل الحجز المهجور بتشغيل إشعار تذكيري واحد بعد 24 ساعة. إنه يتحقق مما إذا كان السعر لا يزال صالحًا قبل كل لمسة، ويخرج من سير العمل في اللحظة التي يكتمل فيها الحجز، ويخرج بشكل منفصل إذا تغير السعر - لأن إرسال "أكمل حجزك بقيمة 399 دولارًا" إلى مسافر عندما يكون السعر الآن 529 دولارًا يدمر الثقة بطريقة لا تبررها أي عملية استرداد حجز.

هذه الجملة الأخيرة هي الفرق. مشغلات الأحداث ليس لديها ذاكرة للحالة الخارجية. سير العمل لديه. إذا استمرت أتمتة الحجز المهجور في إعادة الاتصال بالمسافرين بالسعر القديم بعد تغيير السعر، فليس لديك أتمتة. لديك مشغل لم يخبره أحد بالتحقق.

بالنسبة لفريق إدارة علاقات العملاء في سوق متوسطة الحجم في مجال السفر، فإن هذا التمييز هو الفرق بين قيمة عمر العميل المتكرر للحجز التي تتضاعف وتلك التي تتآكل بسبب الأخطاء المدمرة للثقة في لحظة تغيير السعر. ثلاثة مشغلات تعمل بالتوازي تنتج ثلاث قنوات احتكاك. خمسة سير عمل تعمل بالتنسيق تنتج رحلة واحدة لكل مسافر لكل مرحلة رحلة، متفرعة ومحددة بحالة الحجز، وصلاحية السعر، وحالة الرحلة. نتائج البحث في الصفحة الأولى لهذا المصطلح الرئيسي تؤطر المشكلة على أنها "5 حالات استخدام للسفر" وتجيب بقائمة أدوات. هذا ليس السؤال الذي يطرحه مراجعة الاحتفاظ الخاصة بك يوم الثلاثاء.

تشريح مسار عمل الإشعارات الفورية للسفر

قبل المخططات، المفردات. يتم بناء سير عمل إشعارات الدفع للسفر من ستة أنواع من العقد. بمجرد أن تعرف ما يفعله كل منها، تقرأ كل مخطط كرسم بياني، وليس كوصف.

البداية. نقطة الدخول. تحدد عقدة البداية كيفية تشغيل سير العمل، إما عن طريق حدث مشترك (booking_initiated، booking_abandoned، fare_changed، geolocation_changed، trip_completed) أو عن طريق مرشح جمهور (lifecycle_stage، loyalty_tier، last_active). يحتوي سير العمل على عقدة بداية واحدة بالضبط.

انتظر. تأخير. عقدة الانتظار (WAIT) تحتجز المشترك لمدة محددة (دقائق للتفاعل أثناء الرحلة، ساعات لتحديد وتيرة الحجز المهجور، أيام لتحديد وتيرة ما قبل الرحلة) أو حتى وقت تقويم محدد باستخدام دلالات wait_until المرتبطة بسمة المشترك — departure_date - 7 days، departure_date - 1 day، trip_completion_date + 1 year. الانتظارات هي الطريقة التي يفي بها سير العمل بحدث مستقبلي معروف، وليس فقط حدث ماضٍ معروف.

قرار. فرع ثنائي الاتجاه. تتحقق عقدة القرار (DECISION) من شرط خاص بكل مشترك: هل اكتمل الحجز، هل السعر لا يزال صالحًا (يُقرأ من سمة مشترك يقوم نظام الحجز بتحديثها)، هل مستوى الولاء أعلى من الفضي، هل المسافر حاليًا في رحلة. تقوم عقد القرارات بتقييم عوامل التصفية للأحداث وعوامل تصفية الجمهور؛ لا تستهلك استجابات طلبات HTTP مباشرة. النمط الذي يجلب الحالة الخارجية إلى سير العمل هو أن إجراء HttpRequest يشغل النظام الخارجي، ويكتب النظام الخارجي مرة أخرى إلى سمة مشترك عبر واجهة برمجة تطبيقات PushEngage REST، ويقرأ DECISION السمة.

تقسيم المسار. تفرع قائم على النسبة المئوية. تقوم عقد SPLIT_PATH بتوجيه المشتركين عبر المسارات بناءً على النسب المئوية المحددة: 50/50 لاختبار A/B على مبالغ الخصم للحجز المهجور، 33/33/34 لاختبار وقت إرسال ثلاثي المسارات لتذكيرات ما قبل الرحلة. بمجرد حصولك على فائز، تقوم بترقية هذا المسار إلى 100٪.

إجراء. العمل نفسه. ترسل عقد الإجراء (ACTION) إشعارًا فوريًا، وتضيف المشترك إلى شريحة، وتحدث سمات مخصصة، وتطلق HttpRequest إلى نظام حجز أو بوابة SMS، وتبدأ سير عمل آخر، أو توقفه. يدعم PushEngage Workflows أحد عشر نوعًا من الإجراءات. الأكثر فائدة للسفر هي SendPushNotification، و UpdateAttribute، و HttpRequest، و Workflow.Start (لتسلسل ما قبل الرحلة إلى أثناء الرحلة إلى ما بعد الرحلة).

نهاية / خروج. المحطة النهائية. تشير النهاية (END) إلى الخاتمة الطبيعية. تشير الخروج (EXIT) إلى إنهاء مبكر — في مسار "لا" في القرار عندما لم يعد المسافر مؤهلاً، عند تشغيل قاعدة التهدئة، أو عند تحقيق الهدف (اكتمال الحجز، إلغاء الرحلة، إلغاء صلاحية السعر).

كل مخطط أدناه يتكون من هذه القطع الست.

خمسة مخططات لمسارات العمل للسفر

هذه ليست قوالب. إنها مخططات عمل. يسرد كل منها المشغل ونوع التشغيل وتسلسل العقد ومعايير الخروج ومقياس الاحتفاظ بالسفر الذي تم بناؤه لتحريكه. يمكنك رفع كل منها إلى منشئ PushEngage Workflows وشحن الإصدار الأول في أقل من ساعة. يغطي دليل إشعارات السفر القديم حالات الاستخدام الأوسع التي تنفذها هذه المخططات.

المخطط 1 - الترحيب + رعاية الحجز الأول

• المشغل (البداية): الحدث PushEngage.Subscriber.Added أو browse_destination_page_view
• نوع التشغيل: فردي (رحلة ترحيب واحدة لكل مسافر في نافذة 90 يومًا)
• التدفق: دفعة ترحيبية مع الوجهات الأكثر شيوعًا ← انتظار يوم واحد ← دفعة تفضيلات الوجهة تسأل عن أنواع الرحلات المهمة (شاطئ، تزلج، عطلة مدينة، عمل) ← انتظار يومين ← قرار: هل بدأ المشترك في الحجز؟ ← المسار نعم: سلسلة إلى المخطط 2 إذا تخلى، وإلا دع سير عمل ما قبل الرحلة يتولى الأمر بعد اكتمال الحجز ← المسار لا: أرسل دفعة توصية بثلاث وجهات منسقة، أضف إلى شريحة active_browsers، إنهاء
• معايير الخروج: هدف booking_completed
• مقياس السفر: معدل التحويل من التصفح إلى الحجز الأول في اليوم السابع.

المخطط 2 - التخلي عن الحجز مع خروج تغيير الأجرة (أتمتة إشعارات الدفع للتخلي عن الحجز)

• المشغل (البدء): حدث مخصص booking_abandoned مع حمولة itinerary_id
• نوع التشغيل: متعدد متوازي (كل حجز تم التخلي عنه هو مثيل سير عمل خاص به)
• التدفق: انتظار ساعة واحدة ← إجراء: طلب HttpRequest GET إلى نقطة نهاية التحقق من الأجرة لنظام الحجز الخاص بك لـ itinerary_id. يكتب نظام الحجز مرة أخرى إلى سمة مشترك عبر واجهة برمجة تطبيقات PushEngage REST - fare_status = valid أو fare_status = invalidated - في غضون ثوانٍ ← قرار: مرشح الجمهور fare_status = valid؟ ← المسار لا: أرسل دفعة “تغيرت أجرتك، إليك خيارات مشابهة بالسعر الجديد” وإنهاء (إعادة توجيه سلسة، لا انتهاك للثقة) ← المسار نعم: دفعة تذكير بالأجرة الأصلية ← انتظار 24 ساعة ← كرر التحقق من الأجرة عبر HttpRequest، ثم قرار بشأن fare_status = valid ومرشح الجمهور booking_completed = false ← المسار نعم: تذكير #2 برمز ترويجي بنسبة 10% ← انتظار 48 ساعة ← تذكير نهائي بعرض أقوى ← إنهاء
• معايير الخروج: هدف booking_completed مطابق لـ itinerary_id من المشغل أو مرشح الجمهور fare_status = invalidated
• مقياس السفر: قيمة الحجز المستردة لكل حجز تم التخلي عنه. هذا هو سير العمل الذي يحتوي على الخط الأكثر قابلية للدفاع عنه في الصفحة. تغطي مشاركة 6 نصائح لتقليل التخلي عن الحجز النسخة اليدوية التكتيكية لهذا المخطط؛ تضيف النسخة الخاصة بسير العمل خروج التحقق من صحة الأجرة الذي يحول الاسترداد التكتيكي إلى استرداد يحافظ على ثقة العلامة التجارية.

المخطط 3 - رعاية ما قبل الرحلة (حساب تاريخ المغادرة)

هذا هو سير عمل دفعة إشعار ما قبل الرحلة الذي يوضح دلالات wait_until المرتبطة بسمة مشترك.

• المشغل (البدء): حدث مخصص booking_completed (الذي يكتب departure_date إلى سمة مشترك)
• نوع التشغيل: واحد لكل حجز
• التدفق: انتظر حتى departure_date - 14 يومًا → إشعار "رحلتك بعد أسبوعين" مع توصيات التعبئة وتوقعات الطقس → انتظر حتى departure_date - 7 أيام → إشعار إيرادات إضافية (ترقية مقعد، ترقية غرفة، إضافة تأجير سيارة، نقل المطار) → انتظر حتى departure_date - 1 يوم → إشعار تذكير بتسجيل الوصول مع رابط بطاقة الصعود إلى الطائرة عبر الهاتف المحمول → انتظر حتى departure_date → إشعار رحلة سعيدة، انتهى
• معايير الخروج: الهدف booking_cancelled
• مقياس السفر: الإيرادات الإضافية لكل حجز. اللمسة قبل 7 أيام هي اللحظة الأعلى تأثيرًا للإيرادات الإضافية.

المخطط 4 - تحديد الموقع الجغرافي أثناء الرحلة (أتمتة إشعارات الدفع لتحديد الموقع الجغرافي)

• المشغل (البدء): حدث مخصص geolocation_changed (يتم تشغيله بواسطة تطبيق الهاتف المحمول الخاص بك عندما يبلغ الجهاز عن إحداثيات جغرافية جديدة) وفلتر جمهور trip_in_progress = true
• نوع التشغيل: متعدد متوازي
• التدفق: قرار: هل وصل المسافر إلى مدينة الوجهة (يقارن فلتر الجمهور إحداثيات الموقع الجغرافي بسياج جغرافي للوجهة مخزن كسمة للمشترك)؟ → المسار نعم: إجراء إرسال إشعار توصيات محلية (فنادق، مطاعم، أنشطة محلية مرتبطة بالوجهة)، إجراء طلب HTTP لواجهة برمجة تطبيقات الطقس → إذا كان تنبيه الطقس مبررًا، إجراء إرسال إشعار الطقس → انتهى → المسار لا: خروج (المسافر في طريقه، ليس في الوجهة)
• ساعات الهدوء: مع مراعاة المنطقة الزمنية للمشترك. يحل قسم 9.4 من ملف Workflows.md ساعات الهدوء حسب المنطقة الزمنية للمشترك أولاً، ثم المنطقة الزمنية للموقع، ثم التوقيت العالمي المنسق. بالنسبة لسير العمل أثناء الرحلة، هذا يعني أن المنطقة الزمنية تحترم الوقت المحلي للوجهة، وليس السوق الرئيسي للعلامة التجارية. الإشعارات غير الحرجة تستخدم skip؛ تنبيهات السلامة والطقس تستخدم reschedule لضمان التسليم
• معايير الخروج: الهدف trip_completed
• مقياس السفر: معدل التفاعل أثناء الرحلة والإيرادات الإضافية أثناء الرحلة. ملاحظة: geolocation_changed ليس نوع مشغل مدمج - إنه PushEngage.CustomEvent يقوم تطبيق الهاتف المحمول الخاص بك بتشغيله عند تحديث موقع الجهاز، والتحقق عند الوصول إلى الوجهة هو فلتر جمهور على سمات المشترك التي يحتفظ بها التطبيق. منشور إشعارات الموقع الجغرافي يغطي أساس التقسيم الذي يمتد إليه هذا المخطط.

المخطط 5 - مراجعة ما بعد الرحلة + إعادة الحجز للمشابهين

• المشغل (البدء): حدث مخصص trip_completed
• نوع التشغيل: متعدد تسلسلي
• التدفق: انتظر 3 أيام → إشعار طلب مراجعة يشير إلى الوجهة بالاسم → انتظر حتى trip_completion_date + 365 يومًا (بعد عام) → إشعار "هل أنت مستعد لرحلتك القادمة؟" مع عرض مشابه للوجهة بناءً على نوع الرحلة السابقة → انتظر 7 أيام → قرار: هل بدأ المسافر حجزًا؟ → المسار نعم: ربط بالمخطط 1 أو 2 → المسار لا: خروج
• معايير الخروج: حدث booking_initiated جديد أو unsubscribed
• مقياس السفر: معدل إعادة الحجز خلال 12 شهرًا. هذا هو المخطط الأطول تشغيلًا - حوالي 13 شهرًا - والأكثر تأثيرًا على القيمة الدائمة. نمط التشابه السنوي هو نظير السفر لعمليات استعادة العملاء بعد الشراء في التجارة الإلكترونية، مع تكييفه مع الإيقاع الموسمي الذي يتبعه مشترو السفر بالفعل.

تقسيم مراحل دورة الحياة، واختبار A/B، وساعات الهدوء حسب المنطقة الزمنية للوجهة، ومعايير الخروج موجودة داخل مسار العمل

النمط السائد في مقالات دفع السفر هو سرد هذه المفاهيم الأربعة كـ "أفضل الممارسات" - نقاط عامة في نهاية منشور استراتيجية، منفصلة عن الحملات التي تستخدمها. هذا هو الإطار الخاطئ. إنها ليست أفضل الممارسات التي تجلس بجوار سير العمل. إنها سير العمل.

مفهوم	تأطير أفضل الممارسات (خاطئ)	تأطير عقدة سير العمل (صحيح)
تقسيم مراحل دورة الحياة	"تقسيم المسافرين حسب مرحلة الرحلة"	عقدة قرار (DECISION) على سمة المشترك lifecycle_stage (تصفح / بدأ الحجز / قبل الرحلة / أثناء الرحلة / بعد الرحلة / منتهي الصلاحية) التي توجه المسافرين قبل الرحلة إلى تنبيهات إضافية، والمسافرين أثناء الرحلة إلى سير عمل تحديد الموقع الجغرافي، والمسافرين بعد الرحلة إلى مراجعات وإعادة حجز مشابهة.
اختبار A/B	"اختبر دائمًا A/B نصوصك الخاصة بالحجز المهجور"	عقدة تقسيم المسار (SPLIT_PATH) بتخصيص 50/50، ومشتركين موزعين بالتساوي لكل مسار، وحقل winner_edge_id الذي يروج للفائز بنسبة 100٪ بمجرد وصول الاختبار إلى دلالة - معظم اختبارات A/B للسفر تعمل على مبلغ الخصم في التذكير رقم 2.
ساعات الهدوء حسب المنطقة الزمنية للوجهة	"لا ترسل في الساعة 3 صباحًا"	خيار على مستوى سير العمل مع timezone: subscriber وإعداد fallback يقوم إما بتخطي الإرسال (تنبيهات غير حرجة) أو إعادة جدولته لدقيقة واحدة بعد انتهاء ساعات الهدوء (السلامة، الطقس، تغيير البوابة) - أمر بالغ الأهمية لسير العمل أثناء الرحلة حيث يكون التوقيت المحلي للمشترك هو الوجهة، وليس السوق الرئيسي للعلامة التجارية.
معايير الخروج	"أوقف تسلسل الحجز المهجور بمجرد قيامهم بالحجز"	قاعدة على مستوى سير العمل تتحقق من المسافر مقابل هدف booking_completed وسمة fare_status = invalidated قبل كل عقدة، وتلغي سير العمل إذا تطابق أي منهما - الشرط الثاني هو ما لا يصفه أي نتيجة بحث SERP.

الفرق مهم لأن نقاط أفضل الممارسات سهلة الموافقة عليها وصعبة التنفيذ. عقد سير العمل يتم فرضها بواسطة المحرك. عقدة القرار تعمل في كل مرة. عقدة تقسيم المسار توازن كل مسافر. آلية الرجوع لساعات الهدوء تعمل دون أن يتذكر أحد التحقق من المنطقة الزمنية للوجهة. قاعدة الخروج تلغي سير عمل الحجز المهجور سواء كان مالك الحملة منتبهًا أم لا.

بالنسبة لتدفق الحجز المهجور في المخطط 2، هذا يعني أنه في اللحظة التي يحجز فيها المسافر - في الساعة 1، أو الساعة 30، أو الساعة 73 من سير العمل - يتم تشغيل قاعدة الخروج، ويتم إلغاء سير العمل لهذا المسافر، ولن يتم إرسال المزيد من تنبيهات "أكمل حجزك" لشخص دفع بالفعل بالأمس. بشكل منفصل، في اللحظة التي تتغير فيها الأجرة ويقوم نظام الحجز بتحديث fare_status = invalidated، يخرج سير العمل بسلاسة ويرسل تنبيه استرداد "تغيرت الأجرة، إليك خيارات مشابهة". لا يوجد انتهاك للثقة. لا مكالمة غاضبة لخدمة العملاء.

تنسيق قنوات متعددة: إشعارات الويب، إشعارات التطبيق، الرسائل القصيرة، واتساب، البريد الإلكتروني

تدير العلامات التجارية للسفر قنوات أكثر من فرق التجارة الإلكترونية أو البرمجيات كخدمة (SaaS) أو الناشرين. دفع الويب لتدفق حجز سطح المكتب. دفع التطبيق للمسافرين الذين قاموا بتنزيل تطبيق العلامة التجارية. الرسائل القصيرة (SMS) كقناة مقاومة لتجوال البيانات للتنبيهات الهامة أثناء الرحلة (تغيير البوابة، تأخير الرحلة، الطقس). واتساب لخدمة العملاء عالية اللمس والمسافرين الدوليين في المناطق التي يكون فيها واتساب هو برنامج المراسلة الافتراضي. البريد الإلكتروني كحاوية لجدول الرحلة قبل الرحلة الطويلة. تجميع كل الخمسة داخل سير عمل واحد - اختيار القناة التي تتطابق مع حالة المشترك - هو ما يحدث الفرق بين فريق إدارة علاقات العملاء (CRM) الذي يقدم رحلة متماسكة وفريق يضطر للاعتذار عن إشعار الساعة 3 صباحًا "رحلتك في الوقت المحدد" الذي أيقظ مسافرًا في منطقة زمنية مختلفة.

رحلة تغيير البوابة أثناء الرحلة المجمعة تبدو كالتالي:

• البداية: حدث مخصص gate_change لجدول رحلة حيث trip_in_progress = true
• قرار: هل المسافر يستخدم تطبيق الهاتف المحمول الخاص بالعلامة التجارية حاليًا؟
  • نعم: إجراء إرسال إشعار عبر التطبيق (أقل احتكاكًا، تسليم مدرك لتجوال البيانات)
  • لا: استمر
• قرار: هل المسافر يتجول دوليًا (فلتر الجمهور على country لا يساوي home_country)؟
  • نعم: إجراء إرسال رسالة نصية قصيرة عبر HttpRequest إلى Twilio أو Plivo (الرسائل القصيرة تعتمد على شبكة الاتصالات الخلوية، وليس البيانات - مقاومة عندما تكون بيانات التجوال محدودة)
  • لا: إجراء إرسال إشعار عبر الويب (قد يكون المسافر على شبكة Wi-Fi بالفندق)
• إجراء: HttpRequest إلى ESP لتحديث ملخص جدول الرحلة التالي عبر البريد الإلكتروني
• إنهاء عند gate_acknowledged أو flight_boarded

هوية مسافر واحدة، سير عمل واحد، أربع قنوات مختارة حسب الحالة. القناة الأقل تكلفة الممكنة تأتي أولاً. الرسائل القصيرة - الأكثر تكلفة لكل إرسال - لا يتم إرسالها إلا عندما يكون المسافر يتجول دوليًا وتكون الرسالة ذات أهمية زمنية. قامت Booking.com بتأطير المراسلة عبر الهاتف المحمول على أنها "تفاعل عملاء في الوقت الفعلي" بدلاً من التسويق الجماعي؛ سير العمل المجمع هذا هو نفس الفلسفة المعبر عنها كبنية سير عمل.

تشغيل هذا باستخدام أدوات منفصلة يعني خمس تسجيلات دخول للبائعين، ومحركي تقسيم يختلفان حول من هو حاليًا في الرحلة، ولا يوجد إسناد إيرادات واحد لكل مسافر لكل قناة. القيام بذلك داخل محرك سير عمل واحد يعني هوية مسافر واحدة، ومجموعة واحدة من منطق القرار، وتقرير قمع واحد يوضح أين تتعطل الرحلة فعليًا. إجراء HttpRequest (Workflows.md §5.7) هو ما يجعل التنسيق عبر القنوات ممكنًا - فهو يربط محرك سير العمل ببوابة الرسائل القصيرة، و ESP، ونظام الحجز دون الحاجة إلى أداة تنسيق منفصلة.

رياضيات الاحتفاظ: رفع معدل تحويل الحجز والقيمة الدائمة لإعادة الحجز بأحجام تذاكر السفر

تحقيق الدخل من السفر هو مجال ذو قيمة عالية. تتراوح قيم الحجوزات من رحلات قصيرة المدى بقيمة 300 دولار إلى باقات عطلات بقيمة 5000 دولار أو أكثر - مما يغير حسابات التكلفة مقارنة بالتجارة الإلكترونية (عربات تسوق بقيمة 50-200 دولار) و SaaS (99-999 دولار سنويًا). يتتبع PushEngage Workflows نفس الأرقام الثلاثة في كل عقدة - في قائمة الانتظار، مكتملة، تم الخروج منها - وينطبق نفس نمط تحليلات مستوى العقدة. إيرادات كل حجز تم استرداده تفوق بكثير إيرادات كل عربة تسوق تم استردادها، مما يجعل المساهمة في الأرباح والخسائر لسير العمل أسهل في الدفاع عنها.

إليك كيف تبدو تحليلات مستوى العقدة لسير عمل نشط للحجوزات المهجورة في وكالة سفر عبر الإنترنت متوسطة الحجم مع 5000 حجز مهجور شهريًا بمتوسط قيمة 1200 دولار (أرقام توضيحية):

عقدة	في الانتظار	مكتمل	خرج	ملاحظات
البداية (حجز_مهجور)	0	5,000	0	جميع مسارات الرحلات المهجورة تدخل
انتظر ساعة واحدة	92	4,900	8	تم حجز 8 في الساعة الأولى بدون أي تدخل
الإجراء: التحقق من سعر الرحلة عبر طلب HTTP	0	4,900	0	يقوم نظام الحجز بتحديث السمة fare_status
القرار: حالة السعر صالحة	0	4,410	490	تم إلغاء صلاحية 490 مسار رحلة قبل أول تدخل - خروج سلس عبر رسالة دفع "تغير السعر"
الإجراء: تذكير رقم 1 (السعر الأصلي)	0	4,410	0	تم إرسال التذكير الأول
انتظر 24 ساعة	134	3,950	326	تم حجز 326 بعد التذكير رقم 1
التحقق الثاني من السعر + القرار	0	3,720	230	تم إلغاء صلاحية 230 مسار رحلة أخرى - خروج سلس
الإجراء: تذكير رقم 2 + عرض ترويجي بنسبة 10٪	0	3,720	0	التذكير الثاني
انتظر 48 ساعة	78	3,200	442	تم حجز 442 آخرين بعد التذكير رقم 2
الإجراء: تذكير أخير + عرض أقوى	0	3,200	0	الدفع النهائي
نهاية	غير متاح	3,200	غير متاح	لم يتم الحجز 3200

في هذه المجموعة، تم تحويل 776 مسار رحلة مهجورة إلى حجوزات أثناء وجودها داخل سير العمل - معدل استرداد بنسبة 15.5٪. بمتوسط قيمة حجز 1200 دولار، هذا يعني 931,200 دولار من الإيرادات المستردة شهريًا، أو 11.2 مليون دولار سنويًا. وفرت مخارج تغيير الأسعار 720 علاقة إضافية للمسافرين من تلقي رسالة دفع مضللة "أكمل حجزك بقيمة 399 دولارًا" عندما كان السعر قد ارتفع بالفعل - 720 تذكرة خدمة عملاء وانتهاكات للعلامة التجارية منعها سير العمل، بشكل منفصل عن زيادة تحويل الحجوزات.

تتغير حسابات التكلفة للسفر. لا تكلف رسائل الويب والتطبيق أي شيء لكل إرسال بعد الاشتراك. تبلغ تكلفة الرسائل القصيرة عبر Twilio حوالي 0.0079 دولار لكل رسالة داخل الولايات المتحدة و 0.05-0.30 دولار لكل رسالة دولية - مع 5000 مجموعة حجوزات مهجورة شهريًا بنسبة 10٪ من الرسائل القصيرة أثناء الرحلة، تبلغ تكلفة الرسائل القصيرة 40-150 دولارًا لكل مجموعة. تسعير WhatsApp Business Platform يعتمد على الجلسة. يتوسع البريد الإلكتروني مع عقدة مزود خدمة البريد الإلكتروني. تتمثل مهمة سير العمل في استخدام القناة الأقل تكلفة الممكنة أولاً والتصعيد إلى الرسائل القصيرة أو واتساب فقط عندما تتطلب الحالة ذلك. البند الذي يقرأ "استرد سير عمل الحجوزات المهجورة 931 ألف دولار من حجوزات شهرية بتكلفة قناة شاملة 1500 دولار" هو نوع بيان الأرباح والخسائر الذي يفوز بمحادثة ميزانية العام المقبل.

قم ببنائها في مسارات عمل PushEngage لعلامتك التجارية للسفر

كل من مخططات السفر الخمسة تتوافق مباشرة مع مكونات PushEngage Workflows. التعيين:

مخطط	أنواع العقد المستخدمة	أنواع الإجراءات المستخدمة	خيار سير العمل
الترحيب + رعاية الحجز الأول	بداية، انتظار، قرار، إجراء، نهاية	إرسال إشعار دفع، إضافة شريحة	نوع التشغيل: فردي
الحجز المهجور مع خروج تغيير السعر	البداية، انتظار، إجراء، قرار، نهاية	إرسال إشعار دفع، التحقق من السعر عبر طلب HTTP، تحديث السمة	نوع التشغيل: متعدد متوازي؛ الخروج عند الهدف booking_completed أو فلتر الجمهور fare_status=invalidated
رعاية ما قبل الرحلة (حساب تاريخ المغادرة)	البداية، انتظار (انتظار_حتى)، إجراء، نهاية	إرسال إشعار دفع	نوع التشغيل: واحد لكل حجز؛ wait_until مرتبط بسمة departure_date
الموقع الجغرافي أثناء الرحلة	بداية، قرار، إجراء، نهاية	إرسال إشعار دفع، التحقق من السعر عبر طلب HTTP، تحديث السمة	نوع التشغيل: متعدد متوازي؛ مشغل حدث مخصص + مرشح جمهور
مراجعة ما بعد الرحلة + إعادة حجز شبيه	البدء، انتظار، إجراء، انتظار (انتظار_حتى)، إجراء، قرار، إنهاء	إرسال إشعار دفع	نوع التشغيل: متسلسل متعدد

يأتي محرك سير العمل مع أكثر من 60 قالبًا جاهزًا تغطي اللبنات الأساسية لكل مخطط. معظم القوالب مصممة للتجارة الإلكترونية، ولكن التكيف مع السفر سهل: يصبح منطق قالب عربة التسوق المهجورة سير عمل حجز مهجور عن طريق تبديل حدث المشغل إلى booking_abandoned، وإضافة نمط التحقق من الأجرة لتحديث طلب HTTP والسمات من المخطط 2، واستخدام معيار خروج لإبطال الأجرة جنبًا إلى جنب مع booking_completed. يناسب قالب الترحيب المخطط 1 مباشرة. قالب الإشعارات المجمعة الجغرافية - الموجود بالفعل في الكتالوج - هو الأساس لسير العمل أثناء الرحلة للمخطط 4.

لسياق دفع السفر الأوسع - حالات الاستخدام المتخصصة (الفنادق، الرحلات الجوية، تأجير العطلات) واستراتيجيات الموسمية - يدرج دليل إشعارات الدفع لموقع السفر القديم دليل إشعارات الدفع لموقع السفر أنواع الحملات التي تنفذها هذه المخططات.

لمسار التجربة الفوري، تمنحك الخطة المجانية 200 مشترك، وجميع القنوات (إشعارات الويب، إشعارات التطبيق، واتساب، الدردشة المباشرة)، ومحرك سير العمل الكامل من اليوم الأول. هذا يكفي لشحن المخططين 1 و 2 على دفعتك التالية من مسارات الرحلات المهجورة والتقاط تحليلات مستوى العقدة قبل اجتماع المراجعة ربع السنوي التالي. بالنسبة لوضع PushEngage العمودي للسفر - التسعير، والتكاملات، وأمثلة العملاء - فإن PushEngage للسفر هي الصفحة المقصودة الرسمية.

ما يغيره هذا

إذا أخذت شيئًا واحدًا من هذه المقالة، فخذ هذا: أتمتة إشعارات الدفع للسفر هي بنية سير العمل، وليست بث تأكيدات الحجز مع مشغل حجز مهجور مضاف. رحلة الحجز المهجور التي تنتهي بسلاسة عند تغيير الأجرة، وسير العمل قبل الرحلة الذي يتم تشغيله عند departure_date - 7 days، وسير العمل الجغرافي أثناء الرحلة الذي يحترم المنطقة الزمنية للوجهة - كلها لها نفس الشكل. بداية واحدة، بعض الانتظارات، بعض القرارات، بعض الإجراءات، نهاية واحدة. لا يمكن لثلاثة مشغلات مستقلة القيام بذلك. يمكن لمحرك سير عمل واحد. يتضاعف عمر العميل المتكرر من هناك.

ابدأ بالخطة المجانية لشحن المخطط الأول على دفعتك التالية من مسارات الرحلات المهجورة.