انتقل إلى المحتوى
OmniChannels.ai
القائمة

كيف تربط نظام CRM بصندوق وارد متعدد القنوات باستخدام webhooks؟

اربط نظام CRM بصندوق وارد متعدد القنوات عبر webhooks: الأحداث التي تُزامَن، وعدم التكرار (idempotency)، وإعادة المحاولة، ومطابقة جهات الاتصال، وخصوصية البيانات.

آخر تحديث 8 دقائق للقراءة

بقلم OmniChannels.ai Editorial Team · مراجعة BroadNet Messaging Solutions Team

التكامل

الإجابة المختصرة

لربط CRM بصندوق وارد متعدد القنوات، اشترك في webhooks الصندوق لأحداث المحادثات والرسائل، واستقبلها على نقطة نهاية صغيرة تتحقق من التوقيعات وتخزّن كل حدث مرة واحدة بمعرّفه، ثم عالجها بشكل غير متزامن: طابق المرسل مع جهة اتصال في CRM عبر الهاتف المطبَّع أو البريد أو معرّف المنصة الاجتماعية، واكتب الأنشطة مرة أخرى. واستخدم API الصندوق في الاتجاه المعاكس لإرسال الرسائل أو تحديث الملكية من سير عمل CRM.

في هذه الصفحة
  1. ما الذي ينبغي أن يتبادله CRM وصندوق الوارد متعدد القنوات؟
  2. ما أحداث webhook التي ينبغي الاشتراك فيها؟
  3. كيف تبني مستقبِل webhook موثوقًا؟
  4. كيف تطابق جهات الاتصال عبر القنوات؟
  5. كيف تتعامل مع خصوصية البيانات في تكامل CRM؟
  6. كيف تبدو البنية المرجعية؟
  7. مثال تطبيقي: مجموعة عيادات في جدة
  8. ما الأخطاء الشائعة؟
  9. كيف تساعدك OmniChannels.ai؟

أهم النقاط

  • تدفع webhooks الأحداث من الصندوق إلى CRM شبه فوري، بينما تسحب واجهات API البيانات أو تنفّذ الإجراءات في الاتجاه المعاكس. التكامل المتين يستخدم الاثنين.
  • يكون تسليم webhooks عادةً مرة واحدة على الأقل (at-least-once)، لذا يجب أن يزيل المستقبِل التكرار بمعرّف الحدث وأن يتحمل وصول الأحداث بترتيب مختلف.
  • أقرّ باستلام webhook بسرعة ونفّذ عمل CRM في طابور خلفي، حتى لا تؤدي استدعاءات CRM البطيئة إلى إعادة محاولات وتكرارات.
  • طابق جهات الاتصال بمعرّفات مطبَّعة مثل أرقام الهاتف بصيغة E.164 وعناوين البريد بحروف صغيرة، ولا تدمج السجلات بالاسم وحده أبدًا.
  • أرسل فقط البيانات التي يحتاجها CRM، وأبقِ محتوى الرسائل خارجه حيث يكفي ملخص، والتزم بقانون الخصوصية المنطبق مثل GDPR وقوانين حماية البيانات في الإمارات والسعودية.

هذا الدليل موجّه لمديري التقنية ومهندسي الحلول ومسؤولي أنظمة CRM الذين يحتاجون إلى أن يتشارك نظام CRM وصندوق الوارد متعدد القنوات رؤية واحدة للعميل. يشرح الأحداث التي ينبغي مزامنتها، وكيف تبني مستقبِل webhook يصمد أمام إعادة المحاولات والتكرارات، وكيف تطابق جهات الاتصال عبر واتساب وInstagram والبريد الإلكتروني، وما قواعد الخصوصية التي تشكّل التصميم.

ما الذي ينبغي أن يتبادله CRM وصندوق الوارد متعدد القنوات؟

ينبغي أن يخبر الصندوق نظام CRM من تواصل معك، وعلى أي قناة، وبشأن ماذا، وما كانت النتيجة. وينبغي أن يخبر CRM الصندوق من هو العميل، ومن يملكه، وما السياق الذي يحتاجه الوكلاء.

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

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

ما أحداث webhook التي ينبغي الاشتراك فيها؟

اشترك في أحداث دورة الحياة لا في الرسائل وحدها. تختلف أسماء الأحداث بين المنصات، لذا اربطها بهذه الفئات:

  • إنشاء محادثة — أول رسالة من عميل على أي قناة.
  • استلام رسالة — رسالة واردة من العميل، مع القناة واسم المرسل.
  • إرسال رسالة — رسالة صادرة من وكيل أو قالب.
  • حالة الرسالة — أُرسلت أو سُلّمت أو قُرئت أو فشلت، حيثما تبلّغ القناة بذلك.
  • إسناد محادثة — تغيّر المالك أو القائمة.
  • حل المحادثة أو إعادة فتحها — انتقالات الحالة.
  • تحديث جهة اتصال — تغيّرت المعرّفات أو السمات في الصندوق.

بالنسبة لواتساب، تسلّم webhooks الخاصة بـ Meta الرسائل الواردة وتحديثات حالة الرسائل الصادرة إلى المنصة؛ ثم يعرض مزوّد الصندوق أحداثه الخاصة لأنظمتك.

كيف تبني مستقبِل webhook موثوقًا؟

اقبل بسرعة، وتحقق، وخزّن مرة واحدة، وعالج لاحقًا. تنشأ معظم مشكلات التسليم من تنفيذ عمل CRM داخل طلب webhook نفسه.

تصميم المستقبِل خطوة بخطوة

  1. اعرض نقطة نهاية HTTPS واحدة لكل بيئة، مثل /webhooks/inbox.
  2. تحقق من الأصالة. افحص التوقيع (غالبًا HMAC للجسم الخام بسر مشترك، كما يحدده RFC 2104) أو الرمز الذي يوثّقه المرسل. احسبه على البايتات الخام قبل تحليل JSON.
  3. افحص الحداثة. إذا كان هناك طابع زمني فارفض الأحداث الخارجة عن هامش قصير للحد من إعادة التشغيل.
  4. أزل التكرار. أدرج معرّف الحدث في جدول بقيد فريد. إذا فشل الإدراج لأن المعرّف موجود فأعد نجاحًا وتوقف.
  5. ضع في الطابور. ضع الحدث في طابور وأعد استجابة 2xx فورًا.
  6. عالج بشكل غير متزامن. يقرأ عامل (worker) من الطابور، ويطابق جهة الاتصال، ويكتب في CRM باستخدام upserts.
  7. أعد المحاولة مع تأخير تصاعدي. إذا كان CRM متوقفًا فأعد المحاولة من طابورك بتأخير أسي؛ ولا تعتمد على إعادة محاولات المرسل.
  8. طابور الرسائل الميتة. بعد عدة إخفاقات انقل الحدث إلى طابور الرسائل الميتة (dead-letter) ونبّه شخصًا.
  9. التسوية. شغّل مهمة دورية تقارن محادثات الصندوق الأخيرة بسجلات CRM وتسد الفجوات من API الصندوق.

لماذا تهم خاصية عدم التكرار والترتيب؟

يعيد مرسلو webhook المحاولة عادةً إذا لم يتلقوا استجابة نجاح في وقت مناسب، مما يجعل التسليم مرة واحدة على الأقل. قد يصل الحدث نفسه مرتين، وقد يصل حدث «تم الحل» قبل آخر «استلام رسالة». تعامل مع ذلك بما يلي:

  • استخدام معرّف الحدث كمفتاح لإزالة التكرار.
  • استخدام upserts بمفتاح معرّف المحادثة أو الرسالة في CRM.
  • مقارنة الطوابع الزمنية للأحداث أو أرقام التسلسل وتجاهل الحالة الأقدم.

وعندما يستدعي سير عمل CRM لديك API الصندوق لإرسال رسالة، مرّر مفتاح idempotency إن كانت API تدعمه؛ ويصف مشروع IETF لترويسة HTTP باسم Idempotency-Key النمط الشائع.

كيف تطابق جهات الاتصال عبر القنوات؟

طابق بمعرّفات مطبَّعة، وفضّل المطابقات القطعية، ووجّه الحالات الملتبسة إلى شخص.

المعرّف يُطبَّع إلى ثقة المطابقة ملاحظات
رقم واتساب أو SMS E.164، مثل +9715XXXXXXXX عالية انتبه للصيغ المحلية ذات الصفر البادئ
عنوان البريد الإلكتروني حروف صغيرة ودون مسافات عالية قد تكون الأسماء المستعارة للشخص نفسه؛ لا تفترض ذلك
حساب Instagram معرّف المستخدم الخاص بالمنصة عالية ضمن ذلك الحساب قد تتغير أسماء المستخدمين؛ خزّن المعرّف لا الاسم وحده
مستخدم Telegram معرّف مستخدم المنصة عالية ضمن ذلك البوت أو الحساب قد لا يُشارَك الهاتف
الاسم لا يُستخدم وحده منخفضة لا تدمج بالاسم أبدًا

قواعد القرار:

  1. تطابق دقيق واحد: اربط.
  2. لا تطابق: أنشئ عميلًا محتملًا أو «جهة اتصال غير مطابَقة» مع قناة المصدر.
  3. تطابقات متعددة: علّم المحادثة لوكيل، ولا تدمج تلقائيًا.
  4. يؤكد العميل معرّفًا آخر أثناء المحادثة: اربطه مع ملاحظة بالدليل.

كيف تتعامل مع خصوصية البيانات في تكامل CRM؟

انقل ما يحتاجه كل نظام فقط، ووثّق السبب، واجعل الحذف يعمل في النظامين.

  • تقليل البيانات. خزّن روابط المحادثات والنتائج والملخصات في CRM؛ وأبقِ النصوص الكاملة في الصندوق ما لم يكن هناك غرض محدد.
  • الأساس القانوني والموافقة. سجّل الموافقة على التسويق لكل قناة؛ فمحادثة الدعم ليست موافقة على القوالب التسويقية.
  • الاحتفاظ. وحّد مدد الاحتفاظ في الصندوق وCRM والطوابير والسجلات؛ وكثيرًا ما تُنسى سجلات حمولات webhook.
  • التحكم في الوصول. قيّد من يستطيع رؤية محتوى الرسائل والمرفقات في CRM.
  • طلبات الحذف والوصول. اجعل الطلب في نظام ينتقل إلى الآخر.
  • النقل عبر الحدود. تحقق من مكان تخزين كل نظام للبيانات. ينطبق GDPR على البيانات الشخصية للأشخاص في الاتحاد الأوروبي، ولدى الإمارات والسعودية قوانينها الخاصة لحماية البيانات الشخصية؛ فتأكد من الالتزامات الحالية لدى الجهة التنظيمية المعنية وفريقك القانوني.

كيف تبدو البنية المرجعية؟

نصيًا، التدفق هو: القنوات إلى الصندوق، والصندوق إلى المستقبِل، والمستقبِل إلى الطابور، والطابور إلى العامل، والعامل إلى CRM، وسير عمل CRM عائدًا إلى API الصندوق.

المكوّن المسؤولية قرار التصميم الرئيسي
القنوات (WhatsApp وInstagram والبريد وTelegram) توصيل رسائل العملاء إلى الصندوق تحكمها قواعد كل منصة
صندوق الوارد متعدد القنوات المحادثات والإسناد والوكلاء والأحداث يُصدر webhooks ويعرض API
مستقبِل webhook التحقق وإزالة التكرار ووضع الأحداث في الطابور بلا حالة، واستجابة 2xx سريعة
مخزن الأحداث والطابور مخزن مؤقت دائم وإعادة التشغيل معرّف حدث فريد وطابور رسائل ميتة
عامل المزامنة مطابقة جهات الاتصال وupserts في CRM كتابات idempotent وتأخير تصاعدي
CRM جهات الاتصال والصفقات والحالات وسير العمل يستدعي API الصندوق بمفاتيح idempotency
مهمة التسوية اكتشاف الفجوات وإصلاحها تعمل بجدول زمني
المراقبة التأخر والإخفاقات والرسائل الميتة تنبيهات إلى مسؤول

مثال تطبيقي: مجموعة عيادات في جدة

«واحات كلينيكس»، مجموعة رعاية صحية افتراضية في السعودية، تستخدم CRM لمواعيد المرضى وصندوق وارد لواتساب والبريد الإلكتروني.

  • يراسل مريض عبر واتساب. يُصدر الصندوق حدث إنشاء محادثة؛ ويتحقق المستقبِل منه ويخزنه ويضعه في الطابور.
  • يطبّع العامل الرقم إلى E.164، ويجد سجل مريض واحدًا، ويسجل نشاطًا برابط إلى المحادثة لا بنص الرسالة.
  • يُظهر CRM أن لغة المريض المفضلة هي العربية ويدفعها إلى الصندوق، فيوجّهها إلى القائمة العربية.
  • عند حجز الموعد في CRM، يستدعي سير عمل API الصندوق لإرسال تأكيد بقالب معتمد من فئة تحديثات المعاملات (Utility)، مع تمرير معرّف الموعد كمفتاح idempotency حتى لا تتسبب إعادة المحاولة في إرسال تأكيدين.
  • يحدّث حدث «تم تسليم الرسالة» من الصندوق سجل الموعد.

ما الأخطاء الشائعة؟

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

كيف تساعدك OmniChannels.ai؟

تجمع OmniChannels.ai، المدعومة من BroadNet Technologies، محادثات WhatsApp وInstagram وMessenger وTelegram والبريد الإلكتروني في صندوق الوارد الموحّد (Omni Inbox) واحد مع إسناد المحادثات إلى الموظفين ووسمها، إلى جانب ربط WhatsApp عبر Meta Embedded Signup وقوالب معتمدة بمتغيرات ووسائط وأزرار. ولتكامل CRM، تتوفر REST API موثّقة للعموم بمواصفات OpenAPI 3.1، وتُبلغ webhooks عن حالات التسليم (SENT وDELIVERED وREAD وFAILED وغيرها) بصيغة موحّدة واحدة. وتدعم تقارير التسليم مع المرشحات والتصدير بصيغة CSV تسوية الرسائل. ابدأ من صفحة المطورين.

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

ما الفرق بين webhook وAPI في تكامل CRM؟

الـ webhook طلب HTTP يرسله الصندوق إلى نقطة النهاية لديك عند وقوع حدث، مثل رسالة جديدة أو حل محادثة. أما API فهي ما يستدعيه نظامك لقراءة البيانات أو تنفيذ إجراءات، مثل إرسال رد أو إعادة إسناد محادثة. تُبقي webhooks نظام CRM محدّثًا دون استعلام دوري؛ وتتيح واجهات API لسير عمل CRM العمل على الصندوق.

ماذا تعني خاصية idempotency في webhooks؟

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

كيف تطابق رقم واتساب مع جهة اتصال في CRM؟

طبّع الطرفين إلى الصيغة الدولية E.164، بما في ذلك رمز الدولة ودون مسافات أو أصفار بادئة، ثم ابحث في CRM بهذه القيمة. إذا تطابقت جهة اتصال واحدة فقط فاربطها. وإذا لم تتطابق أي جهة فأنشئ عميلًا محتملًا أو جهة اتصال غير مطابَقة. وإذا تطابق عدة جهات فلا تخمّن؛ علّم المحادثة ليختار وكيل، وسجّل القرار للمرات القادمة.

هل ينبغي تخزين نصوص المحادثات كاملة في CRM؟

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

كيف تُؤمَّن نقاط نهاية webhook؟

قدّم نقطة النهاية عبر HTTPS فقط، وتحقق من التوقيع أو السر المشترك الذي يرفقه المرسل مع كل طلب، وارفض الطلبات ذات الطوابع الزمنية القديمة للحد من إعادة التشغيل (replay)، واحفظ الأسرار في مدير أسرار لا في الشيفرة. وقيّد ما تستطيع نقطة النهاية فعله: ينبغي أن تضع الأحداث في طابور فقط، لا أن تكشف بيانات CRM أو تقبل أوامر عشوائية.

المصادر

  1. Webhooks — WhatsApp Cloud API، Meta for Developers
  2. ترويسة HTTP باسم Idempotency-Key — مسودة مجموعة عمل IETF HTTPAPI
  3. RFC 2104: HMAC — التجزئة المفتاحية لمصادقة الرسائل
  4. اللائحة (EU) 2016/679 (GDPR) — EUR-Lex
  5. قوانين حماية البيانات — البوابة الرسمية لحكومة دولة الإمارات (u.ae)