ردیابی ایشو در پشتیبانی: چطور مشکلهای تکراری را مهار کنیم
ایشو چیست، چه فرقی با برچسب و تیکت دارد و چطور تیم پشتیبانی با وقوع‌ها، رضایت مشتری و زمان حل مشکل‌هایی را که دوباره برمی‌گردند ردیابی میکند.
در این مطلب
هفتهٔ پیش درگاه پرداخت یک ساعت قطع شد و ۴۰ نفر به پشتیبانی پیام دادند. امروز همان اتفاق دوباره افتاد. اگر تیم شما فقط گفت‌وگوها را یکی‌یکی جواب میدهد، هر بار از صفر شروع میکنید و هیچ‌کس نمی‌داند این سومین باری است که همین مشکل پیش می‌آید.
ردیابی ایشو برای همین است: دیدن مشکل‌ها به‌جای گفت‌وگوها.
ایشو چیست و با برچسب و تیکت چه فرقی دارد؟
- برچسب یک دسته‌بندی کلی است («پرداخت»). می‌گوید گفت‌وگو دربارهٔ چه موضوعی است.
- تیکت یک درخواست مشخص از یک مشتری است که باید پیگیری و بسته شود.
- ایشو یک مشکل مشخص است («وقفهٔ درگاه پرداخت») که ممکن است ده‌ها گفت‌وگو و تیکت از مشتری‌های مختلف را به هم وصل کند.
با برچسب می‌فهمید ۴۰ گفت‌وگو دربارهٔ پرداخت بوده. با ایشو می‌فهمید همه از یک مشکل آمده‌اند و آن مشکل چقدر هزینه داشته است.
مفهوم وقوع: همان مشکل، بار دوم
بسیاری از مشکل‌ها برمی‌گردند: قطعی درگاه، خطای یک نسخهٔ اپلیکیشن، تأخیر یک پیک. اگر هر بار ایشوی تازه بسازید، الگو دیده نمی‌شود؛ اگر همه را در یک ایشو بریزید، نمی‌توانید بفهمید بار دوم بهتر مدیریت شد یا بدتر. راه‌حل وقوع است: هر ایشو چند وقوع دارد، هر کدام با بازهٔ زمانی خودش. میتوانید عددهای هر وقوع را جدا ببینید و عدد مجموع را هم.
چه چیزهایی را اندازه بگیریم؟
برای هر ایشو (و هر وقوع) این‌ها را دنبال کنید:
- تعداد گفتوگوهای متصل: اندازهٔ اثر مشکل.
- نظرسنجی رضایت: چند مشتری راضی (CSAT) و چند مشتری ناراضی (DSAT) بودند. CSAT چیست؟
- رعایت SLA: چند درصد گفت‌وگوها در مهلت جواب گرفتند. SLA در پشتیبانی
- زمان اولین پاسخ و زمان حل.
- تکرار: این مشکل در بازهٔ انتخاب‌شده چند بار برگشته است.
- میانگین زمان رفع (MTTR) و نرخ تکرار: ببینید یک مشکل معمولاً چقدر طول می‌کشد تا رفع شود و هر چند وقت یک بار برمی‌گردد. هدهد MTTR را به‌صورت میانگین، میانه و صدک ۹۰ نشان میدهد و کنارش فاصلهٔ میانگین بین دو تکرار (MTBR)، نرخ تکرار در هر ۳۰ روز و فهرست ایشوهای مزمن (دست‌کم سه وقوع در ۹۰ روز) را میدهد.
شاخص‌های عمومی‌تر را در KPIهای پشتیبانی مشتریان ببینید.
روند پیشنهادی برای تیم
- نام‌گذاری روشن. عنوان ایشو باید برای کسی که در جلسه نبوده هم قابل‌فهم باشد: «وقفهٔ درگاه پرداخت»، نه «مشکل ۱۲».
- وصل‌کردن از همان گفت‌وگو. اپراتوری که اولین پیام را می‌بیند، گفت‌وگو (یا تیکت) را به ایشو وصل میکند یا ایشوی تازه می‌سازد. وقتی ایشو جا افتاد، یک قانون اتصال خودکار هم بنویسید تا گفتوگوهای مشابه خودشان وصل شوند.
- تعیین وقوع. اگر مشکل تازه شروع شده یا برگشته، وقوع تازه شروع کنید؛ در غیر این صورت به وقوع جاری وصل کنید.
- بستن وقوع. وقتی مشکل رفع شد وقوع را ببندید و یادداشت علت و راه‌حل را بنویسید. اگر مدتی گفت‌وگوی تازه‌ای وصل نشود، وقوع خودکار هم بسته میشود.
- مرور هفتگی. گزارش ایشوها را باز کنید و بخش «ایشوهای تکرارشونده» را بخوانید.
مرور هفتگی ده‌دقیقه‌ای
- کدام ایشوها بیشترین گفت‌وگو را گرفتند؟
- کدام ایشو در بازه برگشت و چرا؟
- رضایت مشتری و SLA در وقوع جدید نسبت به وقوع قبلی بهتر شد یا بدتر؟
- برای ایشوهای پرتکرار، چه کسی مسئول رفع ریشه‌ای است؟ (موضوع را به تیم فنی یا محصول بدهید.)
اشتباه‌های رایج
- ایشوی بیش‌ازحد کلی («مشکل پرداخت»). بعد از مدتی همه چیز در آن می‌ریزد.
- ایشوی بیش‌ازحد ریز که هر گفت‌وگو یکی دارد. الگو دیده نمی‌شود.
- فراموش‌کردن بستن وقوع. عددهای زمان حل بی‌معنی می‌شوند.
- استفاده از ایشو به‌جای تیکت. ایشو مشکل را دنبال میکند و تیکت درخواست مشتری را؛ هر دو لازم‌اند.
برای دیدن این روند در ابزار، صفحهٔ ردیابی ایشو و سیستم تیکتینگ هدهد را ببینید.
سؤالات متداول
ردیابی ایشو به چه تیمهایی کمک میکند؟
هر تیمی که مشکلهای تکراری دارد: فروشگاههای اینترنتی (تأخیر ارسال)، فینتک (قطعی درگاه)، آموزش آنلاین (خطای پخش ویدیو).
ایشو هم خودکار ساخته میشود؟
بله، میتوانید قانونی تعریف کنید تا گفتوگوهای مشابه خودکار به ایشوی مناسب وصل شوند؛ اپراتور هر وقت خواست آن را تغییر میدهد.
اگر مشکل مدتی آرام شود و دوباره برگردد چه؟
وقوع جدیدی روی همان ایشو شروع میکنید و تاریخچهٔ وقوعهای قبلی کنار آن میماند، تا مقایسه ممکن باشد.
