بدائل الإيميل والـ Push: صمموا خطوة تالية واضحة

الهدف من رسالة الـ email fallback هو مساعدة العميل يكمّل خطوة بعد ما خلّصها. جهّزوا الإيميل على Migma مع نفس المعلومات والوجهة المعتمدة بالـ notification الأساسية، واتركوا للـ journey owner يحدد أيمتى بيصير الإيميل مؤهل للإرسال.

السؤال الأساسي مش كيف نكرر الـ push notification بصيغة أطول، بل هل المستخدم بعده بحاجة للمعلومة؟ وهل الإيميل هو الـ channel الأنسب لهاللحظة؟ أي fallback بتجاهل الخطوات المنجزة بيتحوّل لتذكير مزعج بشيء العميل أصلاً خلّصه.

هيدا الدليل من Migma، وبيحدد workflow للمحتوى والموافقة عليه (acceptance) للفرق اللي بتستخدم multichannel platforms متل Customer.io. الدليل ما بيعتبر إنو Migma بتكتشف فشل تسليم الـ push تلقائياً أو بتتحكم بالـ fallback logic تبع أي منصة تانية.

حددوا شو يعني fallback بهالـ journey

كلمة "fallback" بتعبّر عن أكتر من حالة. ممكن الـ push notification ما توصل لأن المستخدم مش مفعّلها، أو مزوّد الإرسال يعطي تقرير بفشل التوصيل (failure)، أو حتى الإشعار يوصل بس الخطوة المطلوبة تضل مش منجزة. هالحالات مش متطابقة ولا بتتبدّل مكان بعضها.

سجّلوا الشرط الدقيق اللي بيعتمده الـ workflow. إذا كان الشرط هو "المهمة مش منجزة بعد انتهاء الوقت المحدد"، اكتبوها متل ما هيي. ما تسمّوها "فشل الـ push" بلا دليل تسليم واضح. الفرق هون بيأثر مباشرةً على الـ routing وعلى صياغة الإيميل.

دليل Customer.io حول استراتيجية القنوات بيشرح كيف تختاروا الـ channels وتنسّقوها بحسب سياق العميل. هيدا مرجع ممتاز لقرارات المحتوى، بس بيبقى على مسؤول الـ implementation يتأكد شو هي الإشارات (signals) والضوابط المتاحة فعلياً بالـ journey.

امشوا مع المهمة عبر 3 قرارات أساسية

أولاً، اتأكدوا إذا المهمة بعدها مطلوبة ومهمة. إذا العميل كمّل الـ setup، المفروض تذكير الـ setup يوقف فوراً. وإذا الموعد انلغى، التذكير صار إله هدف تاني. مجرد إنكم بعتوا إشعار سابق مش سبب كافي لتبعتوا رسالة جديدة.

ثانياً، شوفوا إذا الإيميل هو المسار الأنسب لهالشخص ولهالهدف بالذات. راجعوا شروط أهلية القناة (channel eligibility) ودور الرسالة حسب سياسات فريقكم المعتادة. موافقة المستخدم على قناة معينة ما بتعني أوتوماتيكياً إنه مؤهل يستلم على باقي الـ channels.

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

سجّلوا هالأجوبة حد الـ journey مباشرةً. هيك بيكون عند مراجع المحتوى سبب منطقي لوجود الإيميل، بدل ما يكون مجرد تطبيق لقاعدة عامة بتبعت على كل القنوات المتاحة.

ابنوا إيميل يوسّع المعلومات المفيدة

بلّشوا تجهيز المحتوى (creative) على Migma بالاعتماد على المهمة المعتمدة، الحالة الحالية، رابط الوجهة (destination)، ومسار الدعم. راجعوا سياق البراند (brand context) ليكون الإيميل متناسق تماماً مع نفس تجربة منتجكم متل الإشعار.

بمثال افتراضي عن خطوة setup ما كملت، إشعار الـ push ممكن يدعو المستخدم يرجع للمنتج، بينما الإيميل بيقدر يشرح شو باقي، ليه هالخطوة مهمة، ومن وين يكمّل. أكيد ما لازم يدّعي إن المستخدم تجاهل الإشعار أو يلومه لأنه ما شافه.

ممكن يكون الـ brief المختصر للإيميل متل هيك:

ساعِد المستخدم يكمّل خطوة الـ setup المتبقية. اشرح الخطوة التالية المعتمدة، وجّهه للرابط الصح، وقدّم خيارات الدعم. ما تفترض فشل التسليم ولا تزيد مهلة زمنية (deadline) إلا إذا كانت موثّقة ومحددة مسبقاً.

خلّوا الـ CTA أو الإجراء الأساسي متناسق عبر القنوات. إذا كان الـ push بيفتح صفحة إعدادات معينة بينما الإيميل عم يروّج لـ upgrade ما إله علاقة، بتكون الـ journey غيّرت هدفها فجأة بدون ما تخبر المستخدم.

حافظوا على دقة المحتوى مع تغيّر الحالة (State)

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

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

جهّزوا محتوى (copy) مخصص لكل مسار أو تفرع مدعوم بدل ما تفترضوا إنو جملة وحدة بتغطي كل الحالات. إذا المهمة خلصت، فالتصرف الصحيح غالباً هو عدم إرسال أي رسالة. وإذا الرابط أو الصفحة المطلوبة بطلت متاحة، الـ workflow بحاجة لمعالجة استثنائية (exception) تشغيلية بدل إيميل fallback فيه زر ما بيشتغل.

هيدا قرار تصميمي لازم يتوثق، ومش ادعاء إنو الإيميل بيقدر يحدّث محتواه لحاله بعد ما يوصل على الـ inbox.

افحصوا الإيميل والـ routing بشكل منفصل

استخدموا Migma Email Preflight لتدقيق النصوص، الروابط، تصميم الـ inbox، وتجنب مشاكل الإرسال الشائعة. راجعوا كيف بتظهر الإجراءات داخل الإيميل على شاشات الديسكتوب والموبايل عبر خطوات الفحص المعتادة عندكم.

استخدموا خاصية تصدير الـ HTML (HTML export) للنظام الهدف لما يلزم. بيحتاج المطور أو مسؤول الـ lifecycle لتكييف الرسالة مع إعدادات التخصيص (personalization) والـ routing بهديك المنصة. صورة المعاينة بصيغة PNG مش template جاهز للإرسال.

بعدها، افحصوا الحالات الأساسية للـ journey باستخدام حسابات تجريبية (test accounts): عدم توفر الـ push، إشارة الفشل المناسبة، إتمام المهمة قبل الـ fallback، بقاء المهمة غير منجزة، ونقص البيانات الاختيارية. ركزوا بس على الحالات اللي الـ implementation الفعلي عندكم بيدعمها.

دققوا بالتسلسل الكامل للرسائل، مش بس بمعاينة الإيميل. سجّلوا سبب إرسال الـ fallback أو إيقافه، نسخة الرسالة النهائية، والرابط اللي استُخدم. مجرد قبول المنصة للـ push أو الإيميل ما بيعني أبداً إن المستخدم كمّل المهمة.

حددوا مسؤولاً واحداً لـ الـ fallback

حددوا الشخص المسؤول عن قواعد الأهلية (eligibility rules) والشخص المسؤول عن الـ creative. لازم يوافقوا التنين على نفس نسخة الرسالة ونفس تعريف المهمة. أي تغيير بحالة المنتج ممكن يفرض تحديث بالـ routing حتى لو تصميم الإيميل ما اتغيّر.

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

بتساعدكم Migma بتصميم إيميل واضح وقابل للمراجعة والتدقيق. أما منصة الـ multichannel والمسؤول عنها فهني اللي بيقرروا إذا كان وجود الرسالة بهاللحظة مبرر ومطلوب. الـ fallback الناجح هو خطوة تالية منطقية ومتماسكة، مبنية على الحالة الفعلية للمستخدم وبتوفر قيمة حقيقية، مش مجرد تكرار لإشعار سابق.

الأسئلة الشائعة