وقتی درخواست نزدیک پایان روز کاری ثبت می‌شود، فاصله تا پاسخ بعدی لزوماً با زمان کاری سپری‌شده برابر نیست. اگر گزارش و وعده فروش دو تقویم متفاوت داشته باشند، تیم ظاهراً خوب عمل می‌کند اما مشتری انتظار دیگری دارد. راه‌حل، یک ساعت اندازه‌گیری با قواعد آشکار است.
تقویم باید بخشی از تعریف شاخص باشد
روزهای فعال، شروع و پایان هر شیفت، تعطیلی استثنایی و منطقه زمانی را مشخص کنید. سپس بنویسید شروع ساعت، ثبت کدام رویداد است و توقف آن با چه پاسخ معتبری انجام می‌شود. تأیید خودکار دریافت و پاسخ کارشناس را یکسان فرض نکنید. اگر چند تیم تقویم متفاوت دارند، قاعده انتخاب تقویم برای پرونده روشن باشد؛ تغییر تیم نباید ساعت گذشته را بی‌صدا پاک کند.
مثال آموزشی عبور از روز تعطیل
فرض کنیم تیم فقط پنجشنبه و شنبه از ساعت نُه تا هفده فعال است و جمعه تعطیل است. درخواست پنجشنبه ساعت شانزده و سی ثبت و شنبه ساعت نُه و سی پاسخ داده می‌شود. از پنجشنبه سی دقیقه و از شنبه سی دقیقه قابل شمارش داریم؛ جمع زمان کاری یک ساعت است. فاصله تقویمی چهل‌ویک ساعت است. این تقویم ساختگی برای توضیح روش است و ساعات واقعی هیچ مجموعه‌ای را اعلام نمی‌کند.
جدول قطعات قابل جمع
| بازه | وضعیت تقویم فرضی | سهم زمان کاری |
|---|---|---|
| پنجشنبه ۱۶:۳۰ تا ۱۷ | فعال | ۳۰ دقیقه |
| پایان پنجشنبه تا آغاز شنبه | خارج از برنامه | صفر دقیقه کاری |
| شنبه ۹ تا ۹:۳۰ | فعال | ۳۰ دقیقه |
| مجموع | دو قطعه فعال | ۶۰ دقیقه |
خطای اصلاح‌پذیر: تعطیلی دیرتر اضافه شده است
در یک سناریوی فرضی، گزارش اولیه جمعه را روز فعال حساب می‌کند؛ مدیر بعداً تقویم را اصلاح می‌کند و همه زمان‌های گذشته تغییر می‌کنند. برای حفظ قابلیت توضیح، نسخه تقویم و تاریخ اعتبارش را نگه دارید. اگر تصمیم به بازمحاسبه سابقه گرفتید، دامنه و دلیل آن را ثبت کنید و گزارش قبلی را بدون ردپا بازنویسی نکنید. در غیر این صورت کاهش زمان ممکن است فقط نتیجه تغییر تقویم باشد.
انتظار مشتری را با همین تعریف هماهنگ کنید
عبارت «پاسخ در یک روز» مبهم است. اگر منظورتان ساعت کاری است، تقویم و مسیر وضعیت را به زبان ساده توضیح دهید. زمان پاسخ با زمان حل موضوع یکی نیست. همچنین توقف ساعت هنگام انتظار اطلاعات مشتری باید قاعده مصوب داشته باشد؛ ارسال یک سؤال بی‌ربط نباید راهی برای متوقف‌کردن مصنوعی تعهد باشد. این صفحه عدد تعهد تعیین نمی‌کند؛ تعهد باید با ظرفیت و سیاست واقعی کسب‌وکار تعیین شود.
پیش از اعتماد به داشبورد این حالت‌ها را امتحان کنید
درخواست دقیقاً در پایان شیفت، قبل از تعطیلی، هم‌زمان با تغییر تقویم و متعلق به تیمی در منطقه زمانی دیگر را با داده آزمایشی بسنجید. خروجی محاسبه را دستی به قطعات فعال تقسیم کنید تا اختلاف روشن شود. مستندات Zendesk تقویم کاری و تعطیلات را جزئی از تنظیمات برنامه معرفی می‌کند؛ این شاهد، ادعای اتصال اپرا یا وجود همین تنظیمات در همه ابزارها نیست. از ارائه عدد بی‌برچسب «زمان پاسخ» در گزارش مشتری پرهیز کنید.
ادامه بررسی با داده خودتان
برای تکمیل این بررسی، ۸ KPI تماس‌های خروجی که هر مدیر مرکز تماس باید اندازه‌گیری کند و گزارش روزانه تماس فروش؛ قالب و تعریف شاخص‌ها را در کنار نمونه‌های مجاز تیم خود ببینید. اگر مسئله شما ارزیابی مکالمه و گزارش مدیریتی است، بسته‌های تحلیل تماس و مسیر دریافت پیشنهاد از فروش را بررسی کنید. درباره تناسب هر قابلیت با این روال، پیش از خرید از تیم فروش توضیح و شاهد اجرایی بخواهید.
منبع تعریف محدود این راهنما: Zendesk: Business hours and holidays, Zendesk: Understanding ticket reply time. مثال‌ها و عددها آموزشی و ساختگی‌اند و نتیجه مشتری اپرا نیستند.
راهنماهای مرتبط با این مسئله
اختلاف تاریخ تماس بین دو گزارش؛ منطقه زمانی و مرز روز را کنترل کنیم و گزارش بر اساس تاریخ شروع یا پایان؟ دو نگاه به پرونده‌های تماس می‌توانند گام بعدی بررسی تیم شما باشند.