راهنمای آناما
دسته‌ها

مدیریت صف تیکت و تعهد پاسخ‌گویی

تیکت‌های فوری، بدون مسئول یا گذشته از موعد را اولویت‌بندی کنید، بازگشایی و رضایت را بررسی کنید و مقالهٔ دانش را بازبینی کنید.

میزکار «پشتیبانی مشتری» در /panel/erp/customer_service تیکت‌های نزدیک به نقض SLA، بدون مسئول، بازگشایی‌شده، دارای رضایت پایین و مقاله‌های دانش در انتظار بازبینی را کنار هم می‌گذارد. این صفحه برای تقسیم کار و پیدا کردن موردهای در معرض تأخیر است؛ پاسخ به مشتری، تغییر وضعیت تیکت، ارجاع، ثبت علت و بستن پرونده باید در خود تیکت انجام شود.

ماژول پشتیبانی در وضعیت Beta است. زمان‌های SLA و صف‌ها به تنظیمات ثبت‌شده و وضعیت تیکت وابسته‌اند. وضعیت «منتظر مشتری» در بعضی جریان‌ها می‌تواند ساعت حل را متوقف کند؛ قبل از مقایسهٔ تأخیرها این پرچم را بخوانید. تعداد یا میانگین این صفحه نیز فقط بر داده‌های قابل دسترسی نقش شما استوار است.

معنی شاخص‌های بالای صفحه

  • تیکت باز و بدون مسئول: تعداد پرونده‌های حل‌نشده، و بخشی که کارشناس به آن‌ها تخصیص ندارد.
  • فوری: تیکت‌هایی که اولویتشان فوری ثبت شده است؛ شدت واقعی را هم از شرح و اثر روی مشتری بسنجید.
  • پاسخ اول عقب‌افتاده / حل عقب‌افتاده: دو مهلت جدا هستند. پاسخ‌دادن به مشتری الزاماً به معنی حل مشکل نیست و حل عملیاتی بدون پاسخ اولیه هم تعهد پاسخ را برآورده نمی‌کند.
  • بازگشایی‌شده: پرونده‌هایی که بعد از بسته‌شدن دوباره باز شده‌اند. علت بازگشایی و پاسخ قبلی را بخوانید؛ آن را تیکت کاملاً تازه فرض نکنید.
  • رضایت مشتری ≤ ۲: پاسخ‌های امتیاز پایین در ۳۰ روز اخیر. عدد به تیکت‌های دارای امتیاز وابسته است و علت نارضایتی را به‌تنهایی توضیح نمی‌دهد.
  • میانگین رضایت ۳۰ روز: میانگین پاسخ‌های امتیازدار ثبت‌شده و تعداد همان پاسخ‌ها. اگر مقدار «—» است، امتیازی در محدودهٔ محاسبه موجود نیست؛ به معنی رضایت صفر نیست.

بخش «فشار صف‌ها» تعداد هر صف، موارد گذشته از موعد و فوری را نشان می‌دهد. بخش «بار کار کارشناسان» تعداد پروندهٔ هر مسئول و موارد دیرکرد را می‌آورد. از این دو برای توزیع کار استفاده کنید، اما پیش از جابه‌جایی تیکت، تخصص، مالکیت گفت‌وگو و ظرفیت واقعی فرد را در نظر بگیرید.

مرور و رسیدگی به تیکت

در هر ردیف شمارهٔ پرونده، عنوان، مشتری، صف، مسئول، اولویت، موعد پاسخ اول و حل، وضعیت توقف SLA، تعداد بازگشایی و سطح ارجاع نمایش داده می‌شود. برای شروع:

  1. تیکت فوری یا گذشته از موعد را باز کنید و آخرین پیام و تعهدی را که به مشتری داده شده بخوانید.
  2. اگر مسئول ندارد، آن را به صف و کارشناس مرتبط تخصیص دهید؛ از تخصیص صوری برای حذف هشدار خودداری کنید.
  3. اگر پاسخ اول از موعد گذشته، پاسخ روشن و مرتبط با سؤال مشتری بدهید. اگر پاسخ نهایی ندارید، وضعیت و زمان پیگیری بعدی را شفاف بنویسید.
  4. برای حل، مسئله را بازتولید یا منبع آن را پیدا کنید، اقدام انجام‌شده و نتیجه را ثبت کنید و سپس پرونده را طبق روال ببندید.
  5. اگر تیکت بازگشایی شده، علت اینکه پاسخ قبلی مسئله را حل نکرد بررسی کنید و همان سابقه را ادامه دهید.

فقط صف‌های دارای مجوز مشاهده در بخش‌های مرتبط دیده می‌شوند. خطا در بارگذاری صفحه، حالت انتظار و خالی بودن یک صف مفهوم یکسانی ندارند؛ در خطا پیام و گزینهٔ تلاش دوباره نمایش داده می‌شود.

پنج تب کارتابل

گذشته از موعد

این تب تیکت‌های نقض‌کنندهٔ مهلت پاسخ اول یا حل را می‌آورد. هر دو زمان را جداگانه بررسی کنید. اگر SLA paused دیده می‌شود، ساعت حل برای وضعیت فعلی متوقف است؛ این توقف را بدون بررسی علت، به‌منزلهٔ حل‌شدن پرونده نخوانید. ردیف را باز کنید و وضعیت واقعی انتظار مشتری، زمان‌بندی و آخرین پاسخ را ببینید.

بدون مسئول

تیکت‌های بازِ بدون کارشناس را نشان می‌دهد. صف، اولویت و حجم کار تیم را مقایسه و مسئول مناسب تعیین کنید. اگر پرونده به تخصص خاص نیاز دارد، آن را در صف درست بگذارید و زمینهٔ انتقال را در تیکت بنویسید تا مشتری مجبور به تکرار موضوع نشود.

بازگشایی‌شده

تعداد دفعات بازگشایی در کارت هر پرونده نمایش داده می‌شود. پیام اخیر مشتری را بخوانید و مشخص کنید علت، پاسخ ناقص، رفع موقت، مشکل تکراری یا انتظار برآورده‌نشده بوده است. پیش از بستن دوباره، مطمئن شوید راه‌حل نتیجه داده یا مشتری تأیید کرده است.

رضایت پایین

پرونده‌هایی را که در ۳۰ روز گذشته امتیاز ۲ یا کمتر گرفته‌اند نمایش می‌دهد. امتیاز را به‌عنوان نشانهٔ بررسی تجربهٔ مشتری بخوانید، نه ارزیابی کامل کارشناس. متن مکالمه و علت امتیاز را مطالعه و در صورت نیاز پیگیری جبرانی را در پرونده ثبت کنید.

بازبینی دانش

مقاله‌های دانشی در وضعیت بازبینی را با دسته، میزان دسترسی/visibility، مالک و زمان به‌روزرسانی نشان می‌دهد. بازبین باید صحت گام‌ها را با محصول و خطاهای واقعی تیکت‌ها تطبیق دهد؛ مقالهٔ پیش‌نویس را به‌عنوان پاسخ عمومی استفاده نکنید. پس از ویرایش، وضعیت انتشار یا بازبینی را در منبع مقالهٔ دانش پیگیری کنید.

تشخیص نقض SLA و تصعید

پروندهٔ باز را با ساعت ثبت‌شده، مهلت پاسخ اول و موعد حل مقایسه کنید. اگر سطح Escalation بیشتر از صفر است، سابقهٔ ارجاع و دلیل آن را بخوانید؛ افزایش سطح به‌تنهایی نمی‌گوید مشکل حل شده یا مدیر آن را دیده است. هنگام تصعید، خلاصه‌ای بنویسید که شامل اثر روی مشتری، کارهای انجام‌شده، سؤال باز، مالک فعلی و اقدام موردنیاز باشد.

اگر وضعیت «منتظر مشتری» است، ببینید چه اطلاعاتی درخواست شده و آخرین زمان پیگیری چه بوده است. توقف SLA نباید بهانه‌ای برای رهاکردن پرونده شود؛ زمان یادآوری و شرط ادامه را ثبت کنید. اگر موعد نمایش‌داده‌شده با سیاست قراردادی مشتری فرق دارد، تنظیمات صف و SLA را با مدیر پشتیبانی بررسی کنید.

یک نمونهٔ کار روزانه

ابتدای شیفت، تب «گذشته از موعد» را باز می‌کنید و دو تیکت می‌بینید: یکی پاسخ اولش دیر شده و دیگری موعد حلش گذشته اما SLA آن متوقف است. برای اولی آخرین پیام مشتری را بخوانید و پاسخ کاربردی بدهید؛ اگر راه‌حل کامل نیست، زمان و مسئول پیگیری بعدی را بنویسید. برای دومی، علت توقف ساعت و اطلاعات درخواستی از مشتری را بررسی کنید؛ اگر پاسخ مشتری رسیده، وضعیت را از انتظار خارج و کار حل را ادامه دهید. سپس صف بدون مسئول را مرور کنید، پرونده‌ها را به کارشناسان مناسب بسپارید و در پایان تیکت بازگشایی‌شده یا امتیاز پایین را برای یادگیری تیم تحلیل کنید.

مقالهٔ دانش و استفاده از پاسخ‌های تکراری

اگر چند تیکت یک مسئله را تکرار می‌کنند، موضوع، شرایط رخداد، نسخه/محیط و راه‌حل تأییدشده را جمع کنید و یک مقالهٔ قابل استفاده برای مشتری یا تیم بسازید. visibility را قبل از انتشار کنترل کنید تا یادداشت داخلی یا اطلاعات حساس برای مشتری نمایش داده نشود. برای اصلاح مقالهٔ در انتظار بازبینی، مالک و شواهد به‌روز را مشخص کنید؛ انتشار پاسخ تأییدنشده می‌تواند تعداد تیکت‌های بازگشایی‌شده را بالا ببرد.

خطاهای متداول

  • پرونده‌ای در صف نیست: فیلتر وضعیت، صف انتخاب‌شده و مجوز مشاهدهٔ تیکت‌ها را بررسی کنید؛ شاید پرونده خارج از scope نقش شماست.
  • تیکت بدون مسئول زیاد است: صف و حجم تیم را مقایسه کنید و تعیین مالک را در پرونده ثبت کنید؛ عدد داشبورد را با انتقال صوری کم نکنید.
  • SLA متوقف است: وضعیت انتظار، آخرین پیام و زمان پیگیری را کنترل کنید؛ توقف ساعت معادل رفع مشکل نیست.
  • پرونده با وجود پاسخ هنوز باز است: پاسخ اولیه و وضعیت حل دو مرحله‌اند. نتیجهٔ فنی، تأیید مشتری و فرایند بستن را جدا بررسی کنید.
  • میانگین رضایت نمایش داده نمی‌شود: پاسخ امتیازدار کافی در بازه وجود ندارد؛ نظرهای متنی را جدا بخوانید.
  • مقالهٔ دانش در صف بازبینی مانده: مالک، visibility، دسته و آخرین نسخه را بررسی و نتیجهٔ بازبینی را در منبع مقاله ذخیره کنید.

برای پرونده‌های فروش که به پرسش مشتری منجر می‌شوند، راهنمای میزکار CRM را ببینید. فهرست سایر بخش‌ها و مسیرهای ERP در راهنمای ERP آناما آمده است.

SLA پاسخ اول با SLA حل چه فرقی دارد؟

مهلت پاسخ اول، زمان واکنش اولیه به تیکت است؛ مهلت حل، زمان تعهد برای رسیدگی تا نتیجه است. کارشناس ممکن است در وقت مناسب پاسخ دهد و بعد برای رفع فنی از موعد حل عبور کند. برعکس، ممکن است تیم مشکل را در پشت‌صحنه حل کرده باشد ولی پاسخی برای مشتری نفرستاده باشد. به همین خاطر شمارنده‌های این دو جدا هستند و باید هرکدام را در فهرست «گذشته از موعد» بررسی کنید. موعدی که در ردیف می‌بینید را با صف و اولویت تیکت بسنجید.

وقتی برای ادامه به اطلاعات مشتری نیاز دارید، دقیقاً بگویید چه چیزی لازم است، چرا لازم است و تا چه زمانی پاسخ انتظار می‌رود. اگر وضعیت تیکت ساعت SLA را متوقف می‌کند، توقف را ثبت‌شده و موقت در نظر بگیرید؛ برای بازبینی دوباره یادآور بگذارید. وقتی پاسخ رسید، وضعیت را از انتظار خارج کنید تا ادامهٔ کار و مهلت حل دوباره روشن باشد. اگر SLA در صفحه تعریف نشده، شمارندهٔ sla_missing را جدی بگیرید و تنظیم صف/قواعد قرارداد را با مدیر پشتیبانی پیگیری کنید.

تحلیل بازگشایی و رضایت پایین

بازگشایی تیکت را به عنوان بازخورد روی کیفیت رفع مشکل بخوانید. متن اولین گزارش و آخرین پاسخ را کنار هم بگذارید و بررسی کنید راه‌حل فقط موقت بوده یا مشتری دستور انجام را نتوانسته اجرا کند. امتیاز ۲ یا کمتر در ۳۰ روز می‌تواند ناشی از طول زمان، توضیح نامفهوم یا نتیجهٔ نامطلوب باشد؛ علت را از مکالمه پیدا کنید و بعد آن را به بهبود پاسخ یا مقالهٔ دانش تبدیل کنید. امتیاز را مبنای سرزنش فرد نکنید، چون شاخص صفحه علت را جدا نمی‌کند.

اگر از یک خطا چند تیکت می‌آید، شناسهٔ مشکل، نسخه یا شرایط رخداد را با تیم محصول جمع کنید. مقالهٔ دانش عمومی باید فقط راه‌حل تأییدشده را منتشر کند و visibility آن پیش از انتشار کنترل شود. اطلاعات داخلی، دادهٔ مشتری یا گام خطرناک را در مقالهٔ قابل مشاهده برای همه قرار ندهید.

این راهنما مفید بود؟بازخورد شما به بهترشدن راهنما کمک می‌کند.
ارسال بازخورد