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