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