تحليل المحادثات المتكررة بالذكاء الاصطناعي : لماذا يعود العميل للمشكلة نفسها ؟

يساعدك تحليل المحادثات المتكررة بالذكاء الاصطناعي على اكتشاف المشكلات التي تستمر خلف تذاكر تبدو منتهية . فقد يتواصل العميل عبر المحادثة ، ثم يرسل بريدًا ، ثم يتصل هاتفيًا بشأن الطلب نفسه ؛ بينما تظهر هذه التفاعلات في سجلات منفصلة لا تكشف بسهولة أن المشكلة واحدة .

السؤال هنا يتجاوز عدد الرسائل التي استقبلها فريقك : لماذا احتاج العميل إلى العودة ؟ هل لم يفهم الخطوات ، أم لم ينجح الحل ، أم أنه ينتظر تأكيدًا لم يصله ؟

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

1. متى نعدّ تواصل العميل تكرارًا للمشكلة نفسها ؟

عودة العميل لا تعني تلقائيًا فشل الخدمة . فقد يشكر الموظف ، أو يرسل مستندًا طُلب منه ، أو يسأل عن طلب شراء جديد . لذلك ، ابدأ بتعريف واضح لما ستعدّه تواصلًا متكررًا قبل مطالبة الأداة باستخراجه .

في مثالنا ، نبحث عن جلسة تواصل جديدة تخص المشكلة نفسها بعد تسجيلها محلولة ، وخلال سبعة أيام من ذلك التسجيل . هذه مدة اخترناها للتحليل ، وليست معيارًا عامًا يصلح لكل نشاط .

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

أ. حالة التذكرة لا تكشف القصة كاملة

توضح وثائق Zendesk أن الرد على تذكرة محلولة يمكن أن يعيد فتحها ، بينما الرد على تذكرة مغلقة ينشئ تذكرة متابعة مرتبطة بالأصل . لذلك ، قد يظهر استمرار المشكلة في سجل جديد ، وليس بالضرورة في عداد التذاكر المعاد فتحها .

عمليًا ، لا تكتفِ بفلتر ( أُعيد فتحها ) . افحص أيضًا الطلبات المرتبطة والتواصل عبر القنوات الأخرى المتاحة لديك .

ب. فرّق بين التكرار وعدم الحل من أول تواصل

يرتبط مفهوم الحل من أول تواصل بحل مشكلة العميل عند التواصل الأول ، مع التمييز بين العودة للمشكلة نفسها وطرح مشكلة مختلفة .

لكن قياسنا هنا يبدأ بعد تسجيل الحالة محلولة ، وقد يكون سبقه أكثر من تواصل . لذا لا يجوز تسمية نتيجته تلقائيًا ( معدل الحل من أول تواصل ) ، أو اعتبار الحالات التي لم تعد ناجحة دون دليل إضافي .

2. جهّز سجلًا يربط المحادثات دون خلط العملاء والمشكلات

لتحليل تكرار التواصل مع خدمة العملاء ، اجمع الحد الأدنى من البيانات اللازمة داخل بيئة معتمدة لدى منشأتك . استخدم رمزًا للعميل بدل اسمه متى كان ذلك كافيًا ، واحذف بيانات الدفع والتفاصيل الشخصية غير المرتبطة بالمهمة .

يتضمن سجل العمل المقترح :

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

لا يكفي تشابه الكلمات أو تطابق العميل لدمج محادثتين . فقد يشتكي العميل من تأخر طلبين مختلفين . وفي المقابل ، قد يصف المشكلة نفسها مرة بعبارة ( الرابط لا يعمل ) ، ومرة بعبارة ( لم أستطع تأكيد الموعد ) .

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

إذا كانت إحدى قنوات التواصل غير متاحة للتحليل ، اذكر ذلك في النتيجة . عبارة ( لم نرصد عودة في السجلات المتاحة ) أدق من الجزم بأن العميل لم يتواصل مجددًا .

3. مثال عملي : أربع حالات وسبع عودات

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

أظهرت السجلات الافتراضية أربع حالات عاد أصحابها :

• الحالة C03 : عودتان ، وتتضمن إحداهما سؤالًا عن الخطوة المقصودة في الشرح .
• الحالة C06 : عودة واحدة ، يقول فيها العميل إن رابط التأكيد لا يعمل .
• الحالة C09 : ثلاث عودات لمتابعة مشكلة يقول العميل إنها ظهرت مجددًا .
• الحالة C12 : عودة واحدة للاستفسار عما إذا كان الطلب قد نُفّذ .

أما الحالات الثماني الأخرى ، فلم نرصد عودة أصحابها خلال نافذة المتابعة المحددة .

أ. احسب نسبة الحالات المتكررة

المعادلة المستخدمة في هذا المثال :

نسبة الحالات التي تكرر التواصل بشأنها = عدد الحالات التي شهدت عودة ÷ عدد الحالات المؤهلة للمتابعة × 100 .

وعليه : أربع حالات من أصل 12 تساوي نحو 33.3% .

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

ب. لا تحوّل غياب العودة إلى إثبات للحل

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

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

4. اطلب تحليل الأدلة بدل اختراع أسباب عودة العميل

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

يمكنك استخدام الأمر التالي بعد تجهيز السجلات المسموح بمشاركتها :

حلّل الحالات المرفقة وفق تعريف تكرار التواصل الموضح في الملف . اقترح ربط الجلسات التي تخص المشكلة نفسها ، ولا تدمجها اعتمادًا على اسم العميل أو تشابه الكلمات وحدهما .

لكل حالة ، اذكر معرّفات الجلسات ، ودليل الربط ، وعبارة قصيرة من الرسالة تدعم سبب العودة الظاهر ، ثم حدّد المعلومات الناقصة والفحص المطلوب .

افصل بين ما قاله العميل ، وما يثبته سجل الإجراءات ، والتفسير المحتمل . إذا لم يكفِ الدليل ، صنّف النتيجة ( تحتاج إلى مراجعة ) ، ولا تخمّن سببًا أو تنسب تقصيرًا إلى موظف .

اعرض عدد الحالات المتكررة وعدد جلسات التواصل الإضافية منفصلين واذكر الحالات المستبعدة وأسباب استبعادها .

في الحالة C06 ، عبارة ( رابط التأكيد لا يعمل ) تثبت أن العميل أبلغ عن مشكلة في الرابط . لكنها لا تثبت وحدها أن الخادم متوقف ؛ فقد يرتبط الأمر بانتهاء صلاحية الرابط أو خطوة أخرى تحتاج إلى فحص .

وفي الحالة C12 ، سؤال ( هل نُفّذ طلبي ؟ ) يوضح غياب التأكد لدى العميل. لمعرفة السبب، راجع سجل التنفيذ وإرسال التأكيد : ربما نُفّذ الطلب ولم يصل الإشعار ، وربما لم يُنفّذ أصلًا .

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

5. حوّل النتيجة إلى تحسين واختبر أثره

اختر مشكلة يمكن التحقق منها ومعالجتها ، ثم حدّد المسؤول عن الإجراء ودليل اكتماله . لا تجعل النتيجة النهائية قائمة عامة مثل (تحسين التواصل) دون خطوة محددة .

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

أما إذا أكدت السجلات تعطل رابط في الحالة C06 ، فتعديل صياغة الرد وحده لن يصلح المشكلة ؛ يلزم إصلاح الخلل والتحقق من نجاح الإجراء .

أ. راقب مجموعات قابلة للمقارنة

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

قد تختلف النتائج أيضًا بسبب تغير نوع الطلبات أو ضغط العمل . لذلك، افصل ما لاحظته عن تفسيرك لسبب حدوثه ، وواصل المتابعة عندما تكون البيانات محدودة .

ب. لا تحسّن الرقم بإخفاء التواصل

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

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

ج. اجعل المراجعة جزءًا من التحليل

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

الهدف هو التأكد من أن الحالة الواحدة لم تُحسب مرتين ، وأن مشكلتين مختلفتين لم تُدمجا ، وأن الاقتباس المستخدم يدعم الاستنتاج فعلًا .

6. الخلاصة

تبدأ فائدة تحليل المحادثات المتكررة بالذكاء الاصطناعي من تعريف ما تعدّه عودة للمشكلة نفسها ، ثم ربط السجلات وفحص الأدلة قبل حساب النسب .

في مثالنا ، عادت أربع حالات من أصل 12 ، لكنها أنتجت سبع جلسات إضافية . فصل هذين الرقمين كشف حجم التكرار وعبء المتابعة دون الخلط بينهما .

ابدأ بمجموعة محدودة من الحالات ، واختر مشكلة واحدة أثبتتها السجلات ، ثم اختبر أثر إصلاحها . ما تريد الوصول إليه هو فهم ما بقي دون حل ، وما يحتاج إلى توضيح أو تنفيذ ، بحيث يجد العميل إجابة نافعة وإجراءً يمكن التأكد منه .