إذا كنت قد استخدمت موظف الذكاء الاصطناعي في زينديسك، فمن المحتمل أنك واجهت نفس الحائط الذي يواجهه كل عميل لدينا في النهاية: وكيل عام يحاول الاحتفاظ بكل قاعدة، وكل حالة خاصة، وكل "إذا كان هذا، فإن ذلك" في موجه واحد. إنه يعمل بالنسبة لـ 70% السهلة. ثم يأتي فحص الضمان مع صورة مرفقة، أو استرداد يحتاج إلى التحقق من الفوترة و السياسة و معايير التصعيد، ويخمن الوكيل إما أو يتخلى إلى إنسان.
إجابة زينديسك، التي يتم طرحها بهدوء في الوصول المبكر، هي وكلاء مخصصون. وهي أقل من ميزة وأكثر من تحول في كيفية بناء أتمتة الدعم.
الفكرة الأساسية
بدلاً من وجود وكيل ذكاء اصطناعي يحاول أن يكون كل شيء، تقوم ببناء وكلاء متخصصين، محددين بالمهام، كل واحد منها محدد بالطريقة التي ستحدد بها وصف وظيفة موظف جديد، وليس شخصية روبوت الدردشة.
كل وكيل مخصص يحصل على:
- إجراء بلغة بسيطة: الخطوات الفعلية، مكتوبة بالطريقة التي ستقوم بها بإحاطة ممثل الدعم المبتدئ، وليس جدار من هندسة الموجهات
- مقالات قاعدة المعرفة المعتمدة: يسمح له بالإشارة إلى لا شيء خارج هذا النطاق
- الوصول إلى إجراءات محددة، وتدفقات الإجراءات، ووكلاء مخصصين آخرين: يقوم بعمله ولا شيء أكثر
- مدخلات ومخرجات محددة: حتى يتمكن من تسليم المهمة بسلاسة إلى الوكيل التالي في السلسلة
النتيجة العملية: بدلاً من نموذج واحد يحاول الاحتفاظ بسياسة الدعم الخاصة بك بالكامل في ذهنه، تحصل على فريق من المتخصصين، كل واحد قابل للاختبار، قابل للإصلاح، وقابل للاستبدال بمفرده.
أين يكون هذا مفيدًا فعلاً
هذا ليس "شيئًا جيدًا أن يكون موجودًا" لتوجيه الأسئلة الشائعة. إنه مصمم للعملية التي تكسر إعدادات الوكيل الفردي:
- التحقق من الضمان والمنتج: يفتح الوكيل صورة مرفقة، ويسحب رقم السيريال واسم المنتج مباشرة منها، ويحقق من نظامك. لا يوجد وكيل يكتب رقم السيريال من صورة ملصق بعد الآن.
- منطق استرداد متعدد الخطوات: يتحقق وكيل واحد من قواعد الفوترة، ويسلم إلى آخر يتحقق من السياسة، الذي يسلم إلى ثالث إذا تم استيفاء معايير التصعيد.
- معالجة التصعيد: للحالات التي لا يمكن لتدفق الفرز الخاص بك حلها بمفرده.
- استكشاف الأخطاء المعقدة: مقسمة إلى خطوات صغيرة قابلة للاختبار بدلاً من مطالبة واحدة شاملة تحاول تغطية كل فرع.
لقد كنا نختبر هذا داخل بيئة Zendesk Practice، بما في ذلك وكيل مخصص يقرأ صورة مرفقة، ويستخرج المنتج ورقم السيريال، ويضع كلاهما مباشرة في التذكرة. تعليق أو حقول، الخيار لك. إنها حالة استخدام صغيرة على الورق. في الممارسة العملية، تزيل فئة كاملة من إدخال البيانات اليدوي من يوم الوكيل.
لماذا نموذج "فريق المتخصصين" أكثر أهمية من الميزة نفسها
العملاء المحددون أسهل في البناء لأنك لا تحاول توقع كل سيناريو في تدفق واحد. إنها أسهل في الاختبار لأن لكل واحد مدخلات ومخرجات محددة ومجموعة ضيقة من الأشياء المسموح بها. وعندما يحدث خطأ، فإنك تقوم بإصلاح وكيل صغير واحد وليس فك تشابك مطالبة ضخمة للعثور على القاعدة التي لا تعمل.
السلسلة هي الافتتاحية الحقيقية. يمكن لوكلاء مخصصين استدعاء وكلاء مخصصين آخرين، مما يعني أنه يمكنك بناء سير عمل سيكون من الصعب جدًا الاحتفاظ به داخل تدفق وكيل ذكاء اصطناعي واحد اليوم. هذه هي الفجوة بين "الذكاء الاصطناعي الذي يجيب على التذاكر" و"الذكاء الاصطناعي الذي يدير عملية."
رأينا
هذا لا يزال وصولًا مبكرًا، توقع أن تتغير الوظائف والحدود قبل التوفر العام. ولكن إذا كنت بالفعل تستخدم وكيل ذكاء اصطناعي من Zendesk وتصل إلى الحد الأقصى لما يمكن لوكيل واحد تحمله بشكل معقول، فإن هذا هو الاتجاه الذي يستحق المتابعة، ويستحق التخطيط له الآن بدلاً من لاحقًا.
في OxtonGrid، هذا هو بالضبط نوع التحول الذي نبني حوله: رسم خرائط عمليات الدعم الفعلية الخاصة بك - فحوصات الضمان، منطق الاسترداد، مسارات التصعيد - إلى أتمتة محددة وقابلة للاختبار بدلاً من أن يحاول وكيل واحد تخمين طريقه عبر كل ذلك.
تحول رقمي منطقي. حتى عندما تصبح الأدوات أكثر تعقيدًا.