1) ابدأ بتعريف “لم يصل” بدقة

قبل أي تحليل، احسم السؤال: “لم يصل” أين بالضبط؟ هل المستخدم لم يستلم الرسالة نهائيًا؟ أم وصلت إلى السبام؟ أم وصلت متأخرة؟ أم وصلت لكن إلى بريد مختلف؟ أم تم حجبها داخل مؤسسة؟ فريق المنتج يحتاج صياغة موحدة للحالات لأن كل حالة لها مسار تشخيص مختلف.

• عدم وصول كامل: لا يوجد أثر للرسالة في أي مكان.
• وصلت إلى Spam/Junk: الرسالة موجودة لكن ليست في Inbox.
• تأخير طويل: وصلت بعد دقائق/ساعات، مما يكسر OTP وتجارب التفعيل.
• وصلت لكن لم تظهر: المستخدم يستخدم تطبيقًا/فلاتر/قواعد تخفي الرسالة.
• وصلت إلى عنوان خاطئ: خطأ إدخال أو تطبيع (trim) أو Unicode.

اجعل فريق الدعم يسأل سؤالين ثابتين: البريد المستلم بالكامل (بدون إخفاء النطاق داخليًا) + وقت محاولة الإرسال + نوع الرسالة (OTP/Reset/Invoice). بهذه الثلاثية، ستقصّر وقت التشخيص إلى النصف.

2) ابنِ “سلسلة إثبات” داخل المنتج (Evidence Chain)

من منظور المنتج، المشكلة ليست فقط “هل أرسلنا؟” بل “هل نستطيع إثبات ذلك خطوة بخطوة؟”. إذا كانت لديك سجلات متفرقة أو ناقصة، ستبقى تدور في حلقة إعادة المحاولة. ما تحتاجه هو معرف واحد ثابت لكل رسالة: Message ID داخلي يرتبط بكل الأحداث.

ما الذي يجب أن يسجله النظام لكل رسالة؟

• المدخلات: البريد، نوع الرسالة، اللغة/القالب، البلد/المنطقة إن وجدت.
• التحقق قبل الإرسال: هل البريد صالح؟ هل تم تطبيع الحروف؟ هل هناك منع نطاقات؟
• مرحلة الإنشاء: أي قالب؟ أي متغيرات؟ أي عنوان مرسل (From)؟
• مرحلة الطابور: هل دخلت الرسالة Queue؟ كم زمن الانتظار؟
• مرحلة التسليم للمزوّد: هل استلم المزود الطلب؟ وما هو provider_message_id؟
• مرحلة الأحداث: accepted / delivered / bounced / dropped / deferred / complaint.
• الإجراءات: هل أعيد الإرسال؟ هل تم تغيير المزود؟ هل تم التراجع؟

إذا لم تكن هذه السلسلة موجودة، فأنتم لا “تدبّغون” المشكلة، أنتم تحاولون تخمينها. استثمروا في لوحة داخلية بسيطة أو صفحة “Trace” تُظهر هذه الأحداث لفريق الدعم والمنتج.

3) تحقق أولًا من الطبقة الأقرب: هل المنتج فعلاً طلب الإرسال؟

كثير من حالات “Sent but Not Received” تبدأ قبل مزود الإرسال أصلًا. مثال واقعي: واجهة المستخدم تعرض نجاحًا لأن API رجّع 200، لكن السيرفر لم ينشئ الرسالة بسبب شرط داخلي أو خطأ في قالب معين. أو أن API يعمل بصورة غير متزامنة (async) ويعيد “تمت جدولة الإرسال” وليس “تم الإرسال”.

أعراض مشاكل طبقة المنتج

• تحدث فقط مع نوع رسالة معين (OTP فقط أو Reset فقط).
• تحدث فقط مع لغة معينة (العربية/الإنجليزية) بسبب قالب أو ترميز.
• تحدث فقط على بيئة معينة (Production دون Staging) بسبب مفاتيح أو إعدادات.
• تحدث عند ضغط عالي لأن الطابور لا يستهلك الرسائل بالسرعة المطلوبة.

خطوة المنتج هنا: قارن بين عدد محاولات الإرسال وعدد الرسائل التي وصلت مرحلة “قبول المزود”. إذا هناك فجوة، فالخلل داخلي قبل المزود.

4) مزوّد الإرسال: “Accepted” لا تعني “Delivered”

كثير من الأنظمة تعرض “Sent” عندما يستلم مزود الإرسال الطلب ويعطيك ID. هذا يعني أن المزود قبل الرسالة، لكنه لا يضمن أنها وصلت لصندوق المستخدم. لذلك اعتمدوا مصطلحات داخل المنتج: Submitted (تم تسليمها للمزوّد) و Delivered (تم قبولها لدى المستقبل) و Seen (إن كان لديكم تتبع، بحذر).

ما الذي تبحث عنه داخل لوحة المزوّد؟

• Accepted: المزود استلم الرسالة وبدأ يحاول التسليم.
• Deferred: تم تأجيل التسليم (غالبًا بسبب rate limit أو سياسة استقبال).
• Bounced: رفض نهائي (عنوان غير موجود، سياسة، أو حظر).
• Dropped: المزود أسقط الرسالة (قائمة حظر، spam policy، أو إعدادات).
• Complaint: المستخدم أبلغ كرسالة مزعجة سابقًا.

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

5) إعدادات الدومين: SPF / DKIM / DMARC ليست “تفاصيل تقنية”

في 2026 وما بعدها، قابلية التسليم (Deliverability) ليست رفاهية. إذا كانت إعدادات SPF/DKIM/DMARC غير سليمة أو غير مكتملة، فسترى أعراضًا مثل: وصول الرسائل إلى السبام، تأخير، أو رفض صريح، خصوصًا لدى مزودات كبيرة. هذه ليست مسؤولية فريق البنية فقط؛ فريق المنتج يجب أن يفهم أثرها لأنها تؤثر مباشرة على التفعيل والتحويل.

متى تشك في إعدادات الدومين؟

• الرسائل لا تصل عند بعض المزودات وتصل عند أخرى.
• الرسائل تصل إلى Spam بشكل متكرر.
• تظهر بوضوح “via” أو تحذيرات ثقة في بعض العملاء.
• ارتفعت مشاكل الوصول بعد تغيير From domain أو إضافة نطاق فرعي.

قاعدة عملية: اجعلوا كل رسائل المعاملات (OTP/Reset/Invoice) على نطاق مرسل ثابت وموثوق، ويفضل فصلها عن نطاقات التسويق. هذا يقلل من تلوث السمعة عندما حملات التسويق ترتفع شكاواها.

6) لماذا تصل OTP ببطء؟ فهم التأخير بطريقة منتج

OTP حساس للوقت. رسالة تصل بعد 6 دقائق = تجربة فاشلة حتى لو “وصلت”. التأخير يأتي غالبًا من أحد هذه الأماكن: طابور داخلي متكدس، مزود الإرسال يؤجل بسبب معدلات الإرسال، أو مزود الاستقبال يفرض سياسات تقييد/تحقق إضافي.

ما الذي يجب أن تقيسه؟

• وقت إنشاء الرسالة داخل النظام.
• وقت تسليمها للمزوّد (Submitted timestamp).
• وقت delivered/deferred من أحداث المزود.
• زمن النهاية للمستخدم (عبر تقارير الدعم أو telemetry إن أمكن).

حددوا SLA للـ OTP مثل: 90% تصل خلال 30 ثانية، و99% خلال 60 ثانية. ثم اربطوا التنبيهات بهذا القياس، وليس بعدد الشكاوى فقط.

7) السبام ليس دائمًا “محتوى سيء”… أحيانًا سمعة وسلوك

رسائل المعاملات عادةً قصيرة وواضحة، ومع ذلك قد تهبط للسبام. السبب قد يكون سمعة IP/Domain، معدل الإرسال المفاجئ، أو نمط الروابط داخل الرسالة. في الإمارات، بعض المستخدمين يعتمدون على Gmail/Outlook وآخرون على بريد مؤسسي. البريد المؤسسي قد يطبق سياسات صارمة أو بوابات أمنية (Secure Email Gateway).

ماذا تفعل كفريق منتج عندما ترى سبام متكرر؟

• تأكد أن العنوان والاسم واضحان وموحدان (From Name ثابت ومعقول).
• قلل الروابط في OTP إلى الحد الأدنى.
• تجنب كلمات تسويق في رسائل المعاملات (خصم، عرض، مجاني) داخل OTP/Reset.
• حافظ على تناسق النطاق بين الروابط والدومين المرسل قدر الإمكان.
• افصل رسائل التسويق عن رسائل المعاملات على مستوى الدومين أو subdomain.

8) أخطاء شائعة داخل المنتج تخلق “لم يصل” بدون أن تلاحظ

أ) تطبيع البريد الإلكتروني (Normalization)

أحيانًا البريد المدخل يحتوي مسافات، أو أحرف غير مرئية، أو اختلافات Unicode. إذا خزّنت البريد كما هو، قد ترسل إلى عنوان غير صحيح. الحل: تطبيع واضح قبل الحفظ والإرسال (trim، تحويل أحرف، إزالة الرموز غير المرئية) مع الاحتفاظ بقيمة العرض للمستخدم بشكل آمن.

ب) تكرار الرسائل ومنع الإرسال (Rate Limiting)

إذا كان النظام يمنع تكرار OTP خلال فترة قصيرة، قد يرى المستخدم “تم الإرسال” بينما النظام قرر عدم الإرسال فعليًا. هذه نقطة UX: يجب أن تشرح للمستخدم أنه لا يمكن إعادة الإرسال قبل مدة محددة، أو أن الرسالة أُرسلت للتو.

ج) تعدد القنوات بدون حسم

بعض المنتجات ترسل OTP عبر البريد والرسائل النصية، ثم تعيد المحاولة عبر قناة أخرى. إذا لم تكن هناك استراتيجية واضحة، قد تتداخل الرسائل ويضيع المستخدم. ضعوا سياسة: إذا فشل البريد خلال X ثانية، اقترح SMS، مع توضيح واضح.

9) خطة تشخيص سريعة من 10 خطوات (للمنتج والدعم معًا)

1. حدد نوع الرسالة (OTP/Reset/Invoice) والوقت الدقيق ومحاولة الإرسال.
2. تأكد من صحة البريد المدخل وتطبيعه (لا مسافات، لا رموز خفية).
3. اعثر على Message ID الداخلي من سجلات التطبيق.
4. تأكد أن الرسالة دخلت الطابور ولم تتعطل (Queue backlog/worker errors).
5. استخرج provider_message_id عند التسليم للمزود.
6. راجع حالة المزود: accepted/deferred/bounced/dropped.
7. إذا deferred: راقب مدة التأجيل وتكراره، وحدد إن كان بسبب معدل أو سياسة استقبال.
8. إذا bounced/dropped: اقرأ سبب الرفض، وراجع قوائم الحظر والسياسات.
9. إذا delivered لكن المستخدم لا يراها: اطلب منه فحص spam والبحث داخل البريد، وتحقق من قواعد/Filters.
10. سجّل النتيجة كسبب جذري (Root Cause) مع تصنيف واضح لتقليل التكرار.

10) كيف تبني “منتجًا” يقاوم هذه المشكلة بدل مطاردة الحالات؟

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

• واجهة حالة الإرسال للمستخدم: بدل “تم الإرسال”، اعرض “تمت محاولة الإرسال” مع زر “إعادة الإرسال بعد 30 ثانية” ومؤقت واضح.
• اقتراحات داخل الشاشة: “افحص البريد غير المرغوب فيه” + “ابحث عن اسم المرسل” + “تأكد من صحة العنوان”.
• Fallback ذكي: إذا فشل البريد أو تأخر، قدّم قناة بديلة (SMS/WhatsApp Business إن كان مناسبًا وسياساتكم تسمح).
• لوحة مراقبة للـ OTP: معدل التأخير، نسبة الـ deferred، ونسبة الوصول خلال SLA، مع تنبيهات تلقائية.
• تجزئة الإرسال: رسائل المعاملات على إعدادات إرسال مخصصة عن التسويق، لتقليل أثر السمعة.

الخلاصة

“Sent but Not Received” ليست مشكلة بريد فقط، بل مشكلة منتج وتجربة وثقة. عندما تُدار بمنهجية فريق المنتج: تعريف واضح للحالة، سلسلة إثبات داخلية، ربط معرفات، وقياسات زمنية للـ OTP، تتحول من لغز مزعج إلى عملية تشخيص سريعة يمكن للدعم تنفيذها بثقة. ومع تحسينات UX والقياس والمراقبة، ستلاحظون انخفاض الشكاوى وارتفاع معدلات التفعيل مباشرةً.