دليل Whats360 الشامل: API وWebhooks وإدارة الأجهزة والموظفين والـAI Chatbot والأتمتة

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

وهنا تظهر نقطة مهمة جدًا عند الحديث عن WhatsApp API: كلمة API لا تعني تلقائيًا حماية مطلقة من الحظر. الـAPI هو وسيلة تقنية لربط النظام بواتساب وتنفيذ العمليات البرمجية، بينما تظل سياسات واتساب وسلوك الحساب ونوع الرسائل والمحتوى وعوامل الاستخدام من الأمور التي يمكن أن تؤثر في استمرارية الحساب.

ما هي Whats360 وما الذي يمكن أن تفعله؟

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

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

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

هل WhatsApp API يعني الحماية من الحظر؟

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

استخدام API لا يعني أن هناك نظامًا يستطيع ضمان عدم حظر الرقم بنسبة 100%. قرار الحظر أو القيود يرتبط في النهاية بسياسات واتساب وطريقة استخدام الحساب وسلوك الإرسال وطبيعة المحتوى وعوامل أخرى خارج سيطرة أي منصة وسيطة.

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

بوابة المطورين وواجهة REST API

تقدم Whats360 واجهة REST API يمكن استخدامها من التطبيقات والأنظمة الخارجية لإدارة الأجهزة وإرسال أنواع مختلفة من الرسائل وإدارة الحملات.

المصادقة في طلبات API تعتمد على تمرير قيمة token ضمن رابط الطلب. الصيغة العامة تكون بالشكل التالي:

GET /api/v1/send-text?token=YOUR_TOKEN&instance_id=DEVICE_ID&...

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

إرسال الرسائل من خلال API

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

إرسال رسالة نصية

يمكن إرسال رسالة نصية من خلال:

GET /api/v1/send-text

المعاملات المطلوبة هي:

• token
• instance_id
• jid
• msg

مثال باستخدام cURL:

curl "https://whats360.live/api/v1/send-text?token=[TOKEN_ID]&instance_id=[DEVICE_ID]&jid=[PHONE_ID]@s.whatsapp.net&msg=Hello"

إرسال صورة

نقطة النهاية:

GET /api/v1/send-image

المعاملات المطلوبة هي token وinstance_id وjid وimageurl، مع إمكانية استخدام caption بشكل اختياري لإضافة وصف أو نص مصاحب للصورة.

إرسال فيديو

يمكن استخدام:

GET /api/v1/send-video

ويحتاج الطلب إلى token وinstance_id وjid وvideourl، مع إمكانية إضافة caption.

إرسال ملف صوتي

نقطة النهاية الخاصة بالصوت هي:

GET /api/v1/send-audio

وتستخدم المعاملات token وinstance_id وjid وaudiourl.

إرسال مستند

يمكن إرسال المستندات باستخدام:

GET /api/v1/send-doc

وتشمل المعاملات token وinstance_id وjid وdocurl، مع إمكانية إضافة caption.

إدارة أجهزة واتساب من خلال API

لا تقتصر الواجهة البرمجية على إرسال الرسائل، بل تشمل أيضًا مجموعة من العمليات المتعلقة بالأجهزة المرتبطة بالنظام.

عرض الأجهزة

GET /api/v1/instances

المعامل المطلوب هو token.

إنشاء جهاز جديد

GET /api/v1/instances/create

المعاملات المطلوبة هي token وid، ويمكن إضافة name بشكل اختياري.

مثال:

curl "https://whats360.live/api/v1/instances/create?token=[TOKEN_ID]&id=new-device&name=New+Device"

توصيل جهاز

GET /api/v1/instances/connect

يحتاج إلى token وinstance_id.

إيقاف جهاز

GET /api/v1/instances/disconnect

ويستخدم token وinstance_id.

معرفة حالة الجهاز

GET /api/v1/instances/status

وهو مفيد لمعرفة حالة جهاز محدد باستخدام instance_id.

الحصول على QR Code

يمكن جلب رمز QR بصيغة JSON عبر:

GET /api/v1/instances/qr

كما توجد صفحة QR تفاعلية يمكن فتحها مباشرة في المتصفح:

GET /api/v1/instances/qr-page

وتستخدم كلتا العمليتين token وinstance_id.

حذف جهاز

GET /api/v1/instances/delete

ويحتاج إلى token وinstance_id.

إدارة الحملات عبر API

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

عرض الحملات

GET /api/v1/campaigns

المعاملات هي token وinstance_id.

إنشاء حملة

POST /api/v1/campaigns/create

يتم إرسال token وinstance_id مع جسم الطلب بتنسيق JSON.

مثال:

curl -X POST "https://whats360.live/api/v1/campaigns/create?token=[TOKEN_ID]&instance_id=[DEVICE_ID]" \
-H "Content-Type: application/json" \
-d '{"name":"test","message_content":"Hello {{name}}"}'

إضافة المستلمين

POST /api/v1/campaigns/recipients

وتحتاج إلى token وinstance_id وcampaign_id، مع إرسال البيانات في جسم الطلب بصيغة JSON.

تشغيل الحملة

POST /api/v1/campaigns/start

وتستخدم token وinstance_id وcampaign_id.

مثال:

curl -X POST "https://whats360.live/api/v1/campaigns/start?token=[TOKEN_ID]&instance_id=[DEVICE_ID]&campaign_id=CAMPAIGN_ID"

إيقاف الحملة مؤقتًا واستئنافها

يمكن إيقاف الحملة مؤقتًا باستخدام:

POST /api/v1/campaigns/pause

ويمكن استئنافها باستخدام:

POST /api/v1/campaigns/resume

وفي الحالتين يتم تمرير token وinstance_id وcampaign_id.

إيقاف الحملة نهائيًا

POST /api/v1/campaigns/stop

وهو مخصص لإيقاف أو إلغاء الحملة.

متابعة حالة الحملة

GET /api/v1/campaigns/status

ويمكن من خلاله الحصول على حالة وإحصائيات الحملة.

حذف الحملة

POST /api/v1/campaigns/delete

مع تمرير token وinstance_id وcampaign_id.

كيف تتعامل مع Responses وأكواد الأخطاء؟

فهم استجابة API مهم جدًا عند بناء Integration مستقر. في حالة النجاح تكون الاستجابة وفق صيغة عامة مثل:

{
  "success": true,
  "message": "...",
  "response": { ... }
}

أما في حالة الخطأ فتكون الصيغة:

{
  "success": false,
  "error": "error message"
}

وهذا يسمح للتطبيق الخارجي بتمييز نجاح العملية عن فشلها ومعالجة الحالة بناءً على النتيجة.

الكود 400

يشير إلى أن الطلب غير صحيح، ومن الأسباب المحتملة وجود باراميتر مطلوب ناقص.

الكود 401

يشير إلى مشكلة في التوكن، مثل أن يكون غير صحيح أو منتهي الصلاحية.

الكود 403

يشير إلى الوصول إلى الحد الأقصى للرسائل أو الطلبات.

الكود 404

يشير إلى أن الجهاز المطلوب غير موجود.

الكود 463

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

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

الكود 500

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

Webhooks: كيف تتحول الرسائل إلى أحداث آلية؟

الـWebhook هو رابط URL يتم إرسال البيانات إليه تلقائيًا عند وقوع حدث محدد. وهذا يجعله أحد أهم مكونات الأتمتة لأن النظام الخارجي لا يحتاج إلى الاستعلام باستمرار عن وجود بيانات جديدة.

بدلًا من أن يسأل CRM كل دقيقة: هل وصلت رسالة جديدة؟ يمكن للمنصة إرسال الحدث مباشرة إلى رابط Webhook عند وصول الرسالة.

يمكن استخدام Webhooks في:

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

ربط Whats360 مع n8n

يمكن استخدام n8n لبناء Workflows آلية بين WhatsApp وخدمات أخرى. الفكرة الأساسية هي إنشاء Webhook في Whats360 ثم استخدام الرابط داخل Trigger من نوع Webhook في n8n.

بعد وصول الحدث، يمكن بناء سلسلة إجراءات، مثل حفظ البيانات في Google Sheets أو إرسال بريد إلكتروني أو تشغيل إجراء آخر في نظام خارجي.

بهذه الطريقة يصبح Webhook هو نقطة البداية، بينما يكون n8n هو محرك تنفيذ السيناريو.

ربط Shopify برسائل واتساب

يمكن استخدام Webhooks لربط متجر Shopify برسائل واتساب تلقائية. تبدأ العملية بإنشاء Webhook استقبال بيانات داخل Whats360 واختيار قالب Shopify، ثم نسخ رابط الاستقبال.

بعد ذلك يتم الدخول إلى إعدادات Shopify من خلال Settings ثم Notifications ثم Webhooks، وإنشاء Webhook جديد، واختيار الحدث المطلوب، ثم وضع رابط الاستقبال واختيار JSON كتنسيق للبيانات.

من الأحداث التي يمكن استخدامها:

• orders/create عند إنشاء طلب جديد.
• orders/updated عند تحديث الطلب.
• orders/paid عند دفع الطلب.
• customers/create عند تسجيل عميل جديد.

مثال مبسط على البيانات:

{
  "id": "[IDENTIFIER_ID]",
  "order_number": "[ORDER_ID]",
  "total_price": "199.00",
  "customer": {
    "first_name": "[PERSON_ID]",
    "phone": "[PHONE_ID]"
  }
}

وللتحقق من مصدر الطلبات، يمكن استخدام الهيدر X-Shopify-Hmac-SHA256 مع Secret عند إعداد Webhook.

ربط WooCommerce بواتساب

يمكن أيضًا ربط WooCommerce مع Whats360 لإرسال إشعارات واتساب عند إنشاء الطلب أو تغيير حالته.

بعد إنشاء Webhook من نوع Incoming واختيار قالب WooCommerce، يتم نسخ رابط الاستقبال ثم الدخول إلى WordPress من خلال WooCommerce ثم Settings ثم Advanced ثم Webhooks.

بعد الضغط على Add Webhook، يتم إدخال الاسم، وتفعيل الحالة، واختيار Topic، ثم وضع الرابط في Delivery URL وإدخال Secret نفسه المستخدم في المنصة.

من الأحداث المهمة:

• Order created.
• Order updated.
• Customer created.
• Product updated.

مثال على Payload:

{
  "id": "[IDENTIFIER_ID]",
  "status": "processing",
  "total": "150.00",
  "billing": {
    "first_name": "[PERSON_ID]",
    "phone": "[PHONE_ID]"
  }
}

وفي حالة حدوث مشكلة يمكن مراجعة سجلات التوصيل من WooCommerce ثم Status ثم Logs. كما يجب الانتباه إلى أن WooCommerce قد يعطل Webhook تلقائيًا بعد الفشل المتكرر، وأن نقطة النهاية يجب أن تعيد حالة 200 OK عند نجاح الاستقبال.

الـCustom Webhook بين الأنظمة

الـCustom Webhook يفتح مسارين مختلفين للتكامل.

Outgoing Webhook

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

يمكن تحديد URL الخدمة وإضافة Headers مخصصة مثل:

{
  "Authorization": "Bearer token"
}

ومن البيانات التي يمكن إرسالها:

• phone
• message
• sender_name
• instance_id
• timestamp
• chat_jid
• message_id
• media_url

Incoming Webhook

في المسار العكسي، يمكن استقبال بيانات من نظام خارجي ثم تحويلها إلى رسالة واتساب.

مثال:

POST /api/instances/{id}/webhooks/{webhook_id}/incoming
Content-Type: application/json

{
  "phone": "[PHONE_ID]",
  "message": "Your order #[ORDER_ID] is confirmed!",
  "name": "[PERSON_ID]"
}

والاستجابة الصحيحة المتوقعة:

{
  "status": "success",
  "message": "Webhook received successfully"
}

إعداد Webhook وإدارة إعادة المحاولة

عند إنشاء Webhook جديد يمكن تحديد الاسم ونوعه، سواء كان Outgoing أو Incoming، وإضافة URL وSecret اختياري للتحقق من مصدر الطلبات.

كما يمكن تحديد الأحداث التي يتم التعامل معها، مثل الرسائل الواردة والرسائل المرسلة وفشل الإرسال وانتهاء الاشتراك.

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

وتشمل المتغيرات المتاحة في Payload:

{{phone}}
{{message}}
{{sender_name}}
{{instance_id}}
{{timestamp}}
{{message_id}}
{{media_url}}
{{chat_jid}}

إدارة الموظفين والصلاحيات

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

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

بيانات الموظف

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

كما يمكن تحديد الأجهزة المخصصة للموظف وصناديق البريد التي يمكنه إدارتها.

الصلاحيات المتاحة

يمكن التحكم في مجموعة واسعة من الصلاحيات، ومنها:

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

ويمكن استخدام خيار تحديد الكل عند الحاجة، أو بناء صلاحيات دقيقة حسب الدور الوظيفي.

ساعات العمل وحدود المحادثات

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

مصادر البيانات الخارجية

مصادر البيانات الخارجية مصممة لعرض معلومات إضافية عن العميل أثناء المحادثة، بدلًا من إجبار الموظف على الانتقال إلى نظام آخر والبحث يدويًا عن البيانات.

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

إعداد نقطة نهاية خارجية

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

أهم إعداد هو URL Template، ويمكن أن يحتوي على المتغير:

{{phone}}

مثال:

https://api.example.com/lookup/{{phone}}

كما يمكن اختيار HTTP Method مثل GET أو POST، وتحديد Timeout، والقيمة الافتراضية له 10000 مللي ثانية، بالإضافة إلى Cache TTL الذي تكون قيمته الافتراضية صفرًا.

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

Response Mapping

بعد وصول الاستجابة من النظام الخارجي، يمكن استخدام Response Mapping لتحويل مسارات JSON إلى حقول مفهومة للموظف.

مثال:

{
  "الاسم": "data.name",
  "الرصيد": "data.balance"
}

كما يمكن تحديد حقول مخفية وإضافة Labels مخصصة وBoxes لتنظيم شكل المعلومات، بالإضافة إلى تحديد ترتيب العرض وتفعيل أو تعطيل نقطة النهاية.

تصميم Persona للمساعد الذكي

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

تعريف شخصية المساعد

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

تحديد المنتجات والخدمات

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

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

تحديد طريقة بدء الحوار

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

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

طريقة الإقناع ومعالجة الاعتراضات

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

القواعد الإلزامية

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

الإعدادات المتقدمة للمساعد الذكي

توفر Persona مجموعة إعدادات متقدمة تسمح ببناء سيناريوهات أكثر تعقيدًا.

Full Prompt

يمكن تجاوز بناء الـPrompt من المراحل المختلفة ووضع Prompt كامل وشامل ليستخدمه النظام مباشرة.

JSON Output Mode

عند تفعيل هذا الوضع، يمكن للنظام انتظار استجابة منظمة بصيغة JSON، مثل:

{
  "intent": "...",
  "botResponse": "...",
  "orderData": {},
  "telegramData": null
}

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

Media URLs

يمكن ربط النوايا والردود بروابط وسائط، مثل صور المنتجات أو الشهادات أو مواد أخرى.

مثال:

{
  "sending_testimonials_1": ["url1", "url2"],
  "sending_product_image": "url"
}

إشعارات Telegram

يمكن إدخال Telegram Bot Token المستخرج من BotFather وتحديد Chat IDs لتوجيه الإشعارات إلى أماكن مختلفة، مثل جروب الطلبات أو الإلغاءات أو المشاكل أو الجروب الافتراضي.

Few-Shot Training

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

إنشاء Chatbots للمحادثات التلقائية

إلى جانب Persona، يمكن إنشاء Chatbots ذات مسارات محددة للتعامل مع أنواع معينة من المحادثات.

توفر المنصة قوالب جاهزة تساعد على البدء بسرعة.

بوت الأسئلة الشائعة

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

بوت الاستبيان

يتكون من أربعة أسئلة لجمع آراء وتقييمات العملاء واستخدامها في تحسين الخدمة.

بوت حجز المواعيد

يحتوي على خمسة أسئلة لمساعدة العميل في تسجيل بيانات الحجز والوصول إلى الموعد المناسب.

بوت الدعم الفني

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

إعدادات إنشاء وتعديل Chatbot

يمكن تحديد اسم البوت وكلمة التشغيل Keyword Trigger التي تبدأ عندها المحادثة الآلية، مثل كلمة حجز، ثم ربط البوت بشخصية Persona محددة أو تشغيله بدون Persona.

رسائل البوت

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

السلوك والمهل الزمنية

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

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

التحويل إلى موظف بشري

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

Gemini API

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

Webhook Integration داخل البوت

يمكن أيضًا ربط البوت بنظام خارجي عبر Webhook لإرسال البيانات التي تم جمعها أثناء المحادثة تلقائيًا.

يمكن إدخال رابط Webhook وإضافة Headers بصيغة JSON، مثل:

{
  "Authorization": "Bearer token",
  "Content-Type": "application/json"
}

وبذلك يصبح البوت نقطة جمع بيانات يمكن أن تتصل مباشرة بنظام آخر بدل أن تبقى المعلومات داخل المحادثة فقط.

كيف تتكامل مكونات Whats360 معًا؟

القوة الحقيقية تظهر عندما يتم استخدام المكونات كمنظومة واحدة.

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

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

متى تحتاج إلى API ومتى تحتاج إلى Webhook؟

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

الأداة	الوظيفة	مثال
API	تنفيذ عملية من النظام الخارجي	إرسال رسالة واتساب
Webhook	إشعار النظام الخارجي بحدث	إبلاغ CRM بوصول رسالة
Chatbot	إدارة مسار محادثة تلقائي	جمع بيانات حجز
Persona	توجيه أسلوب وسياق الذكاء الاصطناعي	مساعد مبيعات
مصدر بيانات خارجي	جلب معلومات من نظام آخر	عرض بيانات العميل بالهاتف

كيف تختار المكونات المناسبة لسيناريو عملك؟

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

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

إذا كان الهدف هو الرد الآلي، فـChatbot وPersona هما المكونان الأكثر ارتباطًا بهذا الاستخدام.

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

وفي المشاريع التي تجمع أكثر من احتياج، يمكن دمج هذه المكونات في Workflow واحد بدل التعامل مع كل وظيفة بمعزل عن الأخرى.

ما الذي يحتاجه المطور قبل بدء التكامل؟

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

بعد ذلك ينبغي تصميم طبقة Integration مستقلة نسبيًا عن واجهة المستخدم، حتى لا تصبح بيانات المصادقة أو منطق API مكشوفًا داخل Frontend.

كما ينبغي التعامل مع HTTP Status Codes وحقول success وerror بطريقة واضحة، بحيث يعرف النظام هل يعيد المحاولة أم يعرض الخطأ أم يطلب إجراءً من المستخدم.

ما الذي يحتاجه صاحب النشاط التجاري؟

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

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

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

أسئلة شائعة حول Whats360

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

شرح Whats360 API

WhatsApp API وWebhooks

WhatsApp CRM والأتمتة

WhatsApp Chatbot والذكاء الاصطناعي

الخلاصة

منصة Whats360 يمكن فهمها كمنظومة متكاملة وليست مجرد Endpoint لإرسال رسالة. الطبقة البرمجية توفر API لإدارة الأجهزة والرسائل والحملات، بينما توفر Webhooks قناة للأحداث والتكامل مع الأنظمة الخارجية.

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

أما طبقة الذكاء الاصطناعي فتضيف إمكانية تصميم Persona متخصصة وبناء Chatbots بمسارات محددة، مع إمكانية استخدام JSON Output وMedia URLs وFew-Shot Training والتكامل مع Webhooks.

وعند جمع هذه المكونات معًا، يمكن بناء Workflow يبدأ من حدث داخل متجر أو نظام، ويمر عبر Webhook أو API، ثم يتفاعل مع العميل عبر واتساب، ويستخدم بياناته من نظام خارجي، ويوجه المحادثة إلى بوت أو مساعد ذكي، ثم يحولها إلى موظف عند الحاجة.

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