عندما لا تصل رسالة WhatsApp: كيف تستخدم SMS كقناة احتياطية تلقائيًا؟
أرسل متجرك للعميل رسالة WhatsApp تخبره أن طلبه أصبح جاهزًا للاستلام.
نجح طلب الـAPI.
إذن الرسالة وصلت، أليس كذلك؟
ليس بالضرورة.
في أنظمة المراسلة الحديثة، نجاح طلب الإرسال لا يعني دائمًا أن الرسالة وصلت فعليًا إلى جهاز العميل. ولهذا، عندما تكون الرسالة مرتبطة بموعد أو طلب أو عملية حساسة للوقت، يصبح الاعتماد على قناة واحدة مخاطرة تشغيلية.
هنا يظهر مفهوم WhatsApp + SMS Fallback:
إذا تعذر تسليم الرسالة عبر WhatsApp وفق قواعد محددة، ينتقل النظام إلى SMS كقناة احتياطية.
ما هو WhatsApp SMS Fallback؟
Fallback يعني وجود قناة بديلة يستخدمها النظام عندما لا تحقق القناة الأساسية النتيجة المطلوبة.
يمكن أن تكون الرحلة مثلًا:
حدث داخل النظام → WhatsApp → فحص حالة التسليم → فشل → SMS
مثال:
يتم تغيير موعد مريض في نظام العيادة.
يرسل النظام إشعار WhatsApp.
إذا تم تسليمه، تنتهي الرحلة.
إذا فشل التسليم وفق القواعد التي حددتها المؤسسة، يمكن تشغيل SMS يحتوي على المعلومة الأساسية.
الفكرة ليست إرسال الرسالة على القناتين دائمًا.
بل استخدام القناة الثانية فقط عندما توجد حاجة حقيقية إليها.
Sent لا تعني Delivered
هذه من أهم النقاط عند بناء النظام.
WhatsApp Business Platform يوفر تحديثات حالة للرسائل عبر Webhooks تشمل حالات مثل:
sent
delivered
read
failed
وتوضح وثائق منصة Meta أن تحديثات الحالة قد تصل بصورة غير متزامنة، ولذلك يجب استخدام بيانات الحالة والتوقيت عند تتبع الرسالة.
عمليًا:
sent تعني أن الرسالة دخلت مرحلة الإرسال.
delivered هي الإشارة المهمة عندما تريد معرفة أن الرسالة وصلت إلى جهاز المستلم.
read يعني أن العميل فتحها، عندما يكون هذا المؤشر متاحًا.
failed يعني أن الرسالة لم تتمكن من الوصول عبر المسار المطلوب.
لذلك يجب ألا يُبنى الـFallback فقط على أن API أعاد استجابة ناجحة.
كيف يعمل الـFallback تقنيًا؟
يمكن تصميم النظام بهذا الشكل:
1. يحدث Event داخل CRM أو ERP أو التطبيق
مثل:
تم تأكيد الطلب.
تم تعديل الموعد.
الشحنة جاهزة.
2. يرسل النظام WhatsApp
يتم الاحتفاظ بمعرف الرسالة وربطه بالحدث داخل النظام.
3. تصل Delivery Webhooks
يستقبل النظام تحديث حالة الرسالة.
توفر OurSMS WhatsApp Business API مع Webhooks وتقارير لمتابعة حالات الرسائل، كما توفر منصة المطورين REST API وWebhooks للتكامل مع التطبيقات والأنظمة.
4. يطبّق النظام قاعدة القرار
إذا أصبحت الحالة delivered → لا تفعل شيئًا.
إذا أصبحت failed وكان الحدث مؤهلًا للـFallback → أرسل SMS.
5. يسجل النتيجة
يجب أن يعرف CRM أو النظام الرئيسي أن العميل تم الوصول إليه عبر SMS بدل WhatsApp.
Failure أم Timeout؟
هذه نقطة تحتاج إلى تصميم دقيق.
أسهل سيناريو هو:
WhatsApp = failed → SMS
لكن ماذا لو ظلت الرسالة في حالة sent ولم يظهر delivered بسرعة؟
يمكن للشركة إضافة Timeout للرسائل الحساسة للوقت.
مثلًا، إذا كان التنبيه يجب أن يصل خلال دقائق، يمكن للنظام تحديد مدة انتظار مناسبة ثم تشغيل قناة احتياطية إذا لم يحصل على تأكيد التسليم.
لكن الـTimeout يحتاج إلى حذر.
قد تتأخر حالة WhatsApp ثم تصل الرسالة لاحقًا، ما قد يؤدي إلى وصول WhatsApp وSMS معًا.
لذلك يجب تحديد الـTimeout وفق أهمية الرسالة، وليس استخدام مدة واحدة لكل شيء.
أين يكون Fallback مفيدًا؟
ليس كل إشعار يحتاج إلى قناة احتياطية.
تأكيدات المواعيد
إذا تغير موعد قريب، قد يكون وصول الإشعار أهم من القناة نفسها.
تحديثات الشحن
مثل تغيير وقت التسليم أو جاهزية الطلب للاستلام.
تنبيهات تشغيلية
مثل تغييرات الخدمة أو معلومات تحتاج إلى اطلاع العميل عليها سريعًا.
OTP والتحقق
التحقق متعدد القنوات من أشهر حالات استخدام Fallback عالميًا؛ فبعض منصات التحقق تستخدم WhatsApp ثم SMS عند تعذر القناة الأولى.
ومع ذلك، يجب تصميم OTP بحذر أكبر بسبب مخاطر الاحتيال وإعادة الإرسال وتزامن الرموز.
كيف تمنع وصول الرسالة مرتين؟
هذه من أهم مشكلات التصميم.
تخيل:
WhatsApp لم يظهر delivered بعد 20 ثانية.
أرسل النظام SMS.
بعد 5 ثوانٍ إضافية، وصلت رسالة WhatsApp أيضًا.
أصبح العميل يمتلك رسالتين متطابقتين.
لذلك يحتاج النظام إلى Message State واضح.
مثلًا:
whatsapp_pending
ثم:
whatsapp_delivered
أو:
fallback_triggered
ثم:
sms_delivered
ويجب أن يكون إجراء تشغيل SMS Idempotent، أي لا يستطيع نفس الحدث تشغيل أكثر من SMS احتياطي بسبب وصول Webhook مرتين أو إعادة محاولة النظام.
كما يجب الانتباه إلى أن تحديثات حالة WhatsApp قد لا تصل بالترتيب المتوقع دائمًا؛ وثائق Meta تنصح باستخدام timestamps لفهم الترتيب الفعلي.
ماذا نرسل في SMS الاحتياطية؟
ليس من الضروري نسخ رسالة WhatsApp حرفيًا.
WhatsApp قد يحتوي على صورة أو أزرار أو معلومات طويلة.
SMS يجب أن يحتوي على الجزء الذي لا يمكن للعميل الاستغناء عنه.
إذا كانت رسالة WhatsApp تقول:
“تم تجهيز طلبك ويمكنك الضغط على الزر لمشاهدة تفاصيل الفرع وخريطة الوصول.”
قد تكون رسالة SMS الاحتياطية:
“طلبك رقم 4815 جاهز للاستلام. راجع حسابك لمعرفة تفاصيل الفرع.”
الهدف هو الحفاظ على النتيجة، وليس الحفاظ على شكل القناة الأولى.
لا تستخدم Fallback لكل الرسائل
إذا أرسلت عرضًا تسويقيًا عبر WhatsApp وفشل، لا يعني ذلك تلقائيًا أنك يجب أن ترسل العرض نفسه عبر SMS.
Fallback أكثر قيمة عندما تكون الرسالة:
مهمة،
مرتبطة بحدث،
حساسة للوقت،
ويتوقع العميل استلامها.
أما الحملات التسويقية، فتحتاج استراتيجية مختلفة تعتمد على الموافقة وتفضيلات العميل وتكرار الرسائل.
أخطاء شائعة
أول خطأ هو إرسال WhatsApp وSMS في نفس اللحظة وتسميته Fallback.
هذا ليس Fallback؛ هذا إرسال مزدوج.
الثاني هو تشغيل SMS عند عدم وجود read.
العميل قد يكون استلم الرسالة لكنه لم يفتحها بعد. عدم القراءة لا يعني فشل التسليم.
الثالث هو استخدام Timeout قصير جدًا.
والرابع هو عدم مزامنة حالة الرسالة مع CRM.
والخامس هو عدم وجود حماية من تكرار إرسال SMS لنفس الحدث.
كيف تقيس نجاح النظام؟
راقب:
نسبة الرسائل التي تصل عبر WhatsApp وحده.
نسبة الرسائل التي تحتاج SMS Fallback.
أسباب فشل WhatsApp.
زمن الانتقال إلى القناة الاحتياطية.
نسبة نجاح SMS بعد الـFallback.
نسبة الرسائل المكررة.
والأهم:
هل وصل الحدث المهم للعميل في الوقت المطلوب؟
نجاح النظام ليس أن يستخدم WhatsApp أكثر.
ولا أن يستخدم SMS أكثر.
نجاحه أن يختار المسار المناسب لتحقيق النتيجة.
كيف يمكن بناء ذلك باستخدام OurSMS؟
توفر OurSMS WhatsApp Business API للرسائل التفاعلية والإشعارات مع REST API وWebhooks وتقارير حالة الرسائل. كما توفر SMS Gateway API لإرسال SMS من المواقع والتطبيقات وأنظمة ERP وCRM.
وتوضح منصة المطورين في OurSMS دعم SMS API وWhatsApp API وOTP API وWebhooks لاستقبال تحديثات حالة الرسائل والأحداث.
هذا يعني أن الشركة تستطيع تصميم منطق الـFallback داخل تطبيقها أو طبقة التكامل لديها اعتمادًا على حالة الرسالة وقواعد العمل المناسبة.
ومن المهم التفريق هنا: القدرة على استخدام القناتين وWebhooks لا تعني أن Automatic WhatsApp-to-SMS Fallback ميزة مدمجة تلقائيًا في كل حساب OurSMS. طريقة التنفيذ تعتمد على إعداد التكامل والمنطق الذي يتم بناؤه للمشروع.
الخلاصة
الـOmnichannel الحقيقي لا يعني إرسال نفس الرسالة عبر كل القنوات.
بل يعني أن الأنظمة تعرف:
أي قناة تبدأ بها،
هل نجحت،
متى تنتقل إلى قناة أخرى،
ومتى تتوقف.
وهنا تتحول WhatsApp وSMS من خدمتين منفصلتين إلى نظام توجيه رسائل يعتمد على حالة التسليم وأهمية الحدث.
السؤال الأفضل لم يعد:
“WhatsApp أم SMS؟”
بل:
“إذا لم تنجح القناة الأولى، هل يعرف نظامنا تلقائيًا ما الذي يجب أن يفعله بعد ذلك؟”
إذا كان تطبيقك أو نظام ERP أو CRM يعتمد على رسائل مهمة للعملاء، يمكنك استكشاف WhatsApp Business API وSMS API وWebhooks لدى OurSMS لبناء Workflow متعدد القنوات يناسب متطلباتك.
تواصل مع فريق OurSMS لمناقشة بنية التكامل، حالات التسليم، ومسار الـFallback المناسب لنوع الرسائل التي ترسلها.
الاسئلة الشائعة
ما هو WhatsApp SMS Fallback؟
هو منطق يجعل النظام يحاول إرسال الرسالة عبر WhatsApp أولًا ثم يستخدم SMS كقناة احتياطية إذا تحقق شرط فشل أو Timeout محدد.
هل نجاح WhatsApp API يعني أن الرسالة وصلت؟
ليس بالضرورة. يجب متابعة تحديثات حالة الرسالة، وخصوصًا delivered، عبر Webhooks.
ما الفرق بين sent وdelivered؟
sent تشير إلى أن الرسالة تم قبولها ضمن مسار الإرسال، بينما delivered تؤكد وصولها إلى جهاز المستلم وفق حالة WhatsApp.
هل يجب إرسال SMS إذا لم يقرأ العميل WhatsApp؟
ليس عادة. عدم القراءة لا يساوي فشل التسليم. الأفضل بناء Fallback على حالة التسليم ومتطلبات الحدث.
ما هو Timeout في Messaging Fallback؟
مدة انتظار يحددها النظام قبل الانتقال إلى قناة احتياطية إذا لم يصل تأكيد التسليم المطلوب.
ما أهم حالات استخدام SMS Fallback؟
المواعيد، تحديثات الطلبات والشحن، الإشعارات الحساسة للوقت وبعض سيناريوهات OTP.
كيف أمنع وصول WhatsApp وSMS معًا؟
باستخدام حالات للرسائل، Idempotency، وتتبع Webhooks قبل تشغيل القناة الاحتياطية.
هل توفر OurSMS Webhooks؟
نعم، توضح منصة المطورين لدى OurSMS دعم Webhooks لتحديثات حالة الرسائل والأحداث.
هل Fallback تلقائي جاهز داخل OurSMS؟
تدعم OurSMS القنوات وAPIs وWebhooks اللازمة لبناء التدفق، لكن يجب تحديد طريقة تنفيذ Automatic Fallback حسب إعداد المشروع والتكامل المستخدم.