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

جاء انزلاق معدل التنشيط في المقدمة أولاً في مراجعة نمو يوم الاثنين. ثمانية وعشرون بالمائة. نفس الربع الماضي. نفس الربع الذي سبقه. تحويلك من تجريبي إلى مدفوع يبلغ 14٪. كان معدل صافي الاحتفاظ بالإيرادات لديك 108٪ قبل اثني عشر شهرًا وهو الآن 102٪. يطرح مجلس الإدارة أسئلة حول ما تغير. لم يتغير شيء. هذه هي المشكلة.

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

هذا ما تبدو عليه أتمتة الإشعارات الفورية لـ SaaS في معظم فرق نمو المنتج الموجه (PLG) في السوق المتوسطة: أربعة إلى ستة مشغلات غير متصلة، مُقنّعة كأتمتة، تُعامل كقائمة حملة بدلاً من رسم بياني لسير العمل. لقد أصبحت كتيبات نمو المنتج الموجه (PLG) جيدة في أعمال تنشيط جانب المنتج على مدار العقد الماضي، وجاءت معظم المكاسب السهلة من تغييرات المنتج - إعادة تصميم تجربة الإعداد، وبادئات بيانات العينة، وقوائم التحقق المضمنة. النقاط العشر التالية لرفع مستوى التنشيط والنقاط الخمس التالية لصافي الاحتفاظ بالإيرادات ليست في المنتج. إنها في طبقة الأتمتة التي كان من المفترض أن يمتلكها فريق دورة الحياة ولم ينتهِ من بنائها أبدًا.

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

لماذا "الإشعارات الفورية الآلية" لـ SaaS الخاصة بك تعيق صافي الاحتفاظ بالإيرادات

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

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

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

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

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

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

البداية. نقطة الدخول. تحدد عقدة البداية (START) كيفية تشغيل سير العمل، إما عن طريق حدث مشترك (trial_signed_up، aha_moment_reached، usage_hit_80pct_of_plan_limit، dau_dropped_50pct) أو عن طريق مرشح جمهور يحدد المشتركين الذين يطابقون معايير محددة في وقت مجدول. يحتوي سير العمل على عقدة بداية واحدة بالضبط.

الانتظار. تأخير. تحتفظ عقدة الانتظار (WAIT) بالمشترك في هذه النقطة لمدة محددة: ساعات لاستعادة لحظة الإلهام (aha-moment)، أيام لتوقيت الفترة التجريبية إلى المدفوعة، أسابيع لدفعات التوسع. أو حتى وقت تقويمي محدد. الانتظار هو كيف يتعلم سير العمل ألا يكون مجرد بث لمرة واحدة.

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

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

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

إنهاء / خروج. المحطة النهائية. تحدد عقد الإنهاء والخروج اكتمال سير العمل وتحديث التحليلات. الإنهاء هو الاستنتاج الطبيعي. عادةً ما يُستخدم الخروج لإنهاء المسار لا مبكرًا في مسار لا لعقدة القرار عندما لم يعد المشترك مؤهلاً، أو للاختصار عندما يتم تحقيق الهدف - تمت ترقية الاشتراك، عاد المستخدم النشط يوميًا إلى المستوى الأساسي، تم الوصول إلى لحظة الإدراك.

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

خمسة مخططات لسير العمل لـ SaaS

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

المخطط 1 - سلسلة التنشيط (أتمتة إشعارات SaaS الفورية للإعداد)

• المشغل (البداية): حدث مخصص trial_signed_up
• نوع التشغيل: فردي (رحلة تنشيط واحدة لكل مشترك في نافذة 90 يومًا)
• التدفق: رسالة ترحيب فورية (بيان القيمة، وليس تفريغًا للميزات) → انتظار ساعة واحدة → رسالة جولة المنتج تركز على ميزة واحدة محددة للخطوة الأولى → انتظار 24 ساعة → قرار: هل وصل المشترك إلى حدث لحظة الإدراك (first_invoice_sent، first_dashboard_created، first_teammate_invited - أيًا كان ما يحدده منتجك كقيمة أولى)؟ → مسار نعم: رسالة تهنئة مع تلميح ترقية لطيف، إضافة إلى شريحة activated، إنهاء → مسار لا: إجراء Workflow.Start يربط بالمخطط 2 (استعادة لحظة الإدراك)، إنهاء
• معايير الخروج: هدف subscription_upgraded (لا مزيد من رسائل التنشيط بمجرد الدفع)
• مقياس SaaS: معدل التفعيل في اليوم السابع. بوابة القرار لمدة 24 ساعة هي اللحظة ذات التأثير الأكبر في الفترة التجريبية — قبل هذه البوابة، يكون المستخدم في مرحلة الاستكشاف، وبعد هذه البوابة يكون إما قد اقتنع أو بدأ في الابتعاد. بالنسبة للنص في أول لمستين، فإن قوالب إشعارات الدفع للتوعية تسرد الأشكال التي تنجح باستمرار.

المخطط 2 - استعادة لحظة "آها"

• المشغل (البدء): Workflow.Start من المخطط 1، أو فلتر الجمهور trial_signed_up_more_than_24h_ago AND aha_moment_not_reached
• نوع التشغيل: فردي
• التدفق: دفع مستهدف يذكر الخطوة المحددة التي علق فيها المشترك (“يبدو أنك لم تنشئ لوحة التحكم الأولى بعد — إليك جولة إرشادية مدتها 60 ثانية”) → انتظار 12 ساعة → قرار: تم الوصول إلى لحظة الإدراك؟ → المسار نعم: إجراء Workflow.Start مرة أخرى إلى فرع التهاني في المخطط 1، إنهاء → المسار لا: إرسال دفعة “هل تريد جولة إرشادية؟ ” مع رابط تقويم → انتظار 24 ساعة → قرار → إذا لم يحدث ذلك بعد، إجراء HttpRequest إلى قناة Slack الخاصة بنجاح العملاء للإبلاغ عن المستخدم للمتابعة البشرية، إنهاء
• معايير الخروج: الهدف aha_moment_reached أو subscription_cancelled
• مقياس SaaS: الوقت حتى تحقيق القيمة الأولى. بالنسبة لمنتجات PLG، فإن تحقيق القيمة الأولى في أقل من 7 أيام هو أقوى مؤشر منفرد للتحويل من الفترة التجريبية إلى المدفوعة. سير عمل استعادة لحظة الإدراك هو الرافعة التي تسحب الوقت حتى تحقيق القيمة الأولى من “حيثما يصل المستخدم بنفسه” إلى “حيثما يمكن أن يصل به توجيه إرشادي”.

المخطط 3 - التحويل من تجريبي إلى مدفوع (تسلسل الإشعارات الفورية من تجريبي إلى مدفوع)

• المشغل (البدء): حدث مخصص trial_ends_in_3_days
• نوع التشغيل: فردي
• التدفق: دفعة نهاية الفترة التجريبية (ملخص القيمة، بدون خصم) → انتظار يوم واحد → قرار: هل تم ترقية الاشتراك؟ → المسار نعم: خروج → المسار لا: دفعة نهاية الفترة التجريبية غدًا مع رابط دراسة حالة عميل → انتظار يوم واحد → قرار → نعم: خروج → المسار لا: دفعة اليوم الأخير بخصم محدود الوقت على الفواتير السنوية → إنهاء
• معايير الخروج: الهدف subscription_upgraded مطابق لـ trial_id في حدث المشغل. في اللحظة التي يقوم فيها المشترك بالترقية — في الساعة 6، أو الساعة 30، أو الساعة 70 من سير العمل — يتم إلغاء سير العمل لهذا المشترك ولن يتم إرسال اللمسات المتبقية أبدًا.
• مقياس SaaS: معدل التحويل من الفترة التجريبية إلى المدفوعة. هذا هو سير العمل الأكثر قابلية للدفاع عنه في خط الإيرادات. تجري العمليات الحسابية في قسم الاحتفاظ أدناه، ولكن كمرساة اتجاهية: كل 1% إضافي من التحويل من الفترة التجريبية إلى المدفوعة بسعر 99 دولارًا شهريًا مع 2000 فترة تجريبية شهرية يساوي تقريبًا 237,000 دولار من الإيرادات السنوية المتزايدة.

المخطط 4 - دفعة التوسع / الترقية

• المشغل (البدء): حدث مخصص usage_hit_80pct_of_plan_limit (مشتركون، مقاعد، استدعاءات API، مشاريع — أيًا كان ما يتم قياس خطتك به)
• نوع التشغيل: متعدد متسلسل (رحلة توسع واحدة في كل مرة لكل حساب؛ يتم تشغيل مثيل جديد في الربع التالي إذا وصلوا إلى الحد مرة أخرى)
• التدفق: انتظر يومًا واحدًا (لا تقم بالإطلاق فورًا عند تجاوز الحد؛ دع المستخدم ينهي ما كان يفعله) → دفعة تذكير لطيفة مع معاينة للاستخدام → انتظر 5 أيام → قرار: هل لا يزال عند 80٪ +؟ → المسار نعم: دفعة تركز على عائد الاستثمار مع دراسة حالة عميل في المستوى التالي → انتظر 7 أيام → قرار: هل تم ترقية الاشتراك؟ → نعم: إنهاء → المسار لا: إجراء HttpRequest لإطلاق مهمة CRM على مالك الحساب للتواصل مع نجاح العملاء → إنهاء
• معايير الخروج: الهدف subscription_upgraded. اخرج أيضًا عند subscription_cancelled (والذي يصبح إشارة إلى التوقف عن الاستخدام يتم التعامل معها بواسطة المخطط 5).
• مقياس SaaS: مساهمة NRR. إيرادات التوسع هي المقياس الذي يحدد تقييمات SaaS؛ سير عمل الترقية هو رافعة الأتمتة التي تحول إشارات الاستخدام المقاسة إلى إيرادات سنوية متكررة متوسعة قبل أن يُجبر الحساب على اتخاذ القرار عند التجديد.

المخطط 5 - منع التوقف عن الاستخدام

• المشغل (البدء): مرشح الجمهور dau_dropped_50pct_over_14d AND subscription_active
• نوع التشغيل: فردي (محاولة واحدة لمنع التوقف لكل مشترك لكل نافذة 90 يومًا)
• التدفق: دفعة إعادة إشراك تعرض ميزة لم يستخدمها المشترك مطلقًا → انتظر 5 أيام → قرار: هل عاد DAU إلى خط الأساس؟ → المسار نعم: أضف إلى شريحة re-engaged، إنهاء → المسار لا: إجراء HttpRequest لإطلاق مهمة CRM على مالك CS + إرسال دفعة ملاحظات “ما الذي يمكننا فعله بشكل أفضل؟“ مع استبيان بسؤال واحد → إنهاء
• معايير الخروج: شرط الجمهور dau_returned_to_baseline. اخرج أيضًا عند subscription_cancelled — وظيفة سير العمل قد انتهت في كلتا الحالتين.
• مقياس SaaS: صافي معدل التوقف عن الاستخدام. تصعيد HttpRequest إلى CRM هو العنصر الخاص بـ SaaS: عندما يفشل الاسترداد الخوارزمي، لا يستسلم سير العمل. إنه يسلم الحساب إلى ممثل CS بشري مع تعبئة السياق بالفعل.

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

تقسيم مراحل دورة الحياة، والاختبار A/B، ومعايير الخروج تعيش داخل سير العمل

النمط السائد لتسويق SaaS لهذه المفاهيم الثلاثة هو سردها كـ “أفضل الممارسات” — نقاط عامة في نهاية مقال، منفصلة عن الحملة التي تستخدمها. هذا هو الإطار الخاطئ. إنها ليست أفضل الممارسات التي تجلس بجوار سير العمل. إنها سير العمل.

مفهوم	تأطير أفضل الممارسات (خاطئ)	تأطير عقدة سير العمل (صحيح)
تقسيم مراحل دورة الحياة	“التقسيم حسب التجربة / التفعيل / الدفع / المعرض للخطر”	عقدة قرار (DECISION) تتحقق من lifecycle_stage (أو تحسبها من MRR + DAU + last-active) وتوجه المستخدمين الذين يدفعون إلى التوسع، والمستخدمين المعرضين للخطر إلى منع الانقطاع، والمستخدمين التجريبيين إلى التحويل من تجريبي إلى مدفوع.
اختبار A/B	"اختبر دائمًا نصوص نهاية الفترة التجريبية الخاصة بك باستخدام اختبار A/B"	عقدة تقسيم المسار (SPLIT_PATH) بتخصيص 50/50، ومشتركين موزعين بالتساوي لكل مسار، وحقل winner_edge_id يعزز الفائز إلى 100% بمجرد وصول الاختبار إلى دلالة إحصائية.
ساعات الهدوء	"لا ترسل في الساعة 3 صباحًا"	خيار على مستوى سير العمل مع start_at، end_at، timezone، وإعداد fallback الذي إما skip (يتخطى) الإرسال أو reschedule (يعيد جدولته) إلى دقيقة واحدة بعد انتهاء ساعات الهدوء - وهو أمر بالغ الأهمية لفرق B2B العالمية حيث يكون المدير المالي في لندن وقائد التطوير في سنغافورة ضمن نفس الخطة.
معايير الخروج	"توقف عن الإرسال إلى الأشخاص الذين قاموا بالترقية"	قاعدة على مستوى سير العمل تتحقق من المشترك مقابل فلتر جمهور أو هدف مُحفز قبل كل عقدة، وتلغي سير العمل إذا تطابق.

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

بالنسبة لمخطط التحويل من تجريبي إلى مدفوع أعلاه، هذا يعني في اللحظة التي يقوم فيها المشترك بالترقية - في الساعة 6، أو الساعة 30، أو الساعة 70 من سير العمل - يتم تفعيل قاعدة الخروج، ويتم إلغاء سير العمل لهذا المشترك، ولن يتم إرسال اللمسات المتبقية أبدًا. لا يوجد إشعار "لديك يوم واحد متبقٍ للترقية" لشخص قام بالترقية بالفعل بالأمس. لا يوجد إشعار Slack من المدير المالي يتساءل عما إذا كانت الفوترة قد تمت بالفعل.

إشعارات متعددة القنوات لـ SaaS: إشعارات الويب، إشعارات التطبيق، داخل التطبيق، البريد الإلكتروني، و Slack/CRM

يتم تشكيل سؤال اتساع القناة بشكل مختلف لـ SaaS مقارنة بـ eCommerce. القنوات المهمة لفريق B2B PLG ليست مجرد الدفع عبر الإشعارات والبريد الإلكتروني. إنها إشعارات الدفع عبر الويب لتطبيق الويب، وإشعارات الدفع عبر التطبيق لتطبيق SaaS للجوال، ورسائل داخل التطبيق للتفاعل داخل المنتج، والبريد الإلكتروني كخيار احتياطي عندما لا يتم الاشتراك في إشعارات الدفع، وتصعيد طلبات HTTP إلى Slack أو HubSpot/Salesforce عندما يحتاج شخص ما للتدخل. خمس قنوات تصعيد، كلها قابلة للتركيب داخل سير عمل واحد إذا كان محرك سير العمل يدعمها.

رحلة استعادة لحظة الإلهام (aha-moment) المركبة تبدو كالتالي:

• البداية: حدث trial_signed_up
• انتظر 24 ساعة
• قرار: هل وصل المشترك إلى حدث لحظة الإلهام؟
  • نعم: خروج (نجاح التفعيل، توجيه إلى فرع التهنئة في المخطط 1)
  • لا: استمر
• قرار: هل المشترك مسجل الدخول حاليًا إلى تطبيق الويب؟
  • نعم: إجراء - إرسال رسالة داخل التطبيق (أقل قناة تسبب احتكاكًا، لا حاجة للتصعيد بعد)
  • لا: استمر
• قرار: هل المشترك مشترك في إشعارات الدفع عبر الويب؟
  • نعم: إجراء - إرسال إشعار دفع عبر الويب إلى الخطوة المهجورة
  • لا: إجراء - إرسال بريد إلكتروني بنفس المحتوى
• انتظر 12 ساعة
• القرار: هل تم الوصول إلى لحظة الإلهام الآن؟
  • نعم: خروج
  • لا: إجراء طلب HTTP إلى قناة Slack لنجاح العملاء، وتعيين الحساب لممثل نجاح العملاء
• نهاية

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

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

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

رياضيات صافي الاحتفاظ بالإيرادات: الإيرادات لكل سير عمل، لكل قناة، لكل مرحلة من مراحل دورة الحياة

سير العمل الذي لا يمكن الدفاع عنه في اجتماع مراجعة الأعمال الربع سنوي التالي هو سير عمل سيتم إلغاؤه. وظيفة مدير دورة الحياة هي إظهار، بالدولارات أو نقاط صافي الإيرادات المتكررة، ما أنتجه كل أتمتة. تتوقف معظم المقالات حول إشعارات الدفع الآلية لـ SaaS عند معدل الفتح. هذا غير كافٍ. المقياس الصحيح هو الإيرادات الشهرية المتكررة المضافة لكل سير عمل، وتغير صافي الإيرادات المتكررة لكل ربع سنة، وانخفاض صافي التوقف عن العمل لكل فئة.

يتتبع PushEngage Workflows ثلاثة أرقام عند كل عقدة:

• المستخدمون في الانتظار: المشتركون الذين ينتظرون حاليًا عند هذه العقدة (عادةً انتظار أو إعادة جدولة لساعات هادئة)
• المستخدمون المكتملون: المشتركون الذين مروا عبر هذه العقدة
• المستخدمون الذين خرجوا: المشتركون الذين غادروا سير العمل عند هذه العقدة، إما لأن معايير الخروج تطابقت أو لأنهم ألغوا اشتراكهم

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

عقدة	في الانتظار	مكتمل	خرج	ملاحظات
البداية (تنتهي التجربة خلال 3 أيام)	0	2,000	0	تدخل جميع التجارب المطابقة
إجراء: إشعار دفع ينتهي قريبًا	0	2,000	0	تم إرسال الإشعار
انتظار يوم واحد	38	1,710	252	تمت ترقية 252 مشتركًا بعد اللمسة رقم 1 (تحويل بنسبة 12.6% باللمسة وحدها)
القرار: تم ترقية الاشتراك	0	1,710	0	لا يزال 1710 غير محوّلين
إجراء: غدًا تنتهي التجربة + دراسة حالة	0	1,710	0	تم إرسال الإشعار
انتظار يوم واحد	24	1,510	200	تمت ترقية 200 إضافي (تحويل إضافي بنسبة 10%)
إجراء: اليوم الأخير + خصم محدود الوقت	0	1,510	0	اللمسة النهائية
نهاية	غير متاح	1,510	غير متاح	1,510 لم يقوموا بالترقية

في هذه المجموعة، تحولت 452 تجربة إلى مدفوعة أثناء سير العمل (من أصل 2000) - بمعدل تحويل من تجربة إلى مدفوعة بنسبة 22.6٪ مدفوعًا بلمسات سير العمل الثلاث. بسعر 99 دولارًا للخطة الشهرية، يبلغ ذلك 44,748 دولارًا من الإيرادات الشهرية المتكررة المضافة لكل مجموعة، أو ما يقرب من 537,000 دولار من الإيرادات السنوية المتزايدة سنويًا إذا حافظت المجموعة على حجمها. الانتظار مرتين (اللمسة رقم 1 واللمسة رقم 2) هما أعلى نقاط الخروج في مسار التحويل، وهو النمط المتوقع: قرارات الترقية تتم في نوافذ الانتظار، وليس في نوافذ الإجراء. إذا أظهر سير العمل الخاص بك العكس - خروج مرتفع في عقد الإجراء، وخروج منخفض في الانتظار - فإن لمساتك تنطلق متأخرة جدًا ويجب تقصير فترات الانتظار.

تجري حسابات التكلفة بنفس طريقة التجارة الإلكترونية، مع إضافة قنوات خاصة بالبرمجيات كخدمة. رسائل الدفع عبر الويب والرسائل داخل التطبيق مجانية لكل إرسال بعد الاشتراك. تعتمد تكاليف البريد الإلكتروني على عقد مزود خدمة البريد الإلكتروني الخاص بك (Customer.io، Iterable، Klaviyo) - مع قائمة برمجيات كخدمة تضم 50,000 مشترك، عادةً ما يكلف إرسال واحد في نهاية التجربة مئات الدولارات لكل لمسة. من ناحية أخرى، فإن وقت نجاح العملاء البشري يكلف مالًا حقيقيًا: مندوب نجاح العملاء الذي يتعامل مع تصعيد لمدة 10 دقائق عبر Slack بتكلفة سنوية مجمعة تبلغ 90,000 دولار هو ما يقرب من 7.50 دولار لكل تصعيد. وظيفة سير العمل هي استخدام أرخص قناة ممكنة أولاً والتصعيد فقط عندما تتطلب الحالة ذلك. عندما يقرأ البند "استعاد سير عمل التحويل من تجربة إلى مدفوعة 44,748 دولارًا من الإيرادات الشهرية المتكررة في المجموعة الأخيرة بتكلفة إجمالية تبلغ 312 دولارًا لكل مجموعة"، فإن محادثة مراجعة الأعمال ربع السنوية تكون قصيرة.

ابنِها في PushEngage Workflows لـ SaaS الخاص بك

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

مخطط	أنواع العقد المستخدمة	أنواع الإجراءات المستخدمة	خيار سير العمل
سلسلة التفعيل	بداية، انتظار، قرار، إجراء، نهاية	SendPushNotification، AddSegment، Workflow.Start	نوع التشغيل: فردي
استعادة لحظة الإلهام	بداية، انتظار، قرار، إجراء، نهاية	SendPushNotification، HttpRequest، Workflow.Start	نوع التشغيل: فردي
التحويل من تجربة إلى مدفوعة	بداية، انتظار، قرار، إجراء، نهاية	إرسال إشعار دفع	نوع التشغيل: فردي؛ الخروج عند الهدف subscription_upgraded
دفعة التوسع / الترقية	بداية، انتظار، قرار، إجراء، نهاية	SendPushNotification، HttpRequest	نوع التشغيل: متسلسل متعدد
منع التراجع	بداية، انتظار، قرار، إجراء، نهاية	SendPushNotification، HttpRequest، AddSegment	نوع التشغيل: فردي؛ مشغل قائم على الجمهور

يأتي محرك سير العمل مع أكثر من 60 قالبًا جاهزًا تغطي كل تدفق من هذه التدفقات. تترجم القوالب ذات الشكل التجاري الإلكتروني (الترحيب، التخلي عن سلة التسوق، استعادة العملاء) بشكل نظيف إلى البرمجيات كخدمة عن طريق تبديل حدث المشغل وهدف شرط الخروج. تصبح قوالب الترحيب أساسًا لأتمتة إشعارات الدفع لتأهيل البرمجيات كخدمة - سلسلة التفعيل، استعادة لحظة الإلهام، وبقية سلسلة المخطط 1 اللاحقة. يصبح منطق قالب التخلي عن سلة التسوق منطق التحويل من تجربة إلى مدفوعة مع استبدال cart_abandoned بـ trial_ends_in_3_days واستبدال purchase بـ subscription_upgraded. البنية عمودية غير مقيدة؛ المفردات هي ما يتغير.

للحصول على نظرة أوسع حول كيفية ملاءمة PushEngage لحالة استخدام SaaS — التسعير، والتكاملات، وأمثلة العملاء — فإن PushEngage لـ SaaS هي الصفحة المقصودة الرسمية. لمسار التجربة الفوري: تمنحك الخطة المجانية 200 مشترك، وجميع القنوات (إشعارات الويب، إشعارات التطبيق، واتساب، الدردشة المباشرة)، ومحرك سير العمل الكامل من اليوم الأول. هذا يكفي لشحن مخطط التجربة إلى المدفوعة على دفعتك التالية والحصول على رقم MRR قابل للدفاع عنه لـ QBR التالي.

ما يغيره هذا

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

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