برای مدیریت درخواست های عقب افتاده پشتیبانی، ابتدا یک فهرست قابل اعتماد از پرونده‌های حل‌نشده بسازید؛ سپس سن درخواست را کنار اثر مشکل و مانع رسیدگی قرار دهید. قدیمی‌ترین تیکت همیشه مهم‌ترین نیست، اما هیچ پرونده قدیمی نباید بدون توضیح ناپدید شود. این روش به مدیر کمک می‌کند بین کار واقعاً معطل، درخواست تکراری و پرونده منتظر مشتری تفاوت بگذارد.
قبل از اولویت‌بندی صف را پاک‌سازی کنید
درخواست‌های تکراری را به پرونده اصلی متصل کنید و سابقه ارتباط را نگه دارید. وضعیت بسته‌شده را فقط وقتی انتخاب کنید که نتیجه قابل توضیح باشد. برای موارد منتظر مشتری، سؤال ارسال‌شده و موعد بازبینی را بنویسید؛ برای موارد منتظر واحد دیگر، نام همان واحد و تعهدش لازم است. نداشتن اقدام جدید با حل‌شدن مسئله یکی نیست و نباید به بستن دسته‌جمعی پرونده‌ها منجر شود.
سن، اثر و مانع را جدا ببینید
سن پرونده را از تاریخ ثبت اصلی محاسبه کنید و زمان آخرین پاسخ مفید را جدا نگه دارید. پرونده سه‌روزه‌ای که هر روز بررسی مستند شده با پرونده سه‌روزه بی‌پاسخ یکسان نیست. اثر را با توصیف واقعی بنویسید، مانند توقف ثبت سفارش یا اشتباه در یک نشانی. سپس مانع را مشخص کنید: کمبود اطلاعات، نیاز به اختیار، نقص محصول یا نبود ظرفیت؛ هر مانع اقدام متفاوتی می‌خواهد.
جدول نمونه برای جلسه رسیدگی به عقب‌ماندگی
ردیف‌های زیر ساختگی‌اند و ساختار قابل استفاده را نشان می‌دهند. جدول را در یک محل مشترک نگه دارید و برای هر ردیف فقط یک نفر را مسئول پیگیری نهایی بگذارید؛ مشارکت چند تیم نباید مسئولیت پاسخ به مشتری را مبهم کند.
- پرونده نمونه: پ۱۰؛ سن درخواست: چهار روز؛ اثر واقعی: ثبت سفارش متوقف؛ مانع فعلی: گزارش خطا ناقص؛ مسئول پیگیری: سرپرست فنی؛ اقدام بعدی: دریافت زمان و تصویر خطا
- پرونده نمونه: پ۱۱؛ سن درخواست: هفت روز؛ اثر واقعی: پاسخ نهایی اعلام نشده؛ مانع فعلی: انتظار تصمیم واحد مربوط؛ مسئول پیگیری: مسئول شکایت؛ اقدام بعدی: دریافت تصمیم مستند
- پرونده نمونه: پ۱۲؛ سن درخواست: دو روز؛ اثر واقعی: سؤال نحوه استفاده؛ مانع فعلی: منتظر پاسخ مشتری؛ مسئول پیگیری: کارشناس پرونده؛ اقدام بعدی: ارسال یادآوری طبق روال
دانلود همین جدول با قالب CSV سازگار با اکسل
یک برنامه جمع‌کردن صف بسازید
در جلسه کوتاه روزانه، پرونده‌های پراثر و وعده‌های گذشته را بررسی کنید، سپس برای بخشی از پرونده‌های قدیمی ظرفیت مشخص کنار بگذارید. اگر همه تیم فقط ورودی جدید را جواب دهد، عقب‌ماندگی پابرجا می‌ماند. خروجی جلسه باید اقدام و موعد باشد، نه صرفاً شمارش تیکت. پس از اجرای برنامه، تعداد حل واقعی، موارد باقی‌مانده و علت توقف را گزارش کنید؛ رشد پرونده‌های بازگشایی‌شده نشانه‌ای برای بازبینی کیفیت پاک‌سازی است.
یک ردیف جدا برای مواردی بگذارید که پاسخ آن‌ها به تصمیم مدیریتی وابسته است. اگر چنین پرونده‌ای هر روز به همان کارشناس برگردد، سن آن بالا می‌رود بدون آنکه اختیار تازه‌ای ایجاد شود. در پایان هفته، سه علت اصلی توقف را به تصمیم مشخص تبدیل کنید: دسترسی لازم، روشن‌شدن سیاست یا اصلاح فرایند. همچنین تاریخ آخرین اطلاع‌رسانی را ببینید؛ مشتری باید بداند پرونده‌اش هنوز باز است و مرحله بعد را چه کسی دنبال می‌کند.
ادامه مطالعه و بررسی فرایند تماس
برای مرتبط‌کردن این الگو با جریان کار تیم، راهنمای طراحی فرایند پشتیبانی تلفنی را بخوانید. برای بررسی تناسب اپراگپ با نیاز کسب‌وکارتان، معرفی و دموی اپراگپ را ببینید و سناریوی خود را مبنای ارزیابی قرار دهید.
موضوع مرتبط: راهنمای قابلیت مرتبط با این فرایند.