كيف تربط WooCommerce بـ WhatsApp لإرسال إشعارات الطلبات تلقائيًا عبر Whats360 API؟ شرح عملي

يمكن تحويل متجر WooCommerce إلى نظام تواصل آلي مع العملاء بمجرد ربط أحداث الطلبات داخل المتجر بواجهة WhatsApp API. بدلًا من أن يراجع فريق المتجر الطلبات يدويًا ويرسل رسالة لكل عميل، يمكن للنظام اكتشاف الحدث تلقائيًا ثم إرسال الرسالة المناسبة عبر Whats360.

عند إنشاء طلب جديد، يمكن إرسال رسالة تأكيد للعميل. وعندما تتغير حالة الطلب إلى «في انتظار الدفع» أو «قيد المعالجة» أو «مكتمل»، يمكن تشغيل رسالة مختلفة تلقائيًا. ويمكن أيضًا استخدام نفس البنية لإرسال تنبيهات داخلية، مثل إشعار المسؤول عند نفاد مخزون منتج.

الفكرة الأساسية هي تحويل أحداث WooCommerce إلى Workflows آلية:

هذا الأسلوب لا يجعل WhatsApp مجرد قناة لإرسال رسالة يدوية، بل يجعله جزءًا من دورة تشغيل المتجر، بحيث تبدأ الرسالة نتيجة حدث حقيقي داخل النظام.

ما الذي يعنيه ربط WooCommerce بـ WhatsApp API؟

عند حدوث حدث داخل WooCommerce، يستطيع WordPress تشغيل كود مرتبط بهذا الحدث باستخدام ما يعرف باسم Hooks. يستطيع الكود بعد ذلك قراءة بيانات الطلب، مثل رقم الطلب واسم العميل ورقم الهاتف، وإنشاء الرسالة المناسبة ثم إرسالها إلى واجهة Whats360 API.

بمعنى آخر، لا يحتاج WooCommerce نفسه إلى معرفة تفاصيل كل عملية إرسال. هو يكتشف الحدث، بينما تتولى الدالة البرمجية مهمة الاتصال بالـAPI.

متى يكون هذا النوع من التكامل مفيدًا؟

يكون الربط مفيدًا عندما يحتاج المتجر إلى تقليل العمل اليدوي المرتبط بالتواصل مع العملاء أو الإدارة. بدلًا من أن يتابع الموظف لوحة الطلبات ويرسل الرسائل بنفسه، تصبح بعض الرسائل نتيجة مباشرة لتغير حالة الطلب.

ومن أمثلة ذلك:

• تأكيد استلام الطلب.
• إبلاغ العميل بأن الطلب في انتظار الدفع.
• إبلاغ العميل بأن الطلب دخل مرحلة المعالجة.
• إبلاغ العميل باكتمال الطلب.
• إرسال رسالة ترحيب عند إنشاء حساب جديد.
• إرسال تنبيه للمسؤول عند نفاد المخزون.

القيمة الحقيقية هنا ليست في إرسال رسالة واحدة، وإنما في بناء Workflow يمكن توسيعه لاحقًا حسب احتياجات المتجر.

المكونات المطلوبة قبل بدء الربط

يحتاج هذا النموذج إلى متجر WordPress يعمل عليه WooCommerce، بالإضافة إلى حساب في Whats360 وبيانات الاتصال اللازمة بالـAPI.

متجر WordPress يعمل عليه WooCommerce

لأن السيناريو يعتمد على WooCommerce Hooks، يجب أن يكون المتجر يعمل باستخدام WooCommerce وأن تكون الأحداث المطلوبة متاحة في النظام.

حساب Whats360

يستخدم الحساب لتوفير طبقة الاتصال اللازمة لإرسال رسائل WhatsApp من الكود البرمجي.

Access Token

يحتاج الكود إلى Access Token لاستخدام واجهة API وفق آلية المصادقة المعتمدة.

Instance ID

يحتاج الإرسال أيضًا إلى Instance ID، وهو المعرف المستخدم للـInstance أو الجهاز الذي سيتم الاعتماد عليه في عملية الإرسال.

رقم الهاتف المستهدف

عند إرسال إشعار إلى عميل، يحتاج النظام إلى رقم الهاتف المخزن في بيانات الطلب. وعند إرسال تنبيه داخلي، يمكن استخدام رقم المسؤول المخزن في إعدادات النظام.

طريقة لتنفيذ كود PHP

يمكن استخدام إضافة مثل Code Snippets لتنظيم الأكواد داخل WordPress بدل تعديل ملفات القالب مباشرة. وتصبح هذه الطريقة عملية عند وجود أكثر من Snippet مرتبط بالـWooCommerce.

البنية الأفضل للكود: دالة إرسال مركزية

من الأخطاء الشائعة كتابة كود API منفصل لكل حالة من حالات WooCommerce. هذا يجعل المشروع أصعب في الصيانة، لأن أي تغيير في طريقة الاتصال بالـAPI يحتاج إلى تعديل عدة أماكن.

الأفضل هو إنشاء Function واحدة مسؤولة عن الإرسال، ثم تستدعيها جميع السيناريوهات.

في النموذج البرمجي المرجعي تسمى الدالة:

send_w360_msg()

وتستقبل بشكل أساسي رقم الهاتف والرسالة:

phone
message

ثم تقرأ بيانات الاتصال المخزنة، مثل Token وInstance ID، وتجهز طلب API.

بهذا الشكل تصبح البنية:

الميزة هنا أن منطق الإرسال يصبح في مكان واحد، بينما يظل منطق كل حدث منفصلًا عن عملية الاتصال.

تنظيف رقم الهاتف قبل الإرسال

رقم الهاتف المخزن في WooCommerce قد يحتوي على مسافات أو رموز أو علامات مختلفة. لذلك يجب تنظيف الرقم قبل استخدامه في طلب API.

في النموذج المرجعي يتم استخدام:

$phone = preg_replace('/[^0-9]/', '', $phone);

والهدف هو الاحتفاظ بالأرقام فقط.

بعد ذلك يتم تكوين معرف المستلم بالشكل المستخدم في النموذج:

$jid = $phone . "@s.whatsapp.net";

لكن هناك نقطة مهمة في المشاريع الحقيقية: تنظيف الرقم لا يعني بالضرورة توحيد مفتاح الدولة. إذا كان المتجر يسمح بإدخال أرقام محلية وأرقام دولية بصيغ مختلفة، فمن الأفضل إضافة طبقة واضحة لتوحيد صيغة الرقم قبل تكوين JID.

كيف يتم الاتصال بـWhats360 API؟

في البنية البرمجية المرجعية يتم الاعتماد على نقطة الإرسال:

GET /api/v1/send-text

وتتضمن البيانات الأساسية التي يتم تجهيزها للطلب:

token
instance_id
jid
msg

وتقوم الدالة بتكوين Parameters ثم بناء عنوان الطلب باستخدام http_build_query().

$params = [
    'token' => $token,
    'instance_id' => $instance_id,
    'jid' => $jid,
    'msg' => $message
];

$url = 'https://whats360.live/api/v1/send-text?' . http_build_query($params);

wp_remote_get($url);

بهذا يصبح WordPress هو طبقة التنفيذ التي تستدعي واجهة Whats360، بينما تبقى أحداث WooCommerce مسؤولة عن تحديد متى يجب إرسال الرسالة.

إرسال رسالة تلقائية عند إنشاء الطلب

من السيناريوهات الأساسية إرسال رسالة للعميل بعد إنشاء الطلب أو وصوله إلى صفحة تأكيد الطلب.

في النموذج المرجعي يتم استخدام Hook:

woocommerce_thankyou

ويتم من خلاله الحصول على رقم الطلب ثم جلب بيانات الطلب باستخدام WooCommerce.

بعد ذلك يمكن الحصول على رقم هاتف العميل والاسم الأول وإنشاء رسالة مثل:

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

ومن أمثلة البيانات التي يمكن قراءتها:

$order->get_billing_phone();
$order->get_billing_first_name();

ثم يتم استدعاء دالة الإرسال:

send_w360_msg($phone, $msg);

منح العميل تجربة أفضل بعد الطلب

تأكيد الطلب عبر WhatsApp لا يتعلق فقط بإرسال معلومة تقنية. الرسالة يمكن أن تكون نقطة بداية لتجربة تواصل أفضل، لأنها تؤكد للعميل أن النظام استلم طلبه.

لكن يجب أن تكون الرسالة مرتبطة فعلًا بالحدث. فلا معنى لإرسال رسالة «تم تجهيز طلبك» في اللحظة التي لم يبدأ فيها تجهيز الطلب بعد.

لذلك يجب أن تتطابق الرسالة مع حالة الطلب الحقيقية.

إرسال رسالة عند حالة انتظار الدفع

عندما ينتقل الطلب إلى حالة Pending، يمكن تشغيل Hook:

woocommerce_order_status_pending

ويتم إرسال رسالة مناسبة مثل:

هذا النوع من الإشعارات يختلف عن رسالة تأكيد الطلب، لأن الهدف هنا هو إبلاغ العميل بالحالة الحالية بدل إعادة تأكيد إنشاء الطلب.

إرسال رسالة عند بدء معالجة الطلب

عندما ينتقل الطلب إلى حالة Processing، يمكن استخدام:

woocommerce_order_status_processing

ثم بناء رسالة مرتبطة بالمرحلة الجديدة:

هنا يصبح WhatsApp قناة لإبقاء العميل على اطلاع بتقدم الطلب بدل أن يضطر إلى فتح الموقع لمعرفة التحديث.

إرسال رسالة عند اكتمال الطلب

عندما يصبح الطلب Completed يمكن تشغيل:

woocommerce_order_status_completed

ويمكن إرسال رسالة مثل:

مرة أخرى، المهم هو ارتباط الرسالة بالحدث الفعلي. كل حالة لها وظيفة مختلفة داخل رحلة العميل.

ترحيب العميل الجديد تلقائيًا

يمكن توسيع التكامل خارج دورة الطلب نفسها.

في النموذج المرجعي يتم استخدام:

woocommerce_created_customer

ويمكن استخدام هذا الحدث لإرسال رسالة ترحيب بعد إنشاء حساب جديد.

بهذا يصبح التكامل قادرًا على التعامل مع أكثر من نوع من أحداث WooCommerce، وليس الطلبات فقط.

تنبيه الإدارة عند نفاد المخزون

WhatsApp Automation يمكن أن تكون موجهة إلى الإدارة أيضًا.

في النموذج المرجعي يتم استخدام:

woocommerce_no_stock

عند نفاد مخزون منتج، يمكن الحصول على اسم المنتج وإرسال رسالة إلى رقم المسؤول.

هذا النوع من الأتمتة مفيد لأنه ينقل المعلومة إلى المسؤول فور وقوع الحدث بدل الاعتماد على مراجعة لوحة التحكم بشكل مستمر.

من رسالة واحدة إلى Workflow كامل

عند جمع الأحداث السابقة يمكن تصور رحلة متكاملة:

وفي مسار منفصل يمكن أن تعمل تنبيهات الإدارة:

هذه هي النقلة المهمة من «إرسال WhatsApp» إلى «أتمتة تشغيل المتجر».

كيف تمنع إرسال الرسالة أكثر من مرة؟

من أهم النقاط عند بناء Automation أن تفكر في التكرار منذ البداية.

في بعض الأحداث قد يتم استدعاء الكود أكثر من مرة أو قد يحدث تنفيذ لنفس السيناريو بطريقة غير مقصودة. لذلك يمكن تسجيل حالة الإرسال في بيانات الطلب.

في النموذج المرجعي تم استخدام:

_w360_sent_thankyou

ثم فحص القيمة قبل إرسال الرسالة.

if ($order->get_meta('_w360_sent_thankyou')) return;

وبعد الإرسال يتم تحديث بيانات الطلب وتسجيل أن الرسالة تم إرسالها.

الفكرة التشغيلية هي:

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

لماذا لا يكفي نسخ Snippet من الإنترنت؟

قد يبدو ربط WooCommerce بـWhatsApp بسيطًا من الخارج: Hook ثم API Request ثم رسالة. لكن التطبيق الحقيقي يحتاج إلى فهم البيانات التي يوفرها كل Hook، وصيغة أرقام الهواتف، وإدارة الأخطاء، ومنع التكرار، وطريقة حفظ Credentials.

الكود الذي يعمل في متجر قد لا يكون مناسبًا لمتجر آخر إذا اختلفت طريقة تخزين أرقام العملاء أو حالات الطلب أو منطق التشغيل.

لذلك الأفضل التعامل مع الكود كنقطة بداية لبناء Integration مناسب، وليس كقطعة يجب نسخها دون اختبار.

أكثر الأخطاء شيوعًا في ربط WooCommerce بـWhatsApp

Access Token غير صحيح

إذا كانت بيانات المصادقة غير صحيحة، فلن ينجح طلب API بالشكل المتوقع. لذلك يجب التحقق من بيانات الحساب قبل تعديل كود WooCommerce نفسه.

Instance ID غير صحيح

يجب أن يكون الـInstance المستخدم هو الـInstance المقصود بالإرسال. وجود Token صحيح لا يعني تلقائيًا أن كل Instance ID صالح لكل سيناريو.

رقم الهاتف بصيغة غير مناسبة

قد يكون رقم العميل مخزنًا مع مسافات أو رموز أو بصيغة محلية، بينما يحتاج الإرسال إلى صيغة مختلفة. تنظيف الرقم خطوة أساسية، وقد تحتاج المشاريع إلى Normalization إضافي لمفتاح الدولة.

الـInstance غير جاهز للإرسال

إذا كانت طبقة الاتصال نفسها غير متاحة، فلا يجب افتراض أن المشكلة في Hook أو في كود WooCommerce.

التشخيص الأفضل يكون على شكل طبقات:

وبذلك يمكن تحديد الطبقة التي حدثت عندها المشكلة بدل تعديل كل أجزاء النظام عشوائيًا.

اختيار Hook غير مناسب

كل Hook له توقيت وسياق مختلف. لذلك يجب معرفة متى يتم تشغيله وما البيانات التي تكون متاحة له.

تكرار الرسائل

يجب تصميم آلية لتتبع الرسائل التي تم إرسالها بالفعل عندما يكون السيناريو معرضًا للتكرار.

كشف بيانات API

Access Token من البيانات التي يجب التعامل معها بحذر. لا تضعه في منشور عام أو مستودع عام أو Screenshot أو ملف يتم مشاركته مع أشخاص غير موثوقين.

كيف تختبر التكامل قبل تشغيله على المتجر الحقيقي؟

أفضل طريقة هي البدء بطلب تجريبي وعدم الانتقال مباشرة إلى تشغيل واسع.

اختبر إنشاء الطلب

أنشئ طلبًا تجريبيًا وتحقق من تشغيل الحدث المطلوب.

تحقق من بيانات العميل

تأكد من أن اسم العميل ورقم الهاتف يتم قراءتهما بالشكل الصحيح.

تحقق من بيانات الاتصال

تأكد من وجود Access Token وInstance ID الصحيحين.

اختبر طلب API

تحقق من أن Parameters المطلوبة يتم تجهيزها قبل إرسال الطلب.

تحقق من وصول الرسالة

إذا نجح طلب API ولكن لم تصل الرسالة، انتقل إلى فحص طبقة الاتصال والـInstance بدل افتراض أن المشكلة في WooCommerce.

اختبر حالات الطلب المختلفة

لا تكتفِ باختبار حالة واحدة. جرّب الحالات التي يعتمد عليها الـWorkflow:

• Pending
• Processing
• Completed

اختبر منع التكرار

تأكد من أن تنفيذ نفس الحدث بالطريقة غير المقصودة لا يؤدي إلى إرسال رسائل متكررة للعميل.

هل تحتاج إلى كود مخصص أم منصة متكاملة؟

الاختيار يعتمد على حجم السيناريو المطلوب.

الاحتياج	الحل المناسب
إشعار بسيط واحد	كود مخصص قد يكون كافيًا
عدة حالات WooCommerce	تنظيم Automation أفضل
ربط عدة أنظمة	API وIntegration Layer
إدارة محادثات الفريق	CRM
ردود آلية	AI أو Chatbot
Workflows متعددة ومتنامية	منصة متخصصة

الكود المخصص مناسب جدًا عندما تكون الحاجة محددة وواضحة. لكن عندما يبدأ المشروع في التوسع إلى عدد كبير من السيناريوهات، تصبح إدارة الـAutomation نفسها أمرًا مهمًا.

متى تصبح Whats360 جزءًا من بنية أكبر؟

إذا كان المطلوب مجرد إرسال رسالة واحدة، فقد يكون Snippet بسيط مناسبًا. لكن إذا كان المتجر يحتاج إلى API وAutomation وCRM وAI وربط عدة أحداث، فمن الأفضل التفكير في البنية الكاملة بدل إضافة عشرات الأكواد المنفصلة.

يمكن أن تعمل Whats360 كطبقة اتصال ضمن منظومة أكبر، بحيث تكون الأحداث داخل المتجر هي بداية الـWorkflow.

وبذلك يمكن أن تتحول الرسائل من أحداث منفردة إلى جزء من دورة تشغيل كاملة.

تخصيص رسائل WhatsApp حسب بيانات الطلب

من نقاط القوة في الربط البرمجي أن الرسالة يمكن أن تتغير حسب البيانات الفعلية.

مثلًا يمكن تصور الرسالة باستخدام اسم العميل ورقم الطلب وحالة الطلب أو أي بيانات أخرى متاحة داخل WooCommerce.

مثلًا يمكن تصور رسالة مخصصة بهذا الشكل:

مرحبًا أحمد، تم استلام طلبك رقم #1542 بنجاح، ويجري الآن تجهيز الطلب. سنرسل لك تحديثًا جديدًا عند انتقاله إلى المرحلة التالية.

الفكرة هنا ليست مجرد إرسال رسالة ثابتة، وإنما إنشاء رسالة مرتبطة بالسياق الفعلي للطلب. وهذا يجعل إشعارات WhatsApp أكثر فائدة للعميل، ويقلل الحاجة إلى الاستفسارات المتكررة عن حالة الطلب.

ما البيانات التي يمكن استخدامها داخل الرسالة؟

• اسم العميل.
• رقم الطلب.
• رقم هاتف العميل.
• حالة الطلب.
• إجمالي قيمة الطلب.
• بيانات الشحن المتاحة.
• اسم المنتج أو المنتجات حسب السيناريو البرمجي.
• بيانات أخرى يوفرها WooCommerce أو النظام المرتبط به.

وبذلك يمكن بناء رسائل مختلفة لكل حدث بدل استخدام نص واحد لجميع الحالات.

بناء Workflow لإشعارات WooCommerce عبر WhatsApp

الأفضل عند تصميم الربط ألا يتم التعامل مع كل إشعار باعتباره وظيفة منفصلة، بل باعتباره جزءًا من Workflow واضح يبدأ من حدوث الحدث داخل المتجر وينتهي بوصول الرسالة إلى العميل أو المسؤول.

يمكن تصور مسار العمل بهذا الشكل:

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

لماذا الفصل بين الحدث ودالة الإرسال مهم؟

في المثال البرمجي المستخدم في الربط، توجد دالة مركزية مسؤولة عن إرسال الرسالة. وتستدعيها الأحداث المختلفة مثل إنشاء الطلب أو تغيير حالته.

هذا الأسلوب يجعل النظام أكثر قابلية للتوسع، لأن المطور يستطيع إضافة Workflow جديد باستخدام نفس آلية الإرسال بدل كتابة اتصال API جديد لكل حالة.

على سبيل المثال، يمكن إضافة إشعار عند إلغاء الطلب، أو عند فشل الدفع، أو عند وجود تحديث في الشحن، مع الاحتفاظ بمنطق الاتصال نفسه.

إضافة حالات طلب جديدة إلى WooCommerce

السيناريوهات الأساسية لا تغطي بالضرورة كل احتياجات المتاجر. بعض المتاجر تستخدم حالات مخصصة للطلبات، خصوصًا عندما يكون لديها نظام شحن أو مخزون أو معالجة داخلية مختلفة.

في هذه الحالة يمكن إنشاء Hook أو Workflow يتعامل مع الحالة المطلوبة ثم يستدعي دالة إرسال Whats360.

ومن السيناريوهات التي يمكن تخصيصها:

• إلغاء الطلب.
• فشل الدفع.
• تأكيد الدفع.
• تجهيز الطلب.
• تسليم الطلب لشركة الشحن.
• إضافة رقم التتبع.
• وصول الطلب إلى العميل.
• طلب الاستبدال أو الاسترجاع.

المهم أن يتم تحديد الحدث المطلوب بدقة قبل كتابة الكود، لأن اختيار Hook غير مناسب قد يؤدي إلى إرسال الرسالة في توقيت غير مقصود.

منع إرسال الإشعار أكثر من مرة

من المشاكل المهمة في أي نظام إشعارات تلقائي احتمال تكرار الرسالة نتيجة تشغيل الحدث أكثر من مرة أو إعادة معالجة الطلب.

ولهذا يتضمن النموذج البرمجي المستخدم في إشعار الطلب الجديد فكرة مهمة، وهي حفظ علامة داخل بيانات الطلب بعد نجاح تنفيذ الإشعار.

الفكرة ببساطة أن النظام يستطيع التحقق من وجود العلامة قبل إرسال الرسالة مرة أخرى.

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

إرسال تنبيهات WhatsApp للمسؤول بدل العميل

ليس كل Workflow داخل WooCommerce موجهًا إلى العميل. بعض الأحداث تكون أهميتها داخلية، مثل انخفاض المخزون أو نفاد منتج معين.

في هذه الحالة يمكن تحديد رقم إداري يستقبل التنبيه بدل إرسال الرسالة إلى رقم العميل.

على سبيل المثال، عند نفاد مخزون منتج يمكن أن تصل رسالة إلى المسؤول تتضمن اسم المنتج الذي أصبح غير متوفر.

لماذا تختلف الرسالة الإدارية عن رسالة العميل؟

الهدف مختلف. رسالة العميل تهدف إلى إبلاغه بحالة طلبه أو مساعدته أثناء عملية الشراء، بينما رسالة المسؤول تهدف إلى اتخاذ إجراء تشغيلي.

لذلك يمكن أن تكون الرسالة الإدارية أكثر اختصارًا وتركيزًا على الحدث:

🚨 تنبيه مخزون: نفد مخزون المنتج “اسم المنتج”. يرجى مراجعة المخزون واتخاذ الإجراء المناسب.

هذا النوع من الأتمتة يحول WhatsApp من قناة تواصل مع العملاء فقط إلى قناة تنبيهات تشغيلية مرتبطة بالمتجر.

أتمتة إشعارات نفاد المخزون

من السيناريوهات المفيدة للمتاجر التي تعتمد على WooCommerce مراقبة المنتجات التي وصلت إلى كمية صفرية.

بدل الاعتماد على مراجعة لوحة التحكم باستمرار، يمكن ربط حدث نفاد المخزون بإرسال إشعار تلقائي إلى الرقم المسؤول.

وبهذا يصبح سير العمل:

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

إشعارات التسجيل للعملاء الجدد

يمكن أيضًا استخدام الربط لإرسال رسالة ترحيبية عند إنشاء حساب جديد في المتجر.

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

ويستطيع المطور تعديل الرسالة لتناسب طبيعة النشاط، مثل الترحيب بالعميل أو توجيهه إلى خدمة العملاء أو تعريفه بالخطوة التالية في رحلة الشراء.

متى يكون هذا النوع من الرسائل مفيدًا؟

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

لكن يجب عدم تحويل كل حدث في الموقع إلى رسالة تلقائية بلا هدف. القيمة الحقيقية للأتمتة تأتي عندما تكون الرسالة مرتبطة بإجراء أو معلومة يحتاج إليها العميل.

إضافة إشعارات للسلات المتروكة

السلات المتروكة من السيناريوهات التي يمكن تطويرها فوق نفس البنية البرمجية، لكن تنفيذها يحتاج إلى منطق إضافي يحدد متى تعتبر السلة متروكة ومتى يسمح النظام بإرسال تذكير.

الفكرة العامة هي اكتشاف حالة عدم اكتمال عملية الشراء، ثم إنشاء Workflow يقرر ما إذا كان العميل مؤهلًا للتذكير، وبعد ذلك إرسال رسالة مناسبة.

هنا يجب الفصل بين اكتشاف السلة وبين إرسال الرسالة، لأن وجود عملية Checkout غير مكتملة لا يعني تلقائيًا أن كل حالة يجب أن تحصل على رسالة.

وهنا تظهر قيمة الربط البرمجي؛ فبدل أن يكون WhatsApp منفصلًا عن المتجر، يصبح جزءًا من دورة العمل نفسها.

إضافة رقم الدولة إلى أرقام العملاء

من النقاط التي يجب الانتباه إليها أثناء تطوير أي تكامل مع WhatsApp طريقة تخزين أرقام الهاتف.

قد يتم إدخال الرقم بصيغة محلية داخل WooCommerce، بينما يحتاج نظام الإرسال إلى صيغة دولية واضحة.

لذلك يمكن تعديل منطق تنظيف الرقم بحيث يتعامل مع صيغة الأرقام المستخدمة في المتجر قبل بناء معرف WhatsApp المطلوب للإرسال.

في السوق المصري مثلًا، قد تحتاج بعض السيناريوهات إلى التعامل مع رقم يبدأ بصيغة محلية ثم تحويله إلى صيغة دولية مناسبة قبل الإرسال.

ولا ينبغي تطبيق قاعدة واحدة على جميع الدول بشكل عشوائي؛ الأفضل أن يتم تحديد الدولة المستهدفة ومنطق تنسيق أرقامها قبل تنفيذ التحويل.

لماذا تعتبر صيغة الرقم مهمة؟

لأن نجاح استدعاء API لا يعني بالضرورة أن منطق البيانات في المتجر صحيح. إذا كان الرقم المرسل إلى واجهة البرمجة غير مطابق للصيغة التي يتوقعها النظام، فقد يفشل Workflow حتى لو كان الاتصال نفسه يعمل.

ولهذا يجب التعامل مع تنسيق أرقام الهواتف كجزء من طبقة البيانات، وليس مجرد تعديل سريع داخل دالة الإرسال.

التعامل مع أخطاء الإرسال

في أي تكامل بين WooCommerce وواجهة API خارجية، يجب التفكير في احتمال فشل الطلب البرمجي.

قد تكون المشكلة مرتبطة بإعدادات الحساب، أو بيانات الاتصال، أو الجهاز، أو الاتصال بالخدمة، أو بيانات المستلم، أو أي عامل آخر خارج منطق WooCommerce نفسه.

لذلك لا يكفي أن يحتوي الكود على استدعاء للإرسال فقط. من الأفضل في المشاريع الإنتاجية إضافة آلية مناسبة للتعامل مع الاستجابة والأخطاء وتسجيل الأحداث المهمة.

ما الذي يجب مراقبته؟

• هل تم تنفيذ الحدث داخل WooCommerce؟
• هل تم العثور على رقم الهاتف؟
• هل بيانات المصادقة موجودة؟
• هل تم إرسال طلب API؟
• ما نتيجة الاستجابة؟
• هل تم تسجيل نجاح أو فشل العملية؟
• هل يجب إعادة المحاولة أم منع التكرار؟

هذه النقاط تصبح أكثر أهمية عندما يتحول الربط من تجربة بسيطة إلى جزء أساسي من عمليات متجر يعتمد على الإشعارات اليومية.

متى تحتاج إلى تطوير الربط بشكل احترافي؟

الكود الجاهز مناسب كنقطة بداية للسيناريوهات الواضحة، لكنه قد لا يكون كافيًا عندما تكون احتياجات المتجر أكثر تعقيدًا.

قد تحتاج إلى تطوير مخصص عندما تريد ربط WooCommerce مع CRM أو نظام ERP أو منصة شحن أو نظام محاسبي أو تطبيق خاص.

في هذه الحالة لا يكون الهدف مجرد إرسال رسالة، وإنما بناء Integration Layer تتبادل البيانات بين أكثر من نظام.

أمثلة على التكاملات المتقدمة

• WooCommerce مع WhatsApp.
• WooCommerce مع CRM.
• WooCommerce مع نظام الشحن.
• WooCommerce مع نظام إدارة المخزون.
• WooCommerce مع نظام المحاسبة.
• WooCommerce مع تطبيق أو منصة مخصصة.

ويمكن أن يصبح WhatsApp في هذه البنية قناة إخراج للأحداث الناتجة من الأنظمة المختلفة، بدل أن يكون مجرد إضافة منفصلة داخل المتجر.

الفرق بين إشعار WhatsApp البسيط وWorkflow المتكامل

إشعار بسيط	Workflow متكامل
يرسل رسالة عند حدوث حدث واحد	يربط عدة أحداث وقرارات ضمن مسار واضح
منطق محدود	منطق أكثر قابلية للتوسع
مناسب للتجارب البسيطة	مناسب للأنظمة التجارية الأكبر
قد يعتمد على كود مباشر	يمكن أن يتضمن API وWebhooks وأنظمة أخرى
هدفه الأساسي الإشعار	هدفه الأتمتة وتحسين التشغيل

الاختيار بين النموذجين يعتمد على احتياجات المشروع. ليس كل متجر يحتاج إلى بنية معقدة، لكن من المهم تصميم الكود بحيث يمكن تطويره إذا توسعت المتطلبات.

ربط WooCommerce مع Whats360 باستخدام API

عند استخدام API، يصبح WooCommerce قادرًا على إرسال طلب برمجي إلى منصة Whats360 عند تحقق الحدث المحدد.

وفي النموذج المستخدم في هذا السيناريو، تعتمد دالة الإرسال على بيانات مثل Access Token وInstance ID ورقم المستلم ونص الرسالة.

هذه البيانات تشكل الحد الأدنى المطلوب لبناء عملية إرسال من النظام إلى WhatsApp وفق البنية البرمجية المستخدمة في المثال.

وتكمن أهمية API في أنها تسمح للنظام بتنفيذ عملية الإرسال تلقائيًا بدل اعتماد الموظف على نسخ البيانات من لوحة WooCommerce ثم إرسالها يدويًا.

ما دور Access Token؟

يستخدم Access Token كبيانات مصادقة ضمن طلب API. لذلك يجب التعامل معه باعتباره بيانات حساسة وعدم وضعه في مكان مكشوف أو مشاركته مع أطراف غير موثوقة.

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

ما دور Instance ID؟

Instance ID يحدد الجهاز أو الاتصال الذي سيستخدمه النظام ضمن البنية المعتمدة في الحساب.

ولهذا يجب أن تكون قيمة Instance ID صحيحة ومتوافقة مع الجهاز أو الاتصال الذي تريد استخدامه في Workflow الإرسال.

ما دور رقم المستلم؟

رقم المستلم يحدد الجهة التي ستصل إليها الرسالة. وفي إشعارات الطلبات يكون عادة رقم العميل، بينما في التنبيهات الداخلية قد يكون رقم المسؤول أو فريق التشغيل.

وهذا الفصل بين المستلم والمنطق التجاري مهم لأنه يسمح باستخدام نفس طبقة الإرسال في سيناريوهات مختلفة.

الحفاظ على بيانات API بأمان

أحد أهم الجوانب في أي تكامل برمجي هو حماية بيانات الوصول.

Access Token وبيانات الاتصال لا ينبغي التعامل معها مثل نص عادي يمكن نشره داخل صفحات الموقع أو مشاركته في الشروحات العامة مع بيانات حقيقية.

كما يجب تجنب إرسال بيانات الحساب الحساسة إلى أي شخص عبر قنوات غير آمنة. وإذا احتاج المشروع إلى مساعدة تقنية، فمن الأفضل استخدام آلية الدعم المناسبة بدل نشر مفاتيح الوصول بشكل علني.

كيف تبدأ تنفيذ الربط عمليًا؟

ابدأ بتحديد الحدث الذي تريد أتمتته بدل البدء بالكود مباشرة.

إذا كان الهدف هو إرسال رسالة عند إنشاء الطلب، حدد هذه النقطة باعتبارها Workflow مستقلًا. وإذا كان الهدف هو متابعة حالة الطلب، حدد الحالات التي تستحق رسالة وحدد النص والمستلم لكل حالة.

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

خطة اختبار عملية

• اختبر الاتصال ببيانات الحساب الصحيحة.
• اختبر إرسال رسالة واحدة إلى رقم اختبار.
• أنشئ طلب WooCommerce تجريبيًا.
• تحقق من وصول إشعار الطلب.
• غيّر حالة الطلب.
• تحقق من Workflow الخاص بالحالة الجديدة.
• اختبر عدم تكرار الرسالة عندما يكون هناك شرط يمنع التكرار.
• اختبر السيناريوهات غير المتوقعة قبل تشغيل الربط على الطلبات الحقيقية.

التدرج في الاختبار أفضل من تفعيل جميع السيناريوهات مرة واحدة، لأنه يجعل تحديد مصدر المشكلة أسهل.

تطوير الربط إلى نظام إشعارات متكامل

بعد نجاح الربط الأساسي، يمكن بناء طبقة أكبر من الأتمتة حسب احتياجات المشروع.

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

وهكذا تتحول البنية تدريجيًا من Script صغير إلى نظام اتصال بين المتجر وWhatsApp.

هل تحتاج إلى إضافة WordPress؟

ليس بالضرورة أن تكون كل عملية تكامل بحاجة إلى إضافة مستقلة. في بعض السيناريوهات يمكن تنفيذ الربط باستخدام Hooks الخاصة بـWooCommerce وإضافة برمجية مثل Code Snippets.

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

لكن عندما تزيد المتطلبات، قد يصبح بناء إضافة مخصصة أو طبقة Integration مستقلة أكثر تنظيمًا، خصوصًا إذا كان هناك عدد كبير من Workflows أو إعدادات تحتاج إلى إدارة من لوحة التحكم.

متى يكون الحل البسيط مناسبًا؟

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

متى تحتاج إلى حل أكثر تقدمًا؟

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

أخطاء يجب تجنبها عند بناء تكامل WooCommerce وWhatsApp

هناك مجموعة من الأخطاء البرمجية والتشغيلية التي يمكن أن تجعل الربط يبدو ناجحًا في البداية ثم يسبب مشاكل عند زيادة حجم الاستخدام.

• وضع بيانات API الحساسة داخل محتوى عام.
• عدم تنظيف أرقام الهواتف قبل الإرسال.
• عدم التعامل مع الأرقام الدولية بشكل صحيح.
• إرسال الرسالة أكثر من مرة بسبب عدم وجود منطق لمنع التكرار.
• ربط عدد كبير من الأحداث دون اختبار كل حدث.
• عدم تسجيل الأخطاء المهمة.
• الاعتماد على نص ثابت لا يناسب حالة الطلب.
• عدم تحديد المستلم الصحيح لكل Workflow.
• إضافة أتمتة كثيرة دون تحديد هدف واضح لكل رسالة.

تجنب هذه الأخطاء لا يعتمد على الكود فقط، بل على تصميم Workflow واضح منذ البداية.

كيف تجعل إشعارات WhatsApp أكثر فائدة للعميل؟

الإشعار الجيد لا يخبر العميل فقط بأن شيئًا حدث، بل يعطيه المعلومة التي يحتاج إليها في تلك اللحظة.

إذا كان الطلب تم استلامه، يكفي توضيح أن الطلب وصل بنجاح. وإذا أصبح قيد المعالجة، يجب أن يعرف العميل أن المتجر بدأ تجهيز الطلب. وإذا اكتملت العملية، يجب أن تكون الرسالة واضحة بشأن حالة الطلب التالية.

لذلك يجب أن تتغير الرسالة حسب الحدث بدل إرسال نفس النص في كل مرحلة.

الرسالة الجيدة يجب أن تكون

• مرتبطة بالحدث.
• واضحة.
• قصيرة نسبيًا.
• مباشرة.
• مناسبة للعميل.
• خالية من المعلومات غير الضرورية.

وبهذا يصبح الإشعار جزءًا من تجربة العميل وليس مجرد رسالة آلية.

الربط بين WhatsApp والمبيعات وخدمة العملاء

عندما يتم توسيع التكامل، يمكن النظر إلى WhatsApp باعتباره قناة ضمن منظومة المبيعات وخدمة العملاء، وليس مجرد وسيلة لإرسال إشعارات الطلب.

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

وجود البيانات داخل نظام مركزي يساعد الفريق على التعامل مع هذه الرحلة بصورة أكثر تنظيمًا.

وهنا يمكن أن يصبح استخدام Whats360 جزءًا من استراتيجية أكبر لإدارة محادثات WhatsApp وربطها بالعمليات التجارية، بدل حصر استخدامه في رسالة واحدة عند إنشاء الطلب.

من WooCommerce إلى أتمتة كاملة

القيمة الحقيقية لهذا التكامل لا تكمن في إرسال رسالة WhatsApp عند تغيير حالة الطلب فقط. هذه هي نقطة البداية.

القيمة تظهر عندما يتم تصميم الأحداث والبيانات والرسائل كمنظومة واحدة يمكن تطويرها مع نمو المتجر.

يمكن أن يبدأ المشروع بإشعار بسيط عند إنشاء الطلب، ثم يتوسع تدريجيًا إلى حالات الطلب، والشحن، والمخزون، والسلات المتروكة، وخدمة العملاء، وربط CRM أو أنظمة أخرى.

وبذلك تصبح الأتمتة وسيلة لتقليل العمل اليدوي وتحسين متابعة العملاء وربط قنوات التواصل بالعمليات التي تحدث داخل المتجر.

أسئلة شائعة حول ربط WooCommerce بـ Whats360

مقالات ذات صلة

شرح Whats360 API وربط الأنظمة

WooCommerce وWhatsApp: الأتمتة والإشعارات

ربط WhatsApp API مع WooCommerce

أتمتة WhatsApp وCRM

أتمتة متجر WooCommerce

الخلاصة

ربط WooCommerce بمنصة Whats360 عبر API يمكن أن يبدأ من سيناريو بسيط مثل إرسال رسالة تلقائية عند إنشاء الطلب أو تغيير حالته، ثم يتطور إلى منظومة أتمتة كاملة تربط المتجر بخدمة العملاء والمبيعات والمخزون والشحن والأنظمة الأخرى.

الأساس في نجاح المشروع هو تحديد الحدث المطلوب، والبيانات التي يحتاجها، والمستلم الصحيح، ونص الرسالة المناسب، ثم بناء Workflow واضح يمكن اختباره وتطويره.

أما البيانات الأساسية في نموذج الربط المعروض فتشمل Access Token وInstance ID ورقم الهاتف المستهدف، مع استخدام دالة مركزية للإرسال يمكن إعادة استخدامها في السيناريوهات المختلفة.

وعندما تتوسع احتياجات المتجر، يمكن تطوير نفس الفكرة لتشمل حالات إضافية مثل الطلبات الملغاة، فشل الدفع، الشحن، السلات المتروكة، تنبيهات المخزون، وربط WhatsApp مع أنظمة أخرى.

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