فهرست مطالب
- SLA برای هر گروه درخواست دست‌کم دو مهلت دارد: زمان نخستین پاسخ و زمان حل.
- مهلت‌ها باید با تقویم کاری محاسبه شوند و در وضعیت‌های انتظار (مثل «منوط به اقدام مشتری») متوقف شوند.
- ارزش SLA در هشدار پیش از عبور از مهلت و مسیر ارتقای روشن است، نه در گزارش پایان ماه.
ثبت درخواست تنها نیمی از کار است؛ نیمهٔ دیگر، پاسخ به‌موقع است. SLA (Service Level Agreement) یا توافق سطح خدمت در سامانه تیکتینگ، مجموعه‌ای از قواعد است که مشخص می‌کند هر نوع درخواست در چه مدتی باید پاسخ داده و حل شود، زمان چگونه شمرده شود و اگر مهلت در خطر بود، چه کسی باید وارد عمل شود.
در این مقاله SLA را از نگاه فنی بررسی می‌کنیم: از ماتریس اولویت تا محاسبهٔ ساعت و فرمول شاخص‌ها.
مؤلفه‌های یک قاعدهٔ SLA
| مؤلفه | شرح |
|---|---|
| دامنهٔ شمول | کدام تیکت‌ها مشمول قاعده‌اند (دسته‌بندی، کانال، گروه مشتری) |
| هدف نخستین پاسخ | حداکثر زمان از ثبت تا اولین پاسخ معنادار به درخواست‌کننده |
| هدف حل | حداکثر زمان از ثبت تا بسته‌شدن با پاسخ نهایی |
| تقویم | ساعات کاری، روزهای تعطیل و شیفت‌ها |
| وضعیت‌های توقف | وضعیت‌هایی که ساعت را متوقف می‌کنند |
| آستانهٔ هشدار | زمانی پیش از مهلت که هشدار ارسال می‌شود |
| مسیر ارتقا | نقش یا فردی که با نزدیک شدن یا عبور از مهلت مطلع می‌شود |
ماتریس اولویت: اثر × فوریت
انتخاب دلخواه اولویت توسط اپراتور، رایج‌ترین منشأ SLA بی‌اعتبار است. روش استاندارد، محاسبهٔ اولویت از دو بُعد است: اثر (چند نفر یا چه سطحی از کسب‌وکار درگیر است) و فوریت (چقدر سریع آسیب ایجاد می‌شود).
| اثر \ فوریت | فوریت بالا | فوریت متوسط | فوریت کم |
|---|---|---|---|
| اثر گسترده (سرویس متوقف) | بحرانی | بالا | متوسط |
| اثر محدود (یک گروه) | بالا | متوسط | پایین |
| اثر فردی | متوسط | پایین | پایین |
سپس برای هر سطح اولویت، اهداف زمانی تعریف می‌شود. مقادیر دقیق به نوع سازمان بستگی دارد و باید از دادهٔ واقعی چند هفتهٔ اول استخراج و اصلاح شود.
محاسبهٔ ساعت SLA
تقویم کاری
اگر مرکز پاسخ‌گویی فقط در ساعات اداری فعال است، تیکتی که ساعت ۱۹ ثبت می‌شود نباید شبانه زمان مصرف کند. ساعت SLA باید فقط در بازه‌های کاری تعریف‌شده جلو برود و تعطیلات رسمی را در نظر بگیرد. برای سرویس‌های ۲۴ساعته، تقویم جداگانه تعریف می‌شود.
وضعیت‌های توقف
وقتی ادامهٔ کار به درخواست‌کننده وابسته است، مثلاً در وضعیت «منوط به اقدام مشتری»، ساعت باید متوقف شود و با بازگشت تیکت به جریان، از همان نقطه ادامه یابد. در غیر این صورت تأخیر مشتری به حساب واحد پاسخ‌گو نوشته می‌شود.
بازگشایی
اگر تیکت بسته‌شده به دلیل اعتراض بازگشایی شود، باید سیاست روشنی داشت: ادامهٔ ساعت قبلی یا شروع چرخهٔ جدید. هر کدام انتخاب شود، باید در همهٔ گزارش‌ها یکسان اعمال شود.
نکتهٔ فنی: «نخستین پاسخ» را دقیق تعریف کنید. پاسخ خودکار سامانه یا تغییر وضعیت بدون پیام، نباید نخستین پاسخ حساب شود؛ وگرنه این شاخص همیشه صددرصد و بی‌معنا خواهد بود.
هشدار و ارتقا
ارزش واقعی SLA در پیشگیری است. یک طرح متداول هشدار:
- آستانهٔ اول (مثلاً با مصرف بخش عمدهٔ زمان مجاز): هشدار به مالک تیکت.
- آستانهٔ دوم (نزدیک مهلت): هشدار به سرپرست گروه و برجسته شدن تیکت در داشبورد.
- عبور از مهلت: انتقال تیکت به فهرست معوق‌ها، اطلاع به مدیر و امکان تخصیص مجدد.
هر سطح هشدار باید نقش مسئول مشخصی داشته باشد؛ هشدار بدون مسئول، فقط یک عدد قرمز روی داشبورد است.
شاخص‌ها و نحوهٔ محاسبه
| شاخص | محاسبه | کاربرد |
|---|---|---|
| نرخ رعایت SLA | تعداد تیکت‌های بسته‌شده در مهلت ÷ کل تیکت‌های بسته‌شده | شاخص اصلی تعهد خدمت |
| میانگین زمان نخستین پاسخ | میانگین (زمان نخستین پاسخ − زمان ثبت) با ساعت کاری | تجربهٔ درخواست‌کننده |
| میانگین زمان حل | میانگین (زمان بسته‌شدن − زمان ثبت − زمان توقف) | کارایی واحدها |
| صدک ۹۰ زمان حل | زمانی که ۹۰ درصد تیکت‌ها زودتر از آن حل شده‌اند | دیدن دنبالهٔ تأخیرها که میانگین پنهان می‌کند |
| تیکت‌های معوق | تعداد تیکت‌های باز که از مهلت گذشته‌اند | نیاز به اقدام فوری |
| نرخ بازگشایی | تیکت‌های بازگشایی‌شده ÷ تیکت‌های بسته‌شده | کیفیت پاسخ؛ بستن زودهنگام را آشکار می‌کند |
| حل در اولین تماس | تعاملات حل‌شده بدون تیکت ÷ کل تعاملات | کیفیت پاسخ اپراتور و پایگاه دانش |
میانگین به‌تنهایی گمراه‌کننده است: چند تیکت بسیار طولانی ممکن است پشت میانگینی قابل قبول پنهان شوند. صدک ۹۰ و تعداد معوق‌ها تصویر واقعی‌تری می‌دهد.
داشبورد SLA
داشبورد مدیریتی باید در یک صفحه پاسخ این پرسش‌ها را بدهد: الان چند تیکت معوق داریم؟ کدام واحد بیشترین تأخیر را دارد؟ کدام موضوع بیشترین تیکت را می‌سازد؟ روند هفته‌های اخیر بهتر شده یا بدتر؟ امکان انتخاب بازهٔ زمانی و صف، و خروجی Excel برای بررسی دقیق‌تر، از الزامات آن است.
اشتباهات رایج
- یک مهلت برای همه: درخواست بحرانی و پرسش ساده در یک صف و با یک مهلت.
- ساعت ۲۴ساعته برای واحد اداری: شب‌ها و تعطیلات به حساب واحد نوشته می‌شود.
- نداشتن توقف ساعت: تأخیر درخواست‌کننده، شاخص واحد را خراب می‌کند.
- اولویت دلخواه: همه‌چیز «فوری» ثبت می‌شود و اولویت معنای خود را از دست می‌دهد.
- بستن برای آمار: تیکت بدون حل واقعی بسته می‌شود؛ نرخ بازگشایی این را نشان می‌دهد.
- هشدار بدون ارتقا: هشدار هست اما کسی مسئول اقدام نیست.
گام‌های پیاده‌سازی
- دسته‌بندی درخواست‌ها و فرایندهای رسیدگی را نهایی کنید.
- ماتریس اثر × فوریت و سطوح اولویت را تعریف کنید.
- تقویم کاری و وضعیت‌های توقف را در سامانه تنظیم کنید.
- اهداف اولیه را تعریف و آستانه‌های هشدار و مسیر ارتقا را مشخص کنید.
- چند هفته داده جمع کنید و اهداف را بر اساس عملکرد واقعی اصلاح کنید.
- بازبینی ماهانهٔ شاخص‌ها را در جلسهٔ مدیریتی جا بیندازید.
جمع‌بندی
SLA، تیکتینگ را از یک صندوق درخواست به یک تعهد قابل اندازه‌گیری تبدیل می‌کند؛ به شرط آنکه زمان درست شمرده شود، اولویت از قاعده بیاید و هشدارها مسئول داشته باشند.
در سامانه تیکتینگ ساعیان ارتباط، برای هر گروه درخواست، اولویت، مهلت پاسخ‌گویی و سطح خدمت تعریف می‌شود و درخواست‌های معوق در داشبورد هشدار داده می‌شوند. برای آشنایی با ساختار کلی سامانه، مقالهٔ سامانه تیکتینگ چیست را ببینید.
