يقدّم Meta Business Agent وعداً كبيراً: وكيل ذكاء اصطناعي يجيب عن أسئلة العملاء، ويوصي بالمنتجات، ويؤهل العملاء المحتملين، ويحجز المواعيد، وينفذ الإجراءات، ويسلّم المحادثة إلى موظف عند الحاجة. طرحت Meta المنتج عالمياً في يونيو 2026، وقدّمت أيضاً منصة للشركات التي تريد إعداد الوكيل عبر أنظمتها المؤسسية.
السؤال التشغيلي ليس فقط: «هل يستطيع الوكيل الإجابة؟» بل: «هل رقم WhatsApp هذا مؤهل، وما الذي يجوز للوكيل امتلاكه، وماذا يحدث عندما يجب أن تنتقل الملكية؟»
هذا الفرق مهم لأن إعلان المنتج ومسار التنفيذ يصفان طبقتين مختلفتين. يغطي إعلان الإطلاق من Meta تجارب موجّهة للشركات عبر WhatsApp وMessenger وInstagram. أما وثائق منصة Meta Business Agent فتشرح مسار WhatsApp Business Platform: وكيل مؤسسي يمكن أن يصبح المستجيب الأساسي، ويجيب استناداً إلى معرفة الشركة المعتمدة، ويستدعي واجهات API الخاصة بها، وينقل التحكم إلى تطبيق.
يحوّل هذا الدليل تلك القدرات إلى خريطة أهلية وملكية يستطيع فريق عمليات العملاء استخدامها قبل تفعيل الوكيل.
1. ابدأ بسطح المنتج الصحيح
لا تبدأ بكتابة التعليمات. ابدأ بتسمية بيئة التشغيل.
تصف Meta تجارب Business Agent للشركات الأصغر داخل تطبيقاتها، ومنصة Business Agent للنشر المؤسسي. يركز هذا المقال على مسار المنصة لرقم WhatsApp Business تتم إدارته عبر Cloud API، بما في ذلك الأرقام المتصلة من خلال مزود حلول أعمال أو Embedded Signup.
اكتب هذه المعرّفات الخمسة في أعلى موجز المشروع:
- محفظة الأعمال المالكة؛
- حساب WhatsApp Business؛
- رقم الهاتف؛
- تطبيق Meta ومستخدم النظام اللذان سيديران التكامل؛
- التطبيق أو الفريق الذي يجب أن يتلقى التحكم بعد التسليم.
إذا لم يستطع الفريق تسمية العناصر الخمسة كلها، فهو غير جاهز لتعريف سلوك الوكيل. ما زال يحسم ملكية النظام.
2. اجتز بوابة أهلية رقم الهاتف
عبارة «متاح عالمياً» لا تعني أن كل رقم قابل للتفعيل. تنص وثائق مطوري Meta، المحدثة في 22 يوليو 2026، على أن الرقم يجب أن يستوفي عدة شروط قبل استخدام Meta Business Agent.
استخدم قائمة التحقق التالية:
- قطاع مدعوم: تستثني Meta حالياً قطاعات التمويل والحكومة والصحة والكحول والمقامرة والأدوية المتاحة من دون وصفة وخدمات الزواج من Business Agent Platform. كما يحتاج الحساب إلى فئة أعمال صحيحة.
- نموذج تشغيل صحيح: يجب إدارة الرقم من خلال WhatsApp Business Platform وCloud API، وليس عبر تطبيق WhatsApp Business وحده.
- وضع سليم: يجب ألا يكون حساب WhatsApp Business أو الشركة المالكة له مقيّداً أو محظوراً.
- بلد مؤهل: تحدد الأهلية وفق بلد الشركة المرتبطة بالحساب. تحقّق من الرقم المحدد عبر نقطة الأهلية لدى Meta.
- الثقة والتحقق: يجب أن تستوفي الشركة متطلبات Meta السارية للثقة والتحقق.
- عدم وجود منتج مراسلة متعارض: لا يمكن لرقم واحد تشغيل أكثر من منتج مراسلة متعارض في الوقت نفسه.
تعامل مع نتيجة الأهلية كتبعية للنشر، لا كتفصيل إداري. سجّل النتيجة والتاريخ وأصل الأعمال والشخص الذي أجرى الفحص. أعد الفحص بعد نقل الرقم، أو تغيير محفظة الأعمال، أو فرض قيد، أو إجراء تغيير جوهري في الإعداد.
إذا فشلت الأهلية، أوقف موضوع Business Agent عند هذه النقطة. لا تصمم حلاً التفافياً يغيّر فئة الشركة أو ملكيتها أو حالة المنتج لمجرد اجتياز الفحص.
3. ارسم خريطة الملكية قبل مسار المحادثة
تقول Meta إن وكيل المنصة يعمل بصفته المستجيب الأساسي بعد تفعيله. لذلك تصبح الملكية قرار التصميم المركزي.
أنشئ خريطة بسيطة من خمس حالات:
| الحالة | المالك الحالي | الدليل المطلوب | المالك الآمن التالي | | --- | --- | --- | --- | | محادثة جديدة | Meta Business Agent | رسالة العميل وهوية القناة | الوكيل أو التطبيق | | إجابة معتمدة | Meta Business Agent | مصدر حديث وسياسة الإجابة | الوكيل | | إجراء تجاري | Meta Business Agent مع API للشركة | مدخلات متحقق منها وإجراء مسموح | الوكيل أو التطبيق | | طلب تسليم | عملية النقل | السبب والسجل والحقول الملتقطة والأولوية | فريق أو شخص مسمى | | عمل بشري نشط | عضو الفريق | إسناد ظاهر وحالة الأتمتة | عضو الفريق أو عودة مقصودة |
يجب أن توضح الخريطة قاعدة واحدة: لا يجوز أن تنتقل المحادثة من «يملكها الوكيل» إلى «لا يملكها أحد».
لكل محفز تسليم، عرّف:
- الحدث الدقيق الذي يطلب النقل؛
- السياق الذي ينتقل مع المحادثة؛
- قائمة الانتظار التي تستقبلها؛
- ما سيقال للعميل؛
- ما يحدث خارج ساعات العمل؛
- هل تتوقف الردود الآلية؛
- من يملك إعادة التحكم إلى الوكيل.
هنا تصبح علبة وارد الفريق المشتركة مهمة تشغيلياً. السؤال المفيد ليس ما إذا كان هناك زر للتسليم، بل هل يستطيع الموظف المستلم رؤية العميل والمحادثة السابقة وسبب النقل والمالك الحالي والإجراء التالي من دون أن يطلب من العميل البدء من جديد.
4. افصل بين المعرفة والقرارات والإجراءات
قد يكون الوكيل دقيقاً في الإجابات وغير آمن في تنفيذ الإجراءات. صمّم ثلاثة حدود منفصلة.
حدود المعرفة
أدرج المصادر التي يجوز للوكيل استخدامها، ومالكيها، وتواريخ مراجعتها. افصل بين:
- حقائق المنتجات والخدمات؛
- الأسعار والشروط التجارية؛
- السياسات التشغيلية؛
- العبارات القانونية أو المنظمة؛
- المعلومات المؤقتة مثل التوفر أو مواعيد التسليم.
حدد ما يجب أن يفعله الوكيل عندما تتعارض المصادر أو تكون ناقصة أو منتهية الصلاحية. «اسأل موظفاً» نتيجة صحيحة. اختراع حل وسط بين وثيقتين متعارضتين ليس كذلك.
حدود القرار
حدد الأحكام التي يجوز للوكيل اتخاذها من المحادثة. قد يصنّف النية، أو يجمع الحقول المطلوبة، أو يحدد الحاجة إلى موظف. يجب أن يكون للقرار سبب ظاهر وخيار احتياطي آمن.
حدود الإجراء
اكتب كل إجراء متصل كصلاحية، لا كقدرة عامة. عبارة «الوصول إلى الطلبات» غامضة. قسّمها إلى:
- قراءة حالة الطلب؛
- تغيير تفضيل التسليم؛
- إلغاء طلب؛
- إنشاء طلب استرداد؛
- إصدار استرداد.
ابدأ بإجراءات القراءة فقط. أضف إجراءات الكتابة القابلة للعكس بعد اختبار المدخلات والتفويض وصيغة التأكيد والتعامل مع التكرار وحالة الفشل وسجل التدقيق. أبقِ الإجراءات عالية التأثير أو غير القابلة للعكس خلف موافقة بشرية.
تتبع مساحة الذكاء الاصطناعي في DripTell الفصل العملي نفسه: معرفة معتمدة، ثم نية وسياق ملتقطان، ثم استلام بشري ظاهر عندما يكون الحكم مطلوباً. الهدف ليس إضافة روبوت آخر، بل إبقاء الإجابة وسجل العميل وقرار الملكية ضمن العملية نفسها.
5. صمّم التسليم كنقل للتحكم
رسالة التعذر ليست تسليماً. يكتمل التسليم فقط عندما يتلقى مالك مسؤول آخر التحكم.
استخدم عقد تسليم من ستة حقول:
- السبب: لماذا لا يستطيع الوكيل أو لا ينبغي له الاستمرار.
- الملخص: ما الذي يريده العميل وما الذي حدث بالفعل.
- الدليل: الرسائل أو المصدر أو نتيجة الأداة أو السياسة التي أدت إلى النقل.
- البيانات الملتقطة: المعرّفات والحقول المتحقق منها، منفصلة عن الافتراضات.
- الوجهة: قائمة الانتظار أو الفريق أو الشخص المسمى.
- حالة الأتمتة: ما الذي توقف مؤقتاً أو أُلغي أو ما زال مسموحاً بتشغيله.
اختبر الاتجاهين. يجب أن يعمل النقل من الوكيل إلى التطبيق، ويجب أن يمتلك الفريق قاعدة صريحة تحدد إمكان إعادة التحكم إلى الوكيل. قد تؤدي العودة الآلية الصامتة إلى تحدث الوكيل فوق محادثة بشرية جارية.
استخدم أتمتة رحلة العميل لإظهار التوجيه والإسناد والتوقفات وشروط الإنهاء. متطلب المنتج المهم ليس طول قائمة المحفزات، بل القدرة على تفسير من كان يملك المحادثة في كل خطوة.
6. نفّذ اختبارات تبدأ بالفشل قبل تفعيل الرقم
تضع وثائق منصة Meta الاختبار والتقييم ضمن القدرات الأساسية. ابنِ مجموعة الاختبار من حالات الفشل التشغيلية، لا من العروض المثالية فقط.
اختبر على الأقل:
- سؤالاً عادياً له إجابة واحدة حديثة ومعتمدة؛
- سؤالاً لا تملك قاعدة المعرفة إجابة عنه؛
- مصدرين معتمدين متعارضين؛
- طلب إجراء يستطيع الوكيل القراءة عنه ولا يجوز له تنفيذه؛
- إجراءً صالحاً مع تعطل API التابعة؛
- طلب إجراء مكرر بعد انتهاء المهلة؛
- عميلاً يطلب صراحة موظفاً؛
- محادثة حساسة أو غاضبة أو ملتبسة تحتاج إلى حكم؛
- تسليماً خارج ساعات العمل؛
- محادثة بكل لغة وأسلوب كتابة يدعمهما الفريق فعلياً.
لكل حالة، سجّل المالك المتوقع والإجابة المسموحة والإجراء المحظور والوجهة والرسالة الموجهة إلى العميل. ينجح الاختبار فقط عندما تكون الحالة الناتجة صحيحة. الجملة السلسة مع المالك الخطأ ما تزال فشلاً.
7. قِس طبقة التحكم، لا سرعة الرد وحدها
الرد السريع مفيد، لكنه لا يثبت أن العملية مضبوطة.
تابع مجموعة موجزة من المؤشرات:
- حالة فحص الأهلية وتاريخ آخر تحقق؛
- دقة الإجابة مقارنة بالمصدر المعتمد؛
- معدل الإجابات غير المسندة؛
- نجاح الإجراءات وفشلها ومنع تكرارها؛
- معدل اكتمال التسليم؛
- الوقت الذي تقضيه المحادثة بلا مالك ظاهر؛
- تكرار العميل للمعلومات بعد التسليم؛
- تدخل البشر وعكس الإجراءات؛
- الحل والتحويل في المسارات التي يملكها الوكيل أو الإنسان.
راجع الأمثلة وراء الأرقام. قد يعني انخفاض معدل التسليم أتمتة ممتازة، أو قد يعني أن العملاء لا يستطيعون الوصول إلى موظف. ارتفاع معدل الاحتواء ليس نتيجة جيدة تلقائياً.
8. قرر ما الذي يحيط بوكيل Meta
قد يكون Meta Business Agent المستجيب الأساسي المناسب لرقم WhatsApp، لكن نموذج التشغيل المحيط به ما يزال يحتاج إلى قرارات مقصودة.
اسأل:
- هل يحتاج عدة أشخاص أو فرق إلى قائمة انتظار مشتركة وإسناد ظاهر؟
- هل يجب أن يبقى سجل WhatsApp بجوار Instagram وMessenger وTelegram أو قناة أخرى مدعومة؟
- هل يجب أن تحدّث الإجابات الملتقطة سجلاً موحداً للعميل والفرصة؟
- هل ينبغي للردود بدء مسارات أوسع أو إيقافها مؤقتاً أو إنهاؤها؟
- هل يحتاج الفريق إلى ملاحظات داخلية وصلاحيات وسجل تدقيق؟
- هل سيقارن المديرون نتائج المسارات التي يملكها الوكيل أو الإنسان؟
إذا كانت معظم الإجابات «لا»، فأبقِ نموذج التشغيل بسيطاً. وإذا كانت عدة إجابات «نعم»، فقيّم مساحة محادثات العملاء المحيطة بالوكيل بالدقة نفسها. لا تفترض أن الوكيل الأصلي يحل تلقائياً ملكية العمل بين الفرق أو حالة CRM أو استمرارية القنوات؛ تحقّق من كل مهمة مطلوبة في المعمارية المختارة.
يربط DripTell بين علبة وارد الفريق والذكاء الاصطناعي والمعرفة المعتمدة وأتمتة سير العمل وسجلات العملاء والعملاء المحتملين. لذلك يفيد الفرق التي تقيّم العملية المحيطة بالمحادثات المدعومة بالذكاء الاصطناعي. هذا لا يعني وجود تكامل غير متحقق منه مع Meta Business Agent؛ أكّد مسار التكامل وملكية الرقم بدقة أثناء تصميم الحل.
اجتماع تمهيدي في 30 دقيقة
قبل أي جلسة بناء، اجمع مالك WhatsApp وقائد عمليات العملاء ومالك التكامل ومدير الفريق المستلم.
استخدم الاجتماع لإنتاج أربعة مستندات:
- سجل أهلية رقم الهاتف؛
- خريطة الملكية ذات الحالات الخمس؛
- قائمة حدود المعرفة والقرار والإجراء؛
- عشر حالات اختبار تبدأ بالفشل مع مالك متوقع ومسمى لكل حالة.
إذا خرج الفريق بهذه العناصر الأربعة، يمكن للتنفيذ أن يبدأ ضمن قيود واضحة. أما إذا خرج بتعليمات وقائمة مزايا فقط، فستبقى القرارات الأعلى خطراً بلا حل.
القرار العملي
Meta Business Agent ليس مجرد مولّد إجابات جديد. في مسار المنصة يمكنه أن يصبح المستجيب الأساسي، ويستخدم معرفة الشركة، ويستدعي الإجراءات المتصلة، وينقل التحكم. لذلك تصبح الأهلية والملكية جزءاً من تصميم المنتج.
تحقق من الرقم أولاً. ثم حدد ما يعرفه الوكيل وما يقرره وما يفعله وما يسلّمه. وأخيراً، أثبت كل تغيير في الملكية تحت ظروف الفشل.
إذا أردت رسم نموذج التشغيل عبر الذكاء الاصطناعي وعلبة وارد مشتركة والأتمتة وCRM، احجز عرضاً توضيحياً من DripTell مستخدماً رحلة عميل حقيقية. أحضر خريطة الحالات الخمس واختبارات الفشل؛ ستكشفان أكثر مما يكشفه نص روبوت مصقول.
DripTell Editorial
إرشادات عملية راجعها فريق المنتج وتجربة العملاء في DripTell.
تعرّف على كيفية التحقق من معلومات المنتج واستخدام المصادر الرسمية وتصحيح الأخطاء.
سياسة التحرير والمصادر