ابدأ في Migma بتحديد المطلوب بالضبط من المستخدم في كل onboarding email. بعدها، حدد للشخص المسؤول عن الـ workflow قاعدة واضحة تماماً: متى ما بيعود هيدا الطلب إلو معنى؟ التذكير بإكمال الإعداد (setup) ممكن يكون مصمم بأحلى طريقة، بس بضل غلط يوصل لشخص خلص الإعداد مبارح.
هيدا الدليل من Migma بيركّز على شروط الخروج (exit rules) للفرق اللي بتستخدم Loops. ما رح نعطيك جدول إيميلات مكرر مبني على أيام محددة، بل ورقة مراجعة عملية وسيناريوهات فحص حقيقية. تم التأكد من التوثيق الرسمي في 15 تشرين الأول (أكتوبر) 2026. Migma بتهتم بمراجعة الـ creative والتصميم المذكورين هون؛ بينما فريق المنتج والإرسال لازم يطبّقوا حالة جهة الاتصال (contact state) وسلوك الـ workflow ويتأكدوا منهن.
عرّف إكمال الخطوة بطريقة يقدر المنتج يتحقق منها
اكتب جملة وحدة بتحدد الفعل المطلوب ورا التذكير. مثلاً، بتطبيق لإدارة المشاريع، ممكن تكون المحطة الفعلية (milestone) هي نشر أول مشروع بيحتوي على مهمة واحدة على الأقل. تسجيل الدخول أو فتح الـ welcome email ما بيعنوا أبداً إنه المستخدم حقق هيدي النتيجة.
بعدين، حدد مصدر هيدي المعلومة. الـ product event، والـ contact property المخزنة، وفتح الإيميل، كلها إشارات مختلفة تماماً. لازم الـ product owner يوضح كيف منصة الإرسال عم تستلم الـ state المناسبة، وكيف الفريق بيتأكد إنها وصلت. أي مسودة بتقول "كمّل مشروعك" ما لازم تعتمد على تخمين إذا المستخدم عنده مشروع أصلاً أو لأ.
دليل Loops لـ أمثلة الـ onboarding بيشرح فكرة عكس حالة الإكمال بـ contact property والتحقق منها قبل إرسال باقي إيميلات الإعداد. اعتمد الـ milestone الخاصة بمنتجك، بدل ما تنسخ الـ property من المثال من دون ما تتفقوا شو معناها بالضبط.
جهّز creative brief فيه خانة لشروط الخروج
على Migma، حضّر النصوص المعتمدة (copy)، وهوية البراند، والفعل المطلوب (action) لكل رسالة. وضيف ورقة عمل مساعدة صغيرة للمسؤول عن الـ workflow. خلّي الورقة حد نسخة التصميم حتى يربط اللي عم يراجع بين كل جملة والشرط اللي بخليها مناسبة.
| الهدف من الرسالة | حالة المستخدم المناسبة لها | وقّف أو غيّر الرسالة لما: |
|---|---|---|
| المساعدة بإنشاء أول مشروع | المستخدم بعد ما كمّل الـ milestone المتفق عليها | يتسجل إكمال الخطوة |
| شرح ربط (integration) غير مكتمل | الربط بعده ناقص والمستخدم عنده صلاحية يديره | يشتغل الربط أو إذا المستخدم ما عنده هيدا الـ role |
| تقديم مساعدة بالإعداد | المستخدم مؤهل وبعده عالق بالخطوة | يخلص الـ setup، أو تتغير الصلاحيات، أو تخلص الـ sequence |
| اقتراح خطوة تالية مفيدة | أول milestone مكتملة | تكون الخطوة التالية انعملت أصلاً أو ما عادت مناسبة |
هيدي قواعد مقترحة للتطبيق التجريبي، مش نتائج مقاسة ولا إعدادات جاهزة للـ Loops. راجعها مع الفريق المسؤول عن داتا المنتج قبل ما تفعّل أي workflow.
انتبه لنطاق تطبيق الـ audience filter
بتوثيق Loops الحالي لـ تفريعات الـ workflows (branching)، في تمييز بين "All following nodes" و"Next node only". مع الخيار الأول، أي جهة اتصال بتبطل تطابق الشرط لاحقاً بتطلع من الـ workflow تلقائياً. أما مع الخيار التاني، فالشرط بيتطبق بس لما يوصل الـ contact للـ node التالية، والتغييرات اللي بتصير بعدين ما بتطلّعه على هيدا الأساس.
هيدا النطاق (scope) كتير أساسي لما يخلّص المستخدم الإعداد خلال فترة انتظار (wait node). إذا فحصت الـ filter مرة وحدة بالأول، هيدا مش دليل إنه كل التذكيرات اللي بعدين بعدها مناسبة. اطلب من مسؤول الـ workflow يوضح وين بيتطبق شرط الإكمال، وشو بيصير بالـ contact اللي ناطر بالخطوات التالية.
كمان افحص نسخة الـ branch الفعلية. توثيق Loops بيوضح الانتقال من التقييم المتوازي القديم (parallel matching) لمنطق التطابق الأول (first-match) بالتفريعات الجديدة، مع بقاء الـ branches القديمة على منطقها السابق لحد ما تترقى يدوياً. ما تفترض كيف بيتصرف workflow محفوظ بمجرد إنك شفت screenshot من أحدث صفحة توثيق.
افصل بين رتبة المستخدم وإكمال الخطوة
ممكن زميل معزوم على الفريق يكون متفاعل ونشيط، بس ما عنده صلاحية يربط مصدر بيانات الشركة (data source). وممكن صاحب الـ workspace يكون ربطها، بوقت زميل تاني ناطر يوصله تذكير. لازم الـ brief يحدد بوضوح إذا الإنجاز مرتبط بالشخص، بالحساب، أو بالـ workspace كلها.
اعتمد هيدا التمييز بصياغة الـ copy. طلب متل "اربط مصدر بيانات فريقك" ممكن يكون منطقي للأدمن، بس مربك جداً لزميل معزوم بصفة contributor. وإذا الفريق ما عنده داتا دقيقة عن الأدوار، اكتب مسار محايد واطلب من المسؤول عن التطبيق يتعامل مع الحالة غير المعروفة (unknown state) بوعي وتخطيط.
توثيق الـ branching بـ Loops بيذكر إن الـ branches الحالية بتقيّم الـ filters من الشمال لليمين وبتمشي مع أول تطابق. وجود filter بأقصى اليمين من دون شروط بيقدر يشكّل مسار افتراضي (default path). تعامل مع تصميم هيدا المسار كقرار محتوى حقيقي: الداتا غير المعروفة ما لازم تتحول تلقائياً لاتهام غير مبرر للمستخدم إنه مقصّر بالإعداد.
اختبر حالة المستخدم اللي بتتغير خلال فترة الانتظار
اعمل جدول اختبارات قبول (acceptance sheet) صغير ببيانات وهمية. وخلّي الشخص المسؤول عن الـ testing يجربه ببيئة مناسبة. ما تغيّر الـ contact properties لزبون حقيقي بس كرمال تاخد screenshot.
جهّز سجل يضل مش مكمّل، وسجل يكمّل الـ milestone قبل أول تذكير، وسجل تالت يخلّص وهو ناطر بين التذكيرات. وسجل رابع تكون بياناته ناقصة (missing state)، وخامس بيمثل زميل بالفريق ما عنده صلاحية ينفّذ الإجراء المطلوب.
لكل سيناريو، سجّل الرسالة المتوقعة أو شرط الخروج، النتيجة الفعلية بالـ workflow، ونسخة الـ creative المستخدمة. إذا التذكير بعده عم يوصل حتى بعد الإنجاز، راجع تحديث الـ state ونطاق الـ filter قبل ما تفكر تغيّر العنوان. تحسين الصياغة ما رح يصلح غلطة باستهداف الجمهور.
طابق الإيميل النهائي مع التصميم المعتمد
راجع الرسالة على Migma لتتأكد من وضوح الإجراء المطلوب وشرح الخطوة الناقصة بطريقة مفيدة. استعمل Email Preflight لفحص الـ creative. خلّي الإيميل قصير ومركّز، بحيث يسهل تلاقي الطلب وطريقة التواصل مع الدعم.
إذا كنتوا بتعتمدوا تسليم HTML، استعمل خيارات التصدير بـ Migma وخلّي المطور يطابق الـ template النهائي على Loops. هيدا مش معناه وجود ربط تلقائي مباشر (native connector) بين Migma وLoops. تأكد من رابط الزر النهائي (CTA) حسب الـ role وحالة المستخدم التجريبية؛ الرابط ممكن يشتغل تقنياً بس يوجّه المستخدم لصفحة ما عنده صلاحية يفوت عليها.
افصل بين مراجعة الـ creative واعتماد الـ workflow. مسودة Migma بتوضح شو وافق عليه الفريق، بينما رسالة الفحص اللي بتوصلك ونتيجة الـ workflow المسجلة هنّي اللي بيكشفوا السلوك الفعلي للـ journey المضبوطة.
أنهِ التذكير وافتح الحوار المفيد التالي
إكمال الخطوة لازم يوقّف طلب الإعداد اللي بطل إلو داعي، بس مش بالضرورة يبعت إيميل جديد فوراً. قرروا إذا المستخدم بحاجة لرسالة تأكيد، أو دليل للخطوة التالية بوقت لاحق، أو ببساطة وقت ليستكشف المنتج براحته.
بالنسبة للتطبيق التجريبي، إنشاء المشروع ممكن يتبعه لاحقاً نصيحة عن التعاون مع الفريق، بينما المستخدم اللي بعده ما خلص بيوصله عرض مساعدة مختصر. الرسالتين بيلبّوا احتياجات مختلفة تماماً، ولازم يكون لكل وحدة brief مستقل. ما ترجع تسمّي نفس الـ nudge باسم جديد وتضل تبعته.
ابنِ الـ creative على Migma مع إبراز الـ exit rule أثناء المراجعة. بعدين، اطلب من مسؤول الـ workflow يثبت إنه التذكير بيوقف للسبب الصح. الـ onboarding sequence الموثوقة بتحترم تقدم المستخدم تماماً متل ما بتطلب منه يتقدّم.
أسئلة شائعة
هل فتح الإيميل بيعتبر قاعدة كافية لإكمال الـ onboarding؟
فتح الإيميل مش دليل على إنجاز الخطوة بالمنتج. اتفقوا على إجراء محدد داخل المنتج (product action)، وتأكدوا كيف حالته عم توصل لمنصة الإرسال.
شو بيصير إذا المستخدم فعّل الحساب أو كمّل الخطوة خلال فترة الانتظار؟
الهدف هو توقيف تذكيرات الإعداد اللي بطلت لازمة. لازم مسؤول الـ workflow يتحقق من الـ contact state الحالية ونطاق الـ audience filter لجهة اتصال ناطرة بالمسار أصلاً.
هل كل تفريعات Loops المحفوظة بتعتمد نفس أسلوب المطابقة؟
لأ. التوثيق الحالي بيميز بين الـ branches الجديدة اللي بتعتمد أول تطابق (first-match) والقديمة اللي بتحافظ على السلوك المتوازي (parallel) لحد ما تترقى يدوياً. افحص الـ workflow المحفوظ قبل ما تبني قراراتك على منطقه.
هل هيدا الـ workflow بيتطلب ربط مباشر بين Migma وLoops؟
لأ. جهّز الـ creative وراجعه على Migma، وبعدين اعتمد صيغة التصدير أو المرجع المناسب بمنصة الإرسال. مسؤول التنفيذ بيتأكد من الـ template النهائي وسلوك الـ workflow.