بناء WhatsApp Bot وذكاء اصطناعي مخصص باستخدام Whats360 API وGemini

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

ما الذي تحتاجه لبناء WhatsApp Bot مخصص؟

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

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

معمارية WhatsApp Bot الحديثة

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

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

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

ما هو Outgoing Webhook؟

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

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

شكل البيانات الواردة

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

{
  "event": "message.received",
  "sender": "CUSTOMER_PHONE",
  "message": "CUSTOMER_MESSAGE",
  "conversation_id": "CONVERSATION_ID"
}

القيم السابقة أمثلة عامة وليست بديلاً عن Payload الفعلي الذي يوفره إصدار الـ API المستخدم.

بناء Backend باستخدام Node.js

يُستخدم Node.js على نطاق واسع في تطبيقات المحادثة لأنه مناسب للتعامل مع طلبات HTTP والأحداث والاتصالات الخارجية. لكن اختيار التقنية ليس الهدف الأساسي؛ المهم أن يكون الخادم قادراً على استقبال الـ Webhook والتحقق منه، ثم تنفيذ منطق النظام بشكل منظم.

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

import express from "express";

const app = express();

app.use(express.json());

app.post("/webhook/whatsapp", async (req, res) => {
  const event = req.body;

  // Validate the incoming event
  // Process the conversation
  // Execute business logic
  // Send the appropriate response

  res.sendStatus(200);
});

app.listen(process.env.PORT || 3000);

المثال يوضح الهيكل فقط، ولا يتضمن أي مفتاح API أو Token حقيقي.

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

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

const WHATS360_API_TOKEN = process.env.WHATS360_API_TOKEN;

async function sendWhatsAppMessage(phone, message) {
  // Call the documented Whats360 sending endpoint
  // using WHATS360_API_TOKEN from the environment.
}

بهذه الطريقة يمكن تغيير Endpoint أو آلية المصادقة لاحقاً من مكان واحد، كما يمكن إضافة Logging ومعالجة الأخطاء وإعادة المحاولة دون تكرار الكود.

Router: كيف يحدد النظام ما الذي يريده العميل؟

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

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

const routes = {
  order_status: handleOrderStatus,
  booking: handleBooking,
  pricing: handlePricing,
  human_support: transferToHuman
};

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

أين يدخل Gemini في النظام؟

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

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

مثال على استخراج البيانات

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

{
  "intent": "booking",
  "date": "REQUESTED_DATE",
  "time": "REQUESTED_TIME",
  "party_size": "REQUESTED_PARTY_SIZE"
}

بعد ذلك يجب التحقق من توفر الموعد من المصدر الحقيقي قبل تأكيد الحجز للعميل.

الفصل بين AI ومنطق الأعمال

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

إذا كان العميل يريد إلغاء طلب، فلا يكفي أن يفهم النموذج كلمة “إلغاء”. يجب أن يعرف النظام هل الطلب موجود؟ هل يمكن إلغاؤه؟ هل تجاوز مرحلة تسمح بالإلغاء؟ هل توجد صلاحية للعميل؟ وهل توجد رسوم أو شروط مرتبطة بالإلغاء؟

الحجز وتنفيذ الإجراءات الحقيقية

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

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

إدارة الجلسات والـ Database

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

لهذا تحتاج المنظومة إلى Session أو Conversation State. يمكن حفظ الحالة في قاعدة بيانات مناسبة أو طبقة تخزين مؤقتة بحسب طبيعة النظام وحجم الاستخدام.

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

{
  "conversation_id": "CONVERSATION_ID",
  "intent": "booking",
  "state": "waiting_for_date",
  "customer_id": "CUSTOMER_ID",
  "collected_data": {
    "name": "CUSTOMER_NAME"
  }
}

المعرفات في المثال عامة ومقصودة لتوضيح البنية فقط.

Multi-Agent في المشاريع الكبيرة

عندما يكبر المشروع، قد لا يكون من المناسب وضع كل المهام داخل Agent واحد. يمكن تقسيم المسؤوليات إلى Agents أو خدمات متخصصة بحسب طبيعة النظام.

قد يوجد Agent لفهم الرسائل، وآخر لخدمة العملاء، وخدمة متخصصة للحجوزات، وأخرى للطلبات، مع وجود طبقة Orchestrator تحدد المسار المناسب.

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

تشغيل النظام على VPS

عند تحويل البوت إلى Production، تحتاج إلى بيئة تشغيل مستقرة. يمكن تشغيل Backend على VPS أو بيئة سحابية مناسبة، مع إعداد HTTPS، وإدارة متغيرات البيئة، ومراقبة الأخطاء، والنسخ الاحتياطي، وتسجيل الأحداث.

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

Dashboard أم API Bot؟

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

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

بناء WhatsApp AI Automation Workflow

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

كيف تعمل الأتمتة من الرسالة حتى النتيجة؟

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

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

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

ثم تأتي Business Logic، وهي المرحلة التي تتعامل مع النظام الحقيقي. بعدها يتم تسجيل النتيجة، ثم صياغة الرد وإرساله للعميل.

معالجة الأخطاء والردود غير الصالحة

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

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

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

الأمان في WhatsApp Bot

الأمان لا يقتصر على إخفاء API Key. يجب حماية الـ Webhook، وعدم قبول أوامر حساسة من أي مصدر غير موثوق، والتحقق من المدخلات، وإدارة الصلاحيات، وعدم تسجيل البيانات السرية داخل Logs بصورة مكشوفة.

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

const config = {
  whats360Token: process.env.WHATS360_API_TOKEN,
  geminiKey: process.env.GEMINI_API_KEY
};

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

اختبار البوت قبل إطلاقه

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

لماذا لا يكفي ربط Gemini مباشرة بواتساب؟

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

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

ربط البوت مع CRM أو ERP

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

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

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

متى يكون بناء Bot مخصص مناسباً؟

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

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

خريطة عملية لبناء النظام

الفرق بين Bot بسيط وAI Bot مخصص

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

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

الخلاصة

بناء WhatsApp Bot احترافي باستخدام Whats360 وGemini API لا يتوقف عند استقبال الرسالة وإرسال رد آلي. البنية الأقوى هي التي تفصل قناة الاتصال عن الـ Backend، وتفصل الذكاء الاصطناعي عن منطق الأعمال، وتحفظ حالة المحادثة، وتتحقق من البيانات قبل تنفيذ الإجراءات.

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

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

مقالات عن WhatsApp API

مقالات عن WhatsApp Bot

مقالات عن AI Automation

مقالات عن Gemini API

مقالات عن CRM Automation

مقالات عن Affiliate Marketing

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

الكلمات المفتاحية