یک درخواست حیاتی ساعت ۹ صبح ثبت میشود. زمان پاسخ ۳۰ دقیقه و زمان حل ۴ ساعت است. تا ساعت ۹:۲۰ هنوز Technician مشخص نشده، اما هیچکس متوجه نیست چون سیستم فقط هنگام Breach هشدار میدهد. وقتی SLA نقض شد، دیگر Escalation دیر انجام شده است.
طراحی درست SLA Escalation در ServiceDesk Plus یعنی قبل از رسیدن به Deadline، نشانههای نزدیکشدن به Breach را به اقدام تبدیل کنیم: Assign، Notify، Reassign، Escalate و در صورت لزوم اطلاع به مدیر یا گروه پشتیبان.
SLA فقط یک Timer نیست
در ServiceDesk Plus، SLA برای تعریف زمان Response و Resolution و شرایط Escalation استفاده میشود. ارزش واقعی SLA زمانی ایجاد میشود که با Priority، Request Type، Site، Group، Technician و Business Hour هماهنگ شود.
| بخش SLA | هدف | نمونه |
|---|---|---|
| Response Time | زمان شروع رسیدگی | ۳۰ دقیقه |
| Resolution Time | زمان حل درخواست | ۴ ساعت |
| Escalation Level 1 | هشدار اولیه | ۳۰ دقیقه قبل از Breach |
| Escalation Level 2 | افزایش سطح پاسخ | ۱۵ دقیقه قبل از Breach |
| Post-breach Action | مدیریت نقض واقعی | مدیر گروه + RCA |
Response Escalation و Resolution Escalation را جدا کنید
اگر Request هنوز Assign نشده، مشکل با موردی که Technician روی آن کار میکند ولی Resolution عقب افتاده متفاوت است. بنابراین Escalation باید برای Response و Resolution منطق جدا داشته باشد.
Response Escalation مناسب است وقتی:
- Request هنوز به Technician نرسیده است؛
- Queue بدون مالک مانده؛
- Assignment Rule درست عمل نکرده؛
- گروه مسئول ظرفیت کافی ندارد.
Resolution Escalation مناسب است وقتی:
- کار شروع شده اما Deadline نزدیک است؛
- Request منتظر Vendor یا کاربر مانده؛
- نیاز به Level 2/3 Support دارد؛
- Change یا Approval باعث تأخیر شده است.
Escalation چندمرحلهای بهتر از یک هشدار نهایی است
یک Email در لحظه Breach معمولاً ارزش عملی کمی دارد. بهتر است Escalation را مرحلهای طراحی کنید.
| مرحله | زمان | اقدام |
|---|---|---|
| Early Warning | ۵۰٪ زمان SLA | هشدار به Technician |
| Risk Warning | ۷۵٪ زمان SLA | هشدار به Group Lead |
| Critical Warning | ۹۰٪ زمان SLA | Reassign/Manager Notification |
| Breach | ۱۰۰٪ | Escalation رسمی + ثبت علت |
Business Hours را اشتباه تنظیم نکنید
یکی از رایجترین خطاها این است که SLA بر اساس ۲۴x۷ محاسبه شود، در حالی که تیم فقط ساعات اداری کار میکند؛ یا برعکس، سرویس بحرانی ۲۴x۷ باشد اما SLA روی Calendar اداری تعریف شود.
برای هر SLA باید مشخص باشد:
- Business Hours؛
- Holiday Calendar؛
- Site یا Region؛
- Support Shift؛
- Critical Service Window.
Priority را مستقیماً به SLA وصل نکنید مگر اینکه مدل Priority بالغ باشد
اگر Priority فقط بر اساس انتخاب دستی کاربر تعیین شود، SLA نیز ناپایدار میشود. بهتر است Impact و Urgency یا Ruleهای استاندارد، Priority را تعیین کنند و سپس SLA از Priority معتبر استفاده کند.
Escalation باید Action داشته باشد، نه فقط Notification
Notification بهتنهایی کافی نیست. در بعضی سناریوها باید با Business Rule یا Workflow اقدام واقعی انجام شود:
- تغییر Group؛
- Assign به Technician دیگر؛
- افزایش Priority؛
- اطلاع به Service Owner؛
- ایجاد Task؛
- Trigger کردن Integration خارجی.
چه Requestهایی باید SLA متفاوت داشته باشند؟
یک SLA واحد برای کل میزخدمت معمولاً باعث بیمعناشدن گزارشها میشود.
| نوع Request | رویکرد |
|---|---|
| Incident بحرانی | Response کوتاه + Escalation سریع |
| Service Request استاندارد | Resolution بر اساس Fulfillment |
| VIP Request | Response سریع با کنترل سوءاستفاده |
| Vendor-dependent | SLA داخلی + OLA/Vendor SLA |
| Change-related | Deadline وابسته به Change Window |
SLA، OLA و Vendor Commitment را از هم جدا کنید
SLA تعهد به کاربر یا مشتری است. OLA تعهد داخلی بین تیمهاست. اگر Resolution به شبکه، دیتابیس یا Vendor وابسته است، باید OLA یا قرارداد پشتیبان طوری طراحی شود که SLA نهایی قابل تحقق بماند.
برای مطالعه بیشتر، راهنمای SLA و OLA در سایت تخصصی ServiceDesk مدانت مفید است.
KPIهای مهم برای SLA Escalation
| KPI | معنا |
|---|---|
| SLA Compliance | درصد درخواستهای بدون Breach |
| Pre-breach Recovery | درصد درخواستهایی که بعد از Escalation قبل از Breach حل شدند |
| Escalation Volume | تعداد Escalationها در هر گروه |
| Repeated Breach | درخواستهای تکرارشونده با علت مشابه |
| Response Breach vs Resolution Breach | تفکیک ضعف Assignment از ضعف حل مسئله |
یک سناریوی پیشنهادی برای میزخدمت سازمانی
- Priority با Impact/Urgency تعیین شود.
- SLA بر اساس Priority و Service انتخاب شود.
- در ۶۰٪ زمان SLA هشدار Technician ارسال شود.
- در ۸۰٪، Group Lead مطلع شود.
- در ۹۰٪، Reassignment یا Manager Escalation انجام شود.
- در Breach، علت اجباری ثبت شود.
- Breachهای تکراری وارد Problem Management شوند.
نکات کلیدی
- Escalation باید پیش از Breach شروع شود.
- Response و Resolution دو مسیر جدا هستند.
- Business Hours و Holiday Calendar مستقیماً روی SLA اثر دارند.
- Notification بدون Action کافی نیست.
- SLA واحد برای همه Requestها معمولاً طراحی ضعیفی است.
- Breach تکراری باید به Problem یا Capacity Issue تبدیل شود.
منابع
سخن پایانی
SLA زمانی ارزشمند است که قبل از نقض، تیم را وادار به اقدام کند. ServiceDesk Plus امکان تعریف SLA، Response/Resolution Time و Escalation را میدهد، اما کیفیت نتیجه به طراحی Priority، Business Hours، OLA و Workflow بستگی دارد.
مدانت خدمات خرید و تمدید لایسنس ServiceDesk Plus، پیادهسازی، فارسیسازی، تقویم شمسی، سفارشیسازی و طراحی Workflow/SLA را ارائه میدهد. برای مقایسه Edition و مدل لایسنس نیز مقاله محاسبه لایسنس ServiceDesk Plus را ببینید.
