ممکن است تیم پشتیبانی به یک شکایت در پنج دقیقه جواب بدهد، اما مشکل مشتری سه روز بعد حل شود. اگر فقط عدد پنج دقیقه را گزارش کنید، وضعیت واقعی پرونده دیده نمی‌شود. زمان پاسخ اولیه و زمان حل شکایت دو بخش متفاوت از تجربه مشتری را اندازه می‌گیرند. برای استفاده درست از آن‌ها باید نقطه شروع، پایان، توقف ساعت و معنای «حل شدن» را روشن کنید.
- زمان پاسخ اولیه معمولاً فاصله ثبت درخواست مشتری تا نخستین پاسخ عمومی از طرف تیم پشتیبانی است.
- زمان حل شکایت از ثبت مسئله تا زمانی ادامه دارد که مشکل واقعاً رفع یا پرونده طبق تعریف روشن بسته شود.
- فرض کنید شکایت ساعت ۱۰ دوشنبه ثبت میشود.
- زمان پاسخ اولیه نشان می‌دهد مشتری چه مدت برای دیده شدن و دریافت نخستین راهنمایی منتظر مانده است.
زمان پاسخ اولیه از کجا تا کجاست؟
زمان پاسخ اولیه معمولاً فاصله ثبت درخواست مشتری تا نخستین پاسخ عمومی از طرف تیم پشتیبانی است. این پاسخ باید برای مشتری قابل مشاهده باشد و به مسئله او مربوط شود. پیام خودکار «درخواست شما دریافت شد» را نباید بی‌توضیح معادل پاسخ انسانی حساب کرد. اگر چنین پیامی در گزارش جداگانه شمرده میشود، نام شاخص باید آن را روشن کند.
در مستندات Zendesk درباره شاخص‌های زمانی، «first reply time» از ایجاد تیکت تا نخستین پاسخ عمومی کارشناس سنجیده میشود. این تعریف به ابزار همان شرکت مربوط است؛ سامانه دیگری ممکن است ساعت کاری یا نوع پیام را متفاوت تنظیم کند. بنابراین پیش از مقایسه دو گزارش، تعریف فنی هر دو را بخوانید. عددی با واحد ساعت کاری را با عدد ساعت تقویمی یکسان نگیرید.
اگر مشتری ساعت ۲۲ پیام دهد و تیم ساعت ۹ صبح پاسخ بدهد، فاصله تقویمی یازده ساعت است. در گزارشی که فقط ساعات کاری را حساب می‌کند، عدد می‌تواند کمتر باشد. هیچ‌کدام ذاتاً غلط نیستند، اما باید با برچسب درست گزارش شوند. مشتری ممکن است تنها فاصله واقعی را تجربه کند، در حالی که مدیر برای برنامه‌ریزی شیفت به ساعت کاری نیاز دارد.
زمان حل شکایت چه زمانی تمام میشود؟
زمان حل شکایت از ثبت مسئله تا زمانی ادامه دارد که مشکل واقعاً رفع یا پرونده طبق تعریف روشن بسته شود. پاسخ اولیه فقط آغاز گفت‌وگو است. اگر کالا هنوز جایگزین نشده، وجه هنوز برگشت نخورده یا نقص فنی پابرجاست، ارسال یک پیام مودبانه مشکل را حل نکرده است. تعریف پایان باید با نوع خدمت سازگار باشد.
در همان فهرست شاخص‌های پشتیبانی Zendesk، زمان نخستین حل و زمان حل کامل از هم جدا شده‌اند. این تمایز زمانی مهم است که پرونده پس از بسته شدن دوباره باز شود. اگر تنها نخستین بستن را ثبت کنید، ممکن است اصلاح ناقص به‌صورت موفقیت زودهنگام دیده شود. برای شکایت‌های تکراری یا پیچیده، زمان حل نهایی را نیز گزارش کنید.
برای نمونه، مشتری از دستگاه خراب شکایت می‌کند. کارشناس همان روز پاسخ می‌دهد، روز بعد روش عیب‌یابی می‌فرستد و سه روز بعد دستگاه جایگزین میشود. پاسخ اولیه همان روز ثبت میشود؛ حل واقعی را باید با تاریخ جایگزینی یا تأیید رفع مشکل بسنجید. بستن تیکت هنگام ارجاع به انبار، اگر هنوز کاری باقی مانده، تصویری ناقص از زمان حل می‌دهد.
یک مثال عددی تفاوت دو شاخص را چگونه نشان می‌دهد؟
فرض کنید شکایت ساعت ۱۰ دوشنبه ثبت میشود. کارشناس ساعت ۱۰:۱۵ همان روز نخستین پاسخ عمومی را می‌دهد. مشکل پس از بررسی فنی و تأیید مشتری، ساعت ۱۴ چهارشنبه رفع میشود. زمان پاسخ اولیه ۱۵ دقیقه است و زمان حل در ساعت تقویمی ۵۲ ساعت. این دو عدد پاسخ دو پرسش متفاوت‌اند.
اکنون فرض کنید مشتری چهارشنبه شب اعلام کند مشکل برگشته است. اگر تیکت دوباره باز شود و پنجشنبه عصر حل نهایی ثبت شود، نخستین حل و حل کامل فاصله متفاوتی خواهند داشت. در گزارشی که فقط بسته شدن اولیه را می‌بیند، این تجربه دوباره‌کاری پنهان می‌ماند. برای تصمیم‌گیری، کنار میانگین زمان حل، تعداد پرونده‌های دوباره بازشده را هم ببینید.
مثال را باید با تعریف ساعت محاسبه همراه کرد. اگر فقط ساعات کاری ۹ تا ۱۷ شمرده می‌شوند، ۵۲ ساعت تقویمی به عدد دیگری تبدیل میشود. همچنین زمانی که تیم منتظر اطلاعات ضروری مشتری است ممکن است در برخی گزارش‌ها جدا شود. این توقف باید با وضعیت مشخص، زمان شروع و پایان ثبت شود. تغییر وضعیت صوری برای کوتاه کردن عدد، کیفیت گزارش را از بین می‌برد.
هر شاخص چه بخشی از تجربه مشتری را می‌سنجد؟
زمان پاسخ اولیه نشان می‌دهد مشتری چه مدت برای دیده شدن و دریافت نخستین راهنمایی منتظر مانده است. زمان حل نشان می‌دهد تا رفع مسئله چقدر زمان گذشته است. مشتری می‌تواند از پاسخ سریع راضی باشد اما از حل طولانی ناراضی بماند. برعکس، ممکن است مشکل سریع رفع شود ولی نبود اطلاع‌رسانی اولیه احساس رها شدن ایجاد کند.
برای شکایت درباره قطع خدمت، پاسخ اولیه می‌تواند شامل تأیید مشکل، اقدام موقت و زمان به‌روزرسانی بعدی باشد. چنین پاسخی حتی اگر راه‌حل نهایی حاضر نیست، به مشتری می‌گوید درخواستش دیده شده است. اما اگر کارشناس فقط یک متن آماده بفرستد و پرونده روزها بی‌پیشرفت بماند، بهبود شاخص پاسخ اولیه به معنی حل بهتر نیست. متن پاسخ و اقدام بعدی باید با هم بررسی شوند.
در شکایت درباره مرجوعی کالا، زمان حل ممکن است به دریافت بسته، بررسی کالا و انتقال وجه وابسته باشد. بخش‌هایی از مسیر خارج از اختیار کارشناس پاسخ‌گوست، ولی برای مشتری بخشی از همان تجربه است. گزارش داخلی می‌تواند زمان هر مرحله را جدا کند تا گلوگاه معلوم شود. با این کار مدیر می‌فهمد تأخیر در پاسخ‌گویی، انبار یا فرآیند مالی رخ داده است.
چرا میانگین تنها می‌تواند گمراه‌کننده باشد؟
اگر بیشتر شکایت‌ها در یک روز حل شوند اما چند پرونده حساس چند هفته باز بمانند، میانگین به‌تنهایی تجربه گروه دوم را پنهان می‌کند. بهتر است در کنار میانگین، میانه و سهم پرونده‌های فراتر از مهلت هدف را ببینید. توزیع زمان‌ها نشان می‌دهد مشکل عمومی است یا در نوع خاصی از شکایت متمرکز شده است.
همچنین پاسخ اولیه بسیار سریع ممکن است نتیجه پیام‌های کوتاه و غیرکمک‌کننده باشد. اگر هدف تیم فقط کاهش عدد باشد، کارشناس وسوسه میشود بدون خواندن کامل مسئله، پاسخی کلی بفرستد. برای ارزیابی منصفانه، نمونه‌ای از پاسخ‌ها را از نظر ارتباط با درخواست، وضوح گام بعد و دقت بررسی کنید. سرعت زمانی ارزش دارد که مشتری واقعاً بتواند مسیر رسیدگی را بفهمد.
گزارش باید شکایت‌های ساده و پیچیده را جدا نشان دهد. زمان حل پرسش درباره رمز عبور با زمان حل نقص محصولی که به تیم فنی می‌رود قابل مقایسه مستقیم نیست. گروه‌بندی بر اساس نوع مسئله، کانال دریافت و نیاز به ارجاع، دلیل تفاوت را روشن‌تر می‌کند. همچنین حجم پرونده‌های هر گروه را کنار عدد زمان بنویسید تا یک گروه کوچک تصویر کل را منحرف نکند.
چه رویدادهایی را در سامانه ثبت کنیم؟
برای محاسبه درست، زمان دریافت شکایت، نخستین پاسخ عمومی، هر تغییر وضعیت، ارجاع، درخواست اطلاعات از مشتری، اقدام حل و بسته شدن نهایی باید ثبت شود. هر رویداد باید زمان و مسئول داشته باشد. اگر پرونده در پیام‌رسان شروع و بعد به سامانه تیکت می‌رود، نقطه شروع را از اولین تماس واقعی مشتری بگیرید یا این تفاوت را اعلام کنید.
وضعیت «منتظر مشتری» را فقط وقتی به کار ببرید که اطلاعات مشخصی درخواست شده و ادامه کار بدون آن ممکن نیست. وقتی تیم منتظر پاسخ انبار یا همکار خود است، این وضعیت نباید به نام مشتری ثبت شود. بهتر است برای انتظار داخلی و خارجی وضعیت جدا داشته باشید. چنین تفکیکی از دست‌کاری ناخواسته زمان حل جلوگیری می‌کند و گلوگاه‌ها را قابل مشاهده نگه می‌دارد.
در راهنمای سنجش زمان پاسخ به پیام مشتری درباره ثبت زمان ورود و نخستین پاسخ توضیح داده‌ایم. برای شکایت، یک لایه دیگر نیز لازم است: ثبت شواهد رفع مسئله. این شواهد می‌تواند تأیید مشتری، شماره تراکنش بازپرداخت یا ثبت رفع عیب باشد. بسته به نوع خدمت، تعریف شواهد فرق می‌کند، اما باید پیش از تهیه گزارش مشخص باشد.
چگونه هدف زمانی واقع‌بینانه تعیین کنیم؟
ابتدا داده چند هفته را با تعریف یکسان جمع کنید. ببینید در چه ساعت‌ها و کانال‌هایی درخواست بیشتر می‌رسد و کدام نوع شکایت زمان‌بر است. سپس هدف پاسخ اولیه و حل را جدا تعیین کنید. هدفی که با ساعت کاری، تعداد کارکنان و پیچیدگی پرونده‌ها سازگار نباشد، فشار برای بستن صوری تیکت ایجاد می‌کند.
برای شکایت ساده می‌توان هدف کوتاه‌تری گذاشت، اما پرونده نیازمند بررسی فنی یا تأمین قطعه باید زمان‌بندی متفاوتی داشته باشد. در هر دو حالت، زمان به‌روزرسانی مشتری را نیز تعیین کنید. مشتری نباید تا پایان حل بی‌خبر بماند. اگر وعده حل در دو روز داده‌اید و تأخیر پیش می‌آید، اطلاع‌رسانی زودهنگام و توضیح گام بعد از یک پیام آماده در پایان مهلت مفیدتر است.
هدف‌ها را دوره‌ای بازنگری کنید. تغییر حجم فروش، تعطیلی‌ها یا اختلال گسترده ممکن است الگوی شکایت را عوض کند. در گزارش، سهم پرونده‌های داخل هدف و خارج از آن را همراه با علت تأخیر نشان دهید. از مقایسه تیم‌ها بدون توجه به نوع پرونده‌ها پرهیز کنید. یک تیم که شکایت‌های پیچیده را حل می‌کند ممکن است زمان بالاتری داشته باشد، اما کار دشوارتری انجام دهد.
گزارش مدیریتی خوب چه شکلی دارد؟
گزارش کوتاه باید هر دو شاخص را با تعریف، واحد و بازه زمانی مشخص نشان دهد. تعداد شکایت‌ها، میانه پاسخ اولیه، میانه حل، سهم پرونده‌های فراتر از هدف و موارد بازگشایی‌شده را کنار هم بگذارید. اگر فقط یک عدد کلی ارائه شود، تصمیم‌گیرنده نمی‌فهمد باید پاسخ‌گویی را تقویت کند یا مرحله حل را اصلاح کند.
پس از دیدن عدد، چند پرونده نمونه را بخوانید. آیا تأخیر به علت نبود اطلاعات محصول بوده است؟ آیا پاسخ اولیه درباره مسئله مشتری بوده یا فقط تأیید دریافت؟ آیا حل در سامانه ثبت شده ولی مشتری هنوز مشکل دارد؟ در مطلب استفاده از پرسش‌های مشتری برای بهبود صفحه محصول نیز نمونه‌ای از تبدیل داده پشتیبانی به اصلاح اطلاعات ارائه شده است. گزارش زمانی وقتی مفید است که به اقدام مشخص برسد.
در پایان، روند را در چند بازه پشت سر هم ببینید. کاهش ناگهانی زمان حل ممکن است بهبود واقعی باشد یا حاصل تغییر تعریف «بسته شدن». هر تغییر در روش محاسبه را کنار نمودار ثبت کنید. اگر شاخص‌ها بهتر شده‌اند اما شکایت تکراری و بازگشایی پرونده بالا رفته است، نتیجه را دوباره بررسی کنید. کیفیت حل باید با داده زمان و بازخورد مشتری سنجیده شود.
زمان پاسخ اولیه تا نخستین پاسخ قابل مشاهده را می‌سنجد؛ زمان حل تا رفع و بستن واقعی شکایت ادامه دارد. تعریف ساعت کاری، وضعیت انتظار و بازگشایی پرونده بر عددها اثر می‌گذارد. هر دو شاخص را با واحد و تعریف روشن، همراه با کیفیت پاسخ و شواهد حل گزارش کنید تا اقدام درست از داده به دست آید.
آیا پیام خودکار پاسخ اولیه محسوب میشود؟
بستگی به تعریف سامانه دارد، اما برای سنجش پاسخ کارشناس بهتر است پیام خودکار را جدا گزارش کنید. در غیر این صورت عدد ممکن است تجربه واقعی مشتری را نشان ندهد.
اگر مشتری دیر جواب دهد، زمان حل چگونه حساب میشود؟
زمان تقویمی همچنان میگذرد، مگر گزارش شما وضعیت انتظار مشتری را جدا کند. شروع و پایان انتظار را ثبت و روش محاسبه را در گزارش توضیح دهید.
آیا بستن تیکت به معنی حل شکایت است؟
نه همیشه. اگر مشکل پابرجا باشد یا مشتری پرونده را دوباره باز کند، زمان نخستین بستن با زمان حل نهایی فرق دارد. معیار حل را پیشاپیش مشخص کنید.
- Zendesk، تعریف شاخص‌های زمانی پاسخ و حل در سامانه پشتیبانی.
- Zendesk، فهرست و تفاوت شاخص‌های نخستین حل و حل کامل.
