ElevenLabs تسلّم الدعم لوكيل ذكاء اصطناعي: 22 000 تذكرة شهريًا، 65% منها دون تدخل بشري
نقلت ElevenLabs دعمها الخاص إلى ElevenAgents، ويغلق الوكيل الآن أكثر من 22 000 طلب شهريًا. يقرأ الوكيل النصوص ولقطات الشاشة وملفات PDF، ويعمل داخل نظام التذاكر، ويطّلع على بيانات الحساب، وينفّذ الإجراءات، ويحيل الحالات المعقدة إلى الموظفين. خلال الشهر الأخير جرى حل 65% من التذاكر من البداية إلى النهاية. يصل الرد الأول خلال 60 ثانية بدلًا من عدة ساعات، وقيّم المستخدمون 70% من المحادثات تقييمًا إيجابيًا، وهي النسبة نفسها التي يحققها الموظفون البشر. • الخطوات الحرجة، مثل المبالغ المستردة، تمر عبر Structured Procedures • عمل الوكيل قبل الإطلاق في shadow mode على حركة بيانات حقيقية • تكشف simulation tests حالات التراجع في نحو 50 سيناريو شائعًا
معالج بواسطة الذكاء الاصطناعي من ElevenLabs Blog؛ بتحرير Hamidun News
تعالج ElevenLabs أكثر من 22 000 طلب شهريًا بمنتجها ElevenAgents. وهذا ليس عرضًا تجريبيًا للعملاء، بل خط الدعم الفعلي للشركة نفسها. وبحسب الفريق، أنهى الوكيل خلال الشهر الأخير 65% من التذاكر من البداية إلى النهاية. وانخفض متوسط زمن الرد الأول إلى 60 ثانية، بعدما كان يستغرق ساعات. وقيّم المستخدمون 70% من المحادثات التي أدارها الذكاء الاصطناعي تقييمًا إيجابيًا، وهذا يتطابق مع تقييم المشغّلين البشر.
يعمل الوكيل مع النصوص ولقطات الشاشة وملفات PDF، ومرتبط بمنصة التذاكر، ويدير مراسلات طويلة، ويبحث عن بيانات الحساب، وينفّذ الإجراءات، ويصعّد الحالات إلى الموظفين. وإذا كان الرقمان يعودان إلى الشهر نفسه، فإن إجمالي التذاكر نحو 34 ألف تذكرة (22 000 بنسبة 65%). هذا حسابنا نحن، وليس تصريحًا من الشركة.
SOP بوصفها الشيفرة المصدرية للوكيل
القرار الرئيسي للفريق مملّ، ولهذا السبب نجح. فقد كان لدى الدعم أصلًا إجراءات تشغيل قياسية مفصلة لكل فئة كبيرة: المبالغ المستردة، وتغييرات الفوترة، وأسئلة الاستنساخ الصوتي الاحترافي. وتلخصت المهمة الهندسية في تحويل هذه المعرفة إلى صيغة ينفّذها الوكيل بصورة يمكن التنبؤ بها. ولهذا احتاج الفريق إلى آليتين في ElevenAgents:
- Procedures تحوّل SOP إلى مسارات عمل قابلة للتكرار. وقد نُقلت أدلة الدعم (playbooks) لكل فئة رئيسية من التذاكر.
- Structured Procedures تُستخدم في العمليات الحرجة، مثل استرداد الأموال. وتُنفَّذ كل خطوة فيها بصورة حتمية، دون ارتجال حر من النموذج.
- Webhook tools تمنح الوكيل بيانات المستخدم الحية: خطة الاشتراك، واستهلاك الرصيد، والأصوات التي يملكها. وبدونها كان الوكيل سيكتفي بتقديم النصائح، أما معها فيحل المشكلة كاملة.
يمر الحد الفاصل بين النموذج المرن والإجراء الصارم عند النقطة التي يكلّف فيها الخطأ مالًا. فالنموذج يدير الحوار، بينما يتحكم السيناريو في إصدار المبلغ المسترد.
كيف جرى فحص الجودة قبل الإنتاج
قبل التشغيل، وبعد كل تغيير في الإعدادات، استخدم الفريق ثلاث أدوات:
- Channel behavior settings. مستخدم البريد الإلكتروني يريد ردًا بأقل عدد من الخطوات وبصيغة المراسلات المهنية. أما العميل الصوتي فيحتاج إلى حوار حي في الوقت الفعلي بعدد أكبر من الردود. ولكل قناة معيارها الخاص.
- Simulation tests. شغّل الفريق الوكيل على نحو 50 من أكثر سيناريوهات الدعم شيوعًا. بعد ذلك عدّل Architect، وهو أداة لبناء الوكلاء بلغة طبيعية، موجّه النظام (system prompt) والإجراءات إلى أن اجتازت الاختبارات بثبات. وتُعاد المجموعة بعد أي تعديل لتفادي حدوث تراجع في الأداء.
- Shadow mode. عمل الوكيل على حركة بيانات حقيقية داخل نظام التذاكر، لكن ردوده لم تكن تصل إلى العملاء. وحين ترسخت الثقة بجودة الردود، فُعّل في الإنتاج.
Architect أداةً لتحليل الأسباب
يستخدم موظفو الدعم Architect يوميًا لمعرفة المواضع التي يتعثر فيها الوكيل. فطلب واحد بلغة طبيعية يعطي توزيعًا للتذاكر حسب الفئات الرئيسية. ويمكن أيضًا السؤال عن سبب تحويل حالة معينة إلى موظف بشري. وقد يكون السبب ثغرة في قاعدة المعرفة، أو أداة غير موجودة، أو سياسة داخلية غير واضحة. وبعد تحديد السبب، يقترح Architect تعديلات.
وتمر التغييرات كذلك عبر Architect: فهو يصوغ التحديثات ويختبرها، ثم ينشئ simulation tests جديدة ويضيفها إلى المجموعة المشتركة. وبهذا تُفحص الإجراءات الجديدة فورًا، ولا تتعطل القديمة دون أن يلاحظ أحد. ويبقى البشر داخل الحلقة: فهم يوضحون احتياجات العملاء، ويحدّثون السياسات، ويتأكدون من أن الوكيل لم يُفرط في التكيّف مع نوع واحد من التذاكر. ويتولى Architect بقية المهام، ما يتيح للدعم مواكبة محفظة المنتجات المتوسعة.
ما الذي يمكن استخلاصه من هذه الحالة
يمكن نقل المخطط العام إلى أي فريق دعم:
1. ابدأوا بإجراءات SOP الموجودة للفئات الأعلى من الطلبات. وإذا لم تكن هناك إجراءات، فلا يوجد ما يمكن أتمتته بعد. 2. افصلوا الحوار الحر عن الإجراءات التي لا رجعة فيها. وصيغوا كل ما يتعلق بالمال وصلاحيات الوصول في صورة خطوات حتمية. 3. امنحوا الوكيل إمكانية الوصول إلى بيانات الحساب عبر الأدوات، وإلا فستصطدم نسبة التذاكر المحلولة بالكامل بسقف. 4. جمّعوا مجموعة من 30–50 سيناريو نموذجيًا، وشغّلوها بعد كل تعديل في الموجّه أو الإجراء. 5. شغّلوا الوكيل في الوضع الخفي على تدفق حي قبل عرض الردود على العملاء. 6. اعتمدوا إعدادات منفصلة للبريد والدردشة والصوت: فتوقعات كل قناة بشأن عدد الخطوات والنبرة مختلفة.
يدل التقييم البشري البالغ 70% على أن السرعة لم تُشترَ بثمن الجودة. لكن نسبة الحل الشامل البالغة 65% تعني أن ثلث التذاكر لا يزال يذهب إلى البشر، وهناك تحديدًا تمنح حالات التصعيد المادة اللازمة للنسخة التالية من الوكيل.
يُنشر هذا العرض في خضم سلسلة إصدارات من ElevenLabs حول منصة الوكلاء. ففي سبتمبر ظهر ElevenAgents على OpenAI Marketplace وEleven v4 Turbo داخل ElevenAgents، وفي أغسطس صدر ElevenLabs MCP لـ Claude. ويشكّل دعم الشركة نفسها واجهة عرض للمنصة.
أسئلة وأجوبة حول الخبر
ما أبرز التفاصيل حول SOP بوصفها الشيفرة المصدرية للوكيل؟
القرار الرئيسي للفريق مملّ، ولهذا السبب نجح. فقد كان لدى الدعم أصلًا إجراءات تشغيل قياسية مفصلة لكل فئة كبيرة: المبالغ المستردة، وتغييرات الفوترة، وأسئلة الاستنساخ الصوتي الاحترافي. وتلخصت المهمة الهندسية في تحويل هذه المعرفة إلى صيغة ينفّذها الوكيل بصورة يمكن التنبؤ بها. ولهذا احتاج الفريق إلى آليتين في ElevenAgents: Procedures تحوّل SOP إلى مسارات عمل قابلة للتكرار. وقد نُقلت أدلة الدعم (playbooks) لكل فئة رئيسية من التذاكر. Structured Procedures تُستخدم في العمليات الحرجة، مثل استرداد الأموال. وتُنفَّذ كل خطوة فيها بصورة حتمية، دون ارتجال حر من النموذج. Webhook tools تمن
ما أبرز التفاصيل حول كيف جرى فحص الجودة قبل الإنتاج؟
قبل التشغيل، وبعد كل تغيير في الإعدادات، استخدم الفريق ثلاث أدوات: Channel behavior settings. مستخدم البريد الإلكتروني يريد ردًا بأقل عدد من الخطوات وبصيغة المراسلات المهنية. أما العميل الصوتي فيحتاج إلى حوار حي في الوقت الفعلي بعدد أكبر من الردود. ولكل قناة معيارها الخاص. Simulation tests. شغّل الفريق الوكيل على نحو 50 من أكثر سيناريوهات الدعم شيوعًا. بعد ذلك عدّل Architect، وهو أداة لبناء الوكلاء بلغة طبيعية، موجّه النظام (system prompt) والإجراءات إلى أن اجتازت الاختبارات بثبات. وتُعاد المجموعة بعد أي تعديل لتفادي حدوث تراجع في الأداء. Shadow mode. عمل الوكيل على حركة بي
ما أبرز التفاصيل حول Architect أداةً لتحليل الأسباب؟
يستخدم موظفو الدعم Architect يوميًا لمعرفة المواضع التي يتعثر فيها الوكيل. فطلب واحد بلغة طبيعية يعطي توزيعًا للتذاكر حسب الفئات الرئيسية. ويمكن أيضًا السؤال عن سبب تحويل حالة معينة إلى موظف بشري. وقد يكون السبب ثغرة في قاعدة المعرفة، أو أداة غير موجودة، أو سياسة داخلية غير واضحة. وبعد تحديد السبب، يقترح Architect تعديلات. وتمر التغييرات كذلك عبر Architect: فهو يصوغ التحديثات ويختبرها، ثم ينشئ simulation tests جديدة ويضيفها إلى المجموعة المشتركة. وبهذا تُفحص الإجراءات الجديدة فورًا، ولا تتعطل القديمة دون أن يلاحظ أحد. ويبقى البشر داخل الحلقة: فهم يوضحون احتياجات العملاء، وي
Delegate Deep Research, Coding & Multi-Step Workflows to Nomad Agent
Deploy autonomous task execution with Nomad Agent (agent.nomadnet.ai) — automated web research, data synthesis, code generation, and MCP tool orchestration.
أهم ما في عالم الذكاء الاصطناعي — مرة كل أسبوع
سبع قصص مهمة فعلاً هذا الأسبوع، مختارة بعناية. بلا ضجيج ولا بيانات صحفية.
تم! تحقق من بريدك للتأكيد.