مثال تطبيقي. هذا مثال تطبيقي توضيحي وليس نتيجة عميل: فريق الدعم وأرقامه افتراضات. يوضح الاسترجاع من جهة الوكيل، وهو أداة تقف خلف وكيل الدعم لا أمام العميل. يسأل الوكيل بلغة بسيطة ويحصل على إجابة موثّقة بالمصدر، ويبقى داخل التذكرة ويرسل الرد بنفسه.
تخيّل فريق CX لتجارة إلكترونية متوسطة الحجم يريد تحسين زمن الرد الأول على التذاكر المعقدة. يتناول هذا المقال مم يتكوّن التصميم، وما يجب قياسه، وما لا يفعله. لا يعرض أي نتيجة، لأنه لا يوجد عميل خلفه.
الفريق افتراضي، وكذلك كل رقم قد تتوقعه هنا. يستند التصميم إلى عمل خدمة العملاء الذي نصفه في /ai-for/customer-support. وأمر آخر في البداية: هذا دعم للوكيل فقط. لا يتحدث أي روبوت محادثة مع عميل في أي وقت.
ما الذي كان يُبطئ الوكلاء؟
الإجابات موجودة، لكن العثور عليها لا يتوسّع. التذكرة المعقدة تعني أن يفتح الوكيل سجل Zendesk ومستند منتج وملف PDF لسياسة الشحن، ثم يركّب الإجابة يدويًا. سنوات من التذاكر السابقة تحمل السابقة المرجعية، ولا يستطيع أحد البحث في ذلك الأرشيف خلال الوقت الذي ينتظر فيه العميل.
لذا كان الرد الأول ينتظر في الطابور بينما يبحث الوكيل. هذا الانتظار هو الرقم الذي يُسأل عنه رئيس الدعم. زمن الرد الأول، لا حجم التذاكر.
هل يستطيع الذكاء الاصطناعي تقليل زمن الرد الأول في دعم العملاء دون روبوت محادثة؟
نعم، هذا هو الهدف. تتيح أداة استرجاع داخلية للوكلاء طرح أسئلة بلغة بسيطة عبر التذاكر السابقة ومستندات المنتج وملفات PDF للسياسات والحصول على إجابة واحدة موثّقة بالمصدر. يظل الوكيل هو من يكتب الرد ويرسله. سيقيس الفريق زمن الرد الأول على التذاكر المعقدة قبل التطبيق وبعده، دون روبوت موجّه للعملاء.
مم يتكوّن التصميم؟
أداة استرجاع داخلية واحدة فوق ثلاثة مصادر: التذاكر التاريخية ومستندات المنتج وملفات PDF لسياسة الشحن. يكتب الوكيل سؤالًا كما يسأل زميلًا أقدم. تعود الإجابة مع ذكر المصدر، فيستطيع الوكيل التحقق منها قبل أن تصل إلى العميل.
- بحث في جميع التذاكر السابقة باستعلام واحد، لا علامة تبويب بعد أخرى.
- إجابات موثّقة بالمصدر، فيتحقق الوكيل من المصدر بدل الوثوق بصندوق أسود.
- إجابات مبنية على ملفات PDF لسياسة الشحن، حيث توجد قواعد الحالات الحدّية فعلًا.
- يبقى الوكيل داخل التذكرة. ولا ترد الأداة على عميل بنفسها أبدًا.
تدريب فريق الدعم جزء من التصميم، لا تسليمًا في النهاية. مؤشر الأداء الذي يجب الاتفاق عليه هو زمن الرد الأول على التذاكر المعقدة، يُقاس قبل التطبيق وبعده. ما الذي سيحرّكه؟ تجيب عنه بياناتك أنت، لا هذا المقال.
أليس هذا مثل بوت التحويل عن الدعم البشري؟
لا، والفرق هو لبّ الموضوع. تحاول خطة الصرف (deflection) خفض عدد التذاكر بالرد على العملاء مباشرة. يستهدف هذا التصميم رقمًا آخر: زمن الرد الأول، بوضع الاسترجاع خلف الوكيل. ويظل العميل يتحدث إلى شخص.
We are
تبني Stennir AI يعمل خلف وكلاء الدعم لديكم: استرجاع، فرز، صياغة ومراجعة، تُقاس مقابل زمن الرد الأول وجودة الحل.
We aren't
Stennir ليست مورّد chatbot يواجه العميل ولا تبيع التحويل عن الدعم البشري كهدف؛ يبقى الوكيل داخل التذكرة، ويظل عملاؤكم يتحدثون إلى بشر.
أدوات مثل Zendesk AI وintercom fin واقتراحات gorgias تعمل داخل أسوارها: وحداتك الجاهزة ومقالات المساعدة وردودك المحفوظة. يضيف هذا التصميم الاسترجاع عبر بقية المصادر. التذاكر التاريخية ومستندات المنتج وملفات PDF لسياسة الشحن وأدلة التشغيل. هناك تختبئ إجابات التذاكر المعقدة.
المؤشرات التي نحرّكها هي زمن الرد الأول وجودة الحل على التذاكر المعقدة، لا عدد الموظفين. نقول ذلك في اليوم الأول ونقيسه.
هل سينجح هذا مع فريق الدعم لدينا؟
اختبار الملاءمة بسيط. هل توجد إجاباتك أصلًا في أماكن بطيئة البحث؟ سنوات من التذاكر، وكومة من ملفات PDF للسياسات، ومستندات منتج تتغير. إذا كان الوكلاء يفقدون دقائق في البحث قبل كل رد معقد، فهذا هو الوقت الذي يهدف الاسترجاع إلى إعادته.
ينتمي هذا التصميم إلى عملنا في استشارات الذكاء الاصطناعي، مع إدماج تدريب فريق الدعم من جانب التدريب على الذكاء الاصطناعي. إن أردت أن ترى كيف تتكامل الأجزاء، ففي المدونة المزيد من الأمثلة التطبيقية مثل هذا.
إذا كان وكلاؤك يبحثون عن إجابات قبل كل رد معقد، فهذا هو التأخير الذي يستهدفه هذا التصميم. أخبرنا بما تبنيه وسنخبرك إن كان الاسترجاع هو الرافعة المناسبة أم لا.
