هل تحتاج إلى مساعدة في تطبيق هذا الدليل؟تحدّث مع فريق DripTell
طلب الفشل هو تواصل من العميل لم يكن ليحدث لو أن جزءًا سابقًا من الخدمة عمل كما وُعد به. لقياسه، راجع عينة ممثلة من المحادثات الواردة واسأل عن كل تواصل ما إذا كان سيبقى ضروريًا لو أُنجز العمل السابق بصورة صحيحة ووصلت المعلومات في وقتها. ثم اعرض نسبته من عدد حالات التواصل ونسبته من وقت المعالجة.
لا يعني كل تواصل متكرر وجود فشل. قد يعود العميل بسؤال جديد، أو يرسل مستندًا طلبه الفريق، أو يتابع حدثًا جديدًا تمامًا. السبب أهم من عدد المرات.
يعرّف الحكومة الاسكتلندية في 2026 طلب الفشل بأنه حاجة يمكن تجنبها أو أنشأها النظام بعد أن كان التدخل السابق غائبًا أو غير كافٍ أو غير فعال. في خدمة العملاء، يشمل ذلك متابعة تحديث لم يصل، أو إعادة معلومات ضاعت أثناء التحويل، أو فتح مشكلة أُغلقت مبكرًا، أو السؤال عن إجراء متوقع لم يُنفذ.
| المجال | ما الذي يجب التحقق منه |
|---|---|
| ابدأ بالتواصل الذي لم يكن يجب أن يحدث | استخدم سؤالًا افتراضيًا واحدًا في كل المراجعات. |
| صنف السبب إلى جانب حالة التواصل | وسم واحد لطلب الفشل يوضح حجم العمل، لكنه لا يوضح ما الذي يجب إصلاحه. امنح كل حالة مصنفة سببًا أصليًا. اجعل القائمة قصيرة وواضحة حتى يطبقها المراجعون بالطريقة نفسها. |
| ابن عينة مراجعة يمكن الدفاع عنها | ابدأ بعينة محددة زمنيًا من كل قناة واردة مهمة تغطي أيامًا ولغات وفرقًا وأسباب تواصل مختلفة. وسعها في المجالات الكبيرة أو عالية المخاطر. |
| قس نسبة التواصل ونسبة العمل | اعرض رقمين على الأقل. |
ابدأ بالتواصل الذي لم يكن يجب أن يحدث
استخدم سؤالًا افتراضيًا واحدًا في كل المراجعات.
هل كان هذا التواصل سيظل ضروريًا لو أن الشركة نفذت العمل السابق بصورة صحيحة وأبقت العميل على اطلاع واضح؟
إذا كانت الإجابة الصادقة لا، فالتواصل على الأرجح طلب فشل. أما إذا كان العميل يقدم طلبًا جديدًا أو يكمل خطوة متفقًا عليها، فهو غالبًا طلب قيمة، أي تواصل موجود أصلًا لكي تعالجه الخدمة.
لنفترض أن عميلًا سأل عن موعد وصول طلبه. قد يكون السؤال الأول طبيعيًا. وعده الفريق بتحديث يوم الثلاثاء. عاد يوم الخميس لأن شيئًا لم يصل. الرسالة الثانية طلب فشل سببه وعد لم يُنفذ. وإذا عاد بعد التسليم لطلب فاتورة ضريبية، فهذه حاجة مختلفة وليست فشلًا جديدًا.
صنف السبب إلى جانب حالة التواصل
وسم واحد لطلب الفشل يوضح حجم العمل، لكنه لا يوضح ما الذي يجب إصلاحه. امنح كل حالة مصنفة سببًا أصليًا. اجعل القائمة قصيرة وواضحة حتى يطبقها المراجعون بالطريقة نفسها.
- إجراء مفقود أو متأخر
- تحديث مفقود أو متأخر أو غير واضح
- إجابة خاطئة أو ناقصة
- سياق ضائع أو معلومات طُلبت مرة أخرى
- إغلاق مبكر
- خدمة ذاتية أو أتمتة معطلة
- فجوة في السياسة أو الصلاحية
- سبب غير معروف بعد المراجعة
سجل حاجة العميل منفصلة عن السبب. سؤال التسليم هو الحاجة، أما غياب تحديث الشحن فهو السبب.
لا تنسب السبب تلقائيًا إلى الموظف الذي استقبل الرسالة اللاحقة. قد يكون الفشل في الشحن أو الفوترة أو تصميم المنتج أو المورد أو قاعدة أتمتة أو قرار دعم سابق. الموظف المستقبِل غالبًا يكشف الفشل ولا ينشئه.
ابن عينة مراجعة يمكن الدفاع عنها
ابدأ بعينة محددة زمنيًا من كل قناة واردة مهمة تغطي أيامًا ولغات وفرقًا وأسباب تواصل مختلفة. وسعها في المجالات الكبيرة أو عالية المخاطر.
احتفظ بست حقائق لكل حالة وهي حاجة العميل، والوعد أو الحدث السابق، وما حدث فعليًا، وسبب التواصل الآن، وقرار التصنيف مع درجة الثقة، والسبب الأصلي ومالك الإجراء التصحيحي.
اطلب من مراجعين تصنيف جزء أولي. ناقش الاختلافات وعدل القواعد قبل قياس الفترة كلها. احتفظ بفئة غير مؤكدة.
الحالات المعاد فتحها والرسائل المتكررة وتغيير القناة وعبارات مثل «هل يوجد تحديث» إشارات جيدة للاكتشاف، لكنها ليست دليلًا وحدها. توصي إرشادات تقارير الدعم لدى Zendesk بفحص إعادة الفتح والطلبات المتعددة من العميل نفسه وعمر الحالة وأولويتها وتصنيفها. المراجعة الجيدة تربط هذه الإشارات بالحاجة نفسها وبحدث الخدمة السابق.
قس نسبة التواصل ونسبة العمل
اعرض رقمين على الأقل.
نسبة تواصل طلب الفشل تساوي عدد حالات طلب الفشل المصنفة مقسومًا على كل حالات التواصل الواردة المؤهلة.
نسبة عمل طلب الفشل تساوي وقت المعالجة المصروف على تلك الحالات مقسومًا على وقت معالجة كل الحالات المؤهلة.
يمثل تقرير مكتب التدقيق الوطني البريطاني عن خدمة عملاء DWP مثالًا عمليًا لأنه فصل وقت المكالمات القابل للتجنب والمحتمل تجنبه وغير القابل للتجنب. الدرس هو طريقة القياس، لا استعارة معيار من خدمة مختلفة.
قسّم النتيجة حسب الحاجة والسبب والقناة واللغة والمنتج والفريق الأصلي، وانشر حدود العينة مع النتيجة.
اربط رحلة العميل قبل أتمتة الوسم
يسهل فقدان طلب الفشل عندما تبدو محادثة WhatsApp الأولى ورسالة Instagram اللاحقة والحالة المعاد فتحها كأنها تخص ثلاثة أشخاص. اربط التواصل بالعميل والحاجة حيث تسمح الموافقة والسياسة. احتفظ بالمواعيد الموعودة والملكية وتغييرات الحالة وإصدار الأتمتة وسبب التحويل ودليل الإكمال.
يساعد صندوق DripTell المشترك على جمع سجل القنوات المدعومة والملكية والملاحظات والحالة والإجراء التالي للمراجعة.
أتمت إشارات المرشحين الواضحة بعد أن يستطيع الفريق التصنيف بثبات. اجعل القواعد تعرض الحالات للمراجعة ولا تعلن أن كل تكرار فشل.
استخدم المقياس لإزالة سبب واحد
اختر أكبر سبب يمكن منعه ويستطيع فريق محدد تغييره. حدد تدخلًا واضحًا، مثل إرسال تحديث شحن صادق قبل الموعد، أو الاحتفاظ بالسياق عند التحويل، أو منع الإغلاق حتى يتأكد تنفيذ الإجراء التالي.
كرر التصنيف بعد التغيير. تحقق من انخفاض نسبة التواصل ونسبة العمل للسبب المستهدف من دون ارتفاع المغادرة أو الشكاوى أو تعذر الوصول إلى المساعدة. إذا انخفض الوسم فقط لأن العميل لم يعد يستطيع التواصل، فلم تتحسن الخدمة.
الهدف ليس لوحة مثالية، بل تقليل عدد العملاء الذين يضطرون إلى مطالبة الشركة بإنهاء عمل سبق أن وعدت بإنجازه.
لرسم مسار الدليل في خدمتك، تواصل مع DripTell.
الأسئلة الشائعة
ما الفرق بين طلب الفشل والتواصل المتكرر
التواصل المتكرر حدث يمكن ملاحظته، أما طلب الفشل فهو حكم على سبب الحدث. قد يكون التكرار لحاجة جديدة، وقد يكون أول تواصل مع الدعم طلب فشل لأن عملية سابقة خارج الدعم تعطلت.
هل تعد كل متابعة للحالة طلب فشل
لا. تعد كذلك عندما تفوت الشركة تحديثًا وعدت به أو تترك التوقعات غامضة. راجع الوعد والسياق قبل اتخاذ القرار.
ما حجم عينة المراجعة المناسب
استخدم عينة تغطي كل قناة وسبب ولغة وفترة تشغيل مهمة. وسعها حتى يستقر التصنيف للأسباب الكبيرة، وانشر الحجم وعدم اليقين بدل ادعاء دقة زائفة.
هل يصلح طلب الفشل مقياسًا لأداء الموظف
غالبًا لا، لأن السبب يكون خارج سيطرة الموظف المستقبِل. استخدمه لاكتشاف العملية الفاشلة وإسناد الإصلاح إلى الفريق الذي يملك الضابط الأصلي.
DripTell Editorial
إرشادات عملية راجعها فريق المنتج وتجربة العملاء في DripTell.
تعرّف على كيفية التحقق من معلومات المنتج واستخدام المصادر الرسمية وتصحيح الأخطاء.
سياسة التحرير والمصادر