يتواصل عميل ثلاث مرات بشأن المبلغ المسترد نفسه. يرسل كل موظف ردًا صحيحًا، وتغلق المحادثات، ويظهر التقرير الأسبوعي ثلاث حالات تمت معالجتها. التقرير مرتب، لكن مشكلة العميل ما زالت قائمة.
يبدأ تحليل السبب الجذري في خدمة العملاء باعتبار التواصل المتكرر دليلًا على خلل في النظام أو العملية، لا دليلًا تلقائيًا على فشل الموظف. الهدف العملي هو ربط العرض الظاهر بضابط لم يعمل، ثم تنفيذ تغيير واحد قابل للقياس والتحقق من أن المشكلة نفسها لم تعد تتكرر.
ابدأ بنتيجة العميل المتكررة
لا تبدأ بتصدير ضخم للبيانات وطلب عام للبحث عن الأنماط. حدد نتيجة واحدة لا ينبغي أن تتكرر. قد يسأل العملاء مرة أخرى عن مكان طلب الإرجاع، أو ينتقلون إلى قناة أخرى بعد إجابة ناقصة، أو يعيدون فتح الحالة لأن الإجراء الموعود لم ينفذ.
اكتب المشكلة بلغة قابلة للملاحظة. اذكر هدف العميل، ونقطة التعطل، والفترة التي عاد خلالها. مثال افتراضي جيد هو أن العملاء الذين تمت الموافقة على مبالغهم المستردة تواصلوا خلال سبعة أيام لأن تاريخ الدفع والجهة المالكة للخطوة التالية لم يكونا ظاهرين. هذا أدق من القول إن الموظفين يحتاجون إلى تدريب إضافي.
يصف معهد خدمة العملاء هذه الممارسة بأنها تحديد الأسباب الأساسية لمشكلات الخدمة ومعالجتها بصورة استباقية. كما يشير إلى ضرورة وجود تصنيفات متسقة حتى يمكن اكتشاف المشكلات المتكررة والإبلاغ عنها.
ابن مجموعة أدلة واحدة
عدد الوسوم إشارة بداية وليس سببًا. اختر عينة صغيرة من قصص العملاء الكاملة وحافظ على تسلسلها عبر القنوات. سجل في كل حالة ما أراده العميل، وما عرفته الشركة عند كل خطوة، وما تم الوعد به، ومن كان يملك الإجراء التالي، وما حدث فعلًا قبل عودة العميل.
قارن أيضًا بحالات لم تتكرر. إذا عاد عشرة عملاء بشأن الاسترداد ولم يعد عشرة آخرون، فابحث عن الفرق. ربما تلقى الفريق الثاني تاريخ دفع واضحًا، أو وصل حدث الموافقة إلى المالية فورًا. المقارنة تمنع تحويل أكثر الحالات صخبًا إلى تفسير للجميع.
افصل العرض عن السبب
قولنا إن العملاء عادوا إلى التواصل يصف العرض فقط. وقد يكون غياب توقع واضح عاملًا مساهمًا. أما السبب الجذري فقد يكون أن مسار الاسترداد لا يحتوي على حدث يؤكد اكتمال الدفع، لذلك لا يستطيع الموظف معرفة متى خرج المبلغ فعلًا.
تعرّف إرشادات مايكروسوفت لإدارة الحوادث تحليل السبب الجذري بأنه تحقيق منظم في العوامل الأساسية لمنع التكرار. ويجب أن تناسب الطريقة شكل المشكلة. تساعد طريقة لماذا المتكررة في فجوة ضيقة، بينما تفيد المقارنة بعد تغيير سياسة أو منتج أو توجيه عند ارتفاع التكرار فجأة. وراجع الضوابط التي كان يفترض أن تمنع المشكلة.
استخدم أربعة أنواع من الأسباب حتى لا يتحول كل اكتشاف إلى تدريب للموظفين فقط:
- معلومات غير متاحة أو قديمة أو غامضة.
- مسار عمل بلا مالك أو حالة أو صلاحية أو إشارة اكتمال.
- منتج أو سياسة يولدان التواصل.
- رد خاطئ أو ناقص أو غير مفهوم.
قد تتشارك عدة أسباب. المطلوب هو العثور على ظرف تستطيع الشركة تغييره والتحقق منه.
اختبر السبب قبل تنفيذ الحل
السبب الموثوق يفسر الأدلة ويتنبأ بمكان ظهور المشكلة. إذا كان غياب حدث الاكتمال يسبب تكرار الاستفسار عن الاسترداد، فيفترض أن تتكرر الحالات التي تفتقده أكثر من الحالات المشابهة التي تحتوي عليه. اختبر ذلك وابحث أيضًا عما قد ينفي الفرضية.
هذا يمنع القصص المقنعة غير الصحيحة. قد يظن المدير أن بطء الرد هو السبب، بينما تبين العينة أن العملاء عادوا بعد ردود سريعة لكنها بلا التزام واضح. وقد يقترح فريق نصًا جاهزًا جديدًا بينما المشكلة الحقيقية في قائمة عمل لا يملكها أحد.
عالج ضرر العميل الفوري أثناء التحليل. الحفاظ على الدليل لا يعني ترك العميل بلا استرداد أو تسليم أو حل مؤقت آمن.
اجعل الإجراء التصحيحي مملوكًا
كل سبب مؤكد يحتاج إلى تغيير في الضابط ومالك وموعد ومقياس للتحقق. عدل صياغة التحديث إذا كانت التوقعات غامضة. أضف حالة إلزامية إذا كان العمل يضيع بين الفرق. أظهر حدث الاكتمال إذا لم يتمكن الموظفون من رؤية النتيجة الحقيقية. وغير التوجيه إذا كانت قائمة العمل تستقبل مهام لا تستطيع إنهاءها.
تؤكد إرشادات جوجل لما بعد الحوادث ضرورة فهم الأسباب المساهمة وتنفيذ إجراءات وقائية، مع مراجعة بلا لوم. هذا مناسب لعمليات خدمة العملاء أيضًا، لأن المراجعة العقابية تدفع الناس إلى إخفاء معلومات يحتاجها التحليل.
امنح الإجراء التصحيحي للفريق القادر على تغيير الضابط المعطل. العيب في المنتج يعود إلى فريق المنتج أو الهندسة، والقاعدة الغامضة قد تعود إلى المالية أو العمليات. يحتفظ الدعم بأدلة العميل ومسار المعالجة المؤقت، لكنه لا يستطيع إصلاح كل سبب سابق وحده.
تحقق من أن المشكلة توقفت
حدد قاعدة القياس قبل إطلاق التغيير. قارن سبب التواصل نفسه، وفئة العملاء نفسها، وفترة التكرار نفسها، ونطاق القنوات نفسه قبل التغيير وبعده. واقرأ عينة من الحالات بدل الاكتفاء بالعد، لأن انخفاض وسم معين قد يعني أن الموظفين استخدموا وسمًا آخر.
راقب ثلاثة أمور على الأقل وهي تكرار التواصل للهدف نفسه، واكتمال النتيجة التي يراها العميل، والاستثناءات التي أنشأها الحل. احتفظ بالتغيير فقط إذا تحسنت الأدلة دون نقل الضرر إلى مكان آخر.
في صندوق وارد DripTell المشترك تساعد محفوظات العميل المتصلة والمالك والحالة والملاحظات والخطوة التالية على إعادة بناء ما مر به العميل. لكن البرنامج لا ينبغي أن يعلن سببًا جذريًا اعتمادًا على التكرار وحده.
راجع هذا الأسبوع سببًا واحدًا متكررًا. خذ عشر قصص كاملة، وقارنها بحالات ناجحة، واكتب سببًا قابلًا للاختبار، وكلف الفريق الذي يملك الضابط بالإجراء الوقائي.
إذا أردت مقارنة هذا المسار بقائمة عملك الحالية، تواصل مع فريق DripTell.
الأسئلة الشائعة
ما تحليل السبب الجذري في خدمة العملاء؟
هو أسلوب منظم لمعرفة سبب تكرار مشكلة العميل، وتغيير العملية أو النظام الذي يولدها، ثم التحقق من انخفاض التواصل أو الشكوى المتكررة.
كم تذكرة دعم يجب مراجعتها؟
ابدأ بعينة مركزة تحتوي على تاريخ كامل وحالات ناجحة للمقارنة. قد تكشف عشر إلى عشرين قصة نمطًا قابلًا للاختبار، بينما تحتاج المشكلات الأكبر أو الأعلى خطورة إلى أدلة أوسع.
هل يجب ذكر أسماء الموظفين في المراجعة؟
سجل الأفعال والقرارات، لكن ركز على المعلومات والضوابط والصلاحيات ومسار العمل والسياق. قد يكون التدريب الفردي مناسبًا، إلا أن اسم الشخص ليس سببًا نظاميًا.
كيف نعرف أن الإجراء التصحيحي نجح؟
حدد فترة التكرار ونتيجة العميل قبل التغيير، ثم قارن الفئة نفسها بعده. أكد التحسن بقراءة الحالات لا بمشاهدة لوحة أرقام فقط.
DripTell Editorial
إرشادات عملية راجعها فريق المنتج وتجربة العملاء في DripTell.
تعرّف على كيفية التحقق من معلومات المنتج واستخدام المصادر الرسمية وتصحيح الأخطاء.
سياسة التحرير والمصادر