متى ينتهي طلب الدعم؟ حددوا الحل والإغلاق وطلب المتابعة

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

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

حددوا من عليه اتخاذ الخطوة التالية

ابدؤوا بالعمل، لا بقائمة حالات ملونة. هل يبحث الفريق في المشكلة؟ هل ينتظر معلومات من العميل؟ هل يؤخر مورد خارجي التقدم؟ هل قُدم حل؟ ومن يتابع الحالة أثناء الانتظار؟

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

كمثال محدد، تسرد مرجعية واجهة التذاكر في Zendesk القيم new وopen وpending وhold وsolved وclosed ضمن الحالات المسموح بها. وتوضح أنه عند تفعيل الحالات المخصصة يحتوي حقل الحالة على فئة الحالة، مع معرف منفصل للحالة المخصصة نفسها. لذلك لا يمكن للربط الخارجي استنتاج المسار كله بأمان من تسمية ظاهرة واحدة. ولا تحدد المرجعية التسميات أو قواعد الانتقال المناسبة لبوابتكم.

اجعلوا معنى الحل مفهوما

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

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

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

قرروا ما الذي يفعله الرد اللاحق

هناك عدة سلوكيات معقولة، لكن لا ينبغي أن يحددها النظام بالمصادفة.

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

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

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

لا تسمحوا للإغلاق الآلي بإخفاء عمل جديد

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

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

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

اجعلوا التقارير تعكس ما حدث فعلا

اختاروا معنى إعادة الفتح في التقارير. هل تقيسون أول حل مقترح، أم آخر حل، أم الإغلاق النهائي؟ وإذا أُنشئ طلب متابعة مرتبط، فهل يستطيع الموظفون معرفة أن المشكلة نفسها استمرت؟ سموا كل مقياس بدقة، بدلا من تسمية الجميع «وقت الحل».

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

حالات مهمة لاختبار القبول

في مشروع بوابة عملاء، أضيفوا إلى اختبارات القبول الحالات التالية:

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

الفائدة ليست زيادة عدد أسماء الحالات. المهم أن يعرف العميل والفريق هل انتهى العمل، ومن عليه التصرف، وإلى أين ستذهب الرسالة التالية.

المصدر ونطاقه

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