تقنية

متى يحوّل مساعد خدمة العملاء المحادثة إلى موظف؟

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

يكون تحويل محادثة الذكاء الاصطناعي إلى موظف مناسبا عندما يطلب العميل ذلك، أو يحتاج الحل إلى معلومة أو صلاحية غير متاحة للمساعد. هذه قواعد تصميم مقترحة ينبغي مواءمتها مع الخدمة. والأمر يتطلب مسارا فعليا للتسليم؛ ففي Dialogflow CX مثلا، إشارة التحويل إلى موظف لا تنفذ التسليم بذاتها، بل يستخدمها النظام المتصل لتنفيذ الإجراء. [1] لذلك لا يكفي أن يكتب المساعد «تم تحويلك».

الخلاصة السريعة

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

  • حدد مسبقا حالات التحويل: طلب الموظف، أو نقص معلومة، أو إجراء يحتاج إلى صلاحية.
  • سلّم ملخصا يحفظ طلب العميل والخطوات التي نُفذت فعلا، دون بيانات زائدة أو استنتاجات عن شخصيته.
  • فرّق بين طلب التحويل ونجاحه؛ إشارة تقنية وحدها لا تضمن التسليم. [1]
  • اختبر حالات التعثر، وأتح قناة بديلة عندما لا يتوفر موظف، ولا تعتبر المحادثة المحولة مشكلة محلولة.

ضع حدودا واضحة لعمل المساعد

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

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

احفظ سياق المشكلة عند التسليم

جهّز ملخصا قصيرا: ماذا يريد العميل؟ ما المعلومة المتاحة؟ وما الخطوة التي نجحت أو فشلت؟ ميّز بين قول العميل وبين نتيجة سجل النظام. لا تكتب «الطلب لم يصل» بوصفها حقيقة من قاعدة البيانات إذا كان هذا ما أفاد به العميل فقط.

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

تأكد من اكتمال التحويل

توضح وثائق Dialogflow CX أن استجابة التحويل تشير إلى ضرورة التسليم، ولا تغير حالة الجلسة بنفسها؛ يقع تنفيذ الخطوات اللازمة على النظام أو التكامل المستخدم. [1] هذه نقطة خاصة بالمنتج توضّح الفرق العام بين اقتراح إجراء وتنفيذه.

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

اختبر المسار وقِس النتيجة

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

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

المصادر ومتابعة القراءة

  1. Google Cloud: Dialogflow CX Fulfillments — Live agent handoff (يفتح في نافذة جديدة)docs.cloud.google.com

أُعدّ هذا المقال بصياغة عربية أصلية بالاستناد إلى المصادر أعلاه، وهو مدخل تمهيدي إلى الموضوع. اقرأ منهجية المحتوى وحدوده.