SLA چیست و چطور یک توافقنامه سطح خدمات درست تعریف کنیم؟
بیشتر SLAهایی که در قراردادها نوشته میشوند، هیچوقت اندازهگیری نمیشوند. یک بند حقوقیاند که همه امضا میکنند و کسی پیگیری نمیکند - تا روزی که مشتری عصبانی میشود و به آن استناد میکند. این مقاله درباره SLA بهعنوان ابزار مدیریت است، نه بند قرارداد.
محصول آماده کارن تکنولوژی
این را روی داده واقعی کسبوکار خودتان ببینید
آنچه در این مقاله میخوانید، در محصولات کارن پیادهسازی شده است. در جلسه دمو، همان را روی داده و فرآیند خودتان اجرا میکنیم.
درخواست دمو رایگان یا تماس بگیرید: ۰۲۱-۸۸۶۱۴۲۸۲در این صفحه
تعریف
SLA مخفف Service Level Agreement است: توافقنامه سطح خدمات. یک توافق مکتوب بین ارائهدهنده خدمت و دریافتکننده آن که مشخص میکند چه سطحی از خدمت، در چه زمانی، با چه تضمینی ارائه میشود.
در حوزه پشتیبانی مشتری، SLA معمولاً به دو سؤال پاسخ میدهد:
- چقدر طول میکشد تا جواب بگیرم؟ (زمان پاسخ)
- چقدر طول میکشد تا مشکلم حل شود؟ (زمان حل)
تفاوت SLA، SLO و OLA
این سه مرتب با هم اشتباه گرفته میشوند:
| تعریف | بین چه کسانی | ضمانت اجرا | |
|---|---|---|---|
| SLA | توافق رسمی سطح خدمت | شما و مشتری | معمولاً دارد (جریمه، تخفیف) |
| SLO | هدف داخلی سطح خدمت | داخل سازمان | ندارد؛ هدف است |
| OLA | توافق بین تیمهای داخلی | تیمهای داخل سازمان | داخلی |
و OLA نکتهای است که اغلب فراموش میشود: اگر به مشتری چهار ساعت تعهد دادهاید ولی تیم فنی داخلی هیچ تعهدی به تیم پشتیبانی ندارد، SLA شما روی هوا است.
اجزای یک SLA کامل
۱. دامنه خدمت
دقیقاً چه چیزی پوشش داده میشود و چه چیزی نه. مبهمترین بند اکثر SLAها همین است. «پشتیبانی نرمافزار» یعنی چه؟ آموزش کاربر جدید هم شاملش میشود؟
۲. سطوح اولویت
همه درخواستها یکسان نیستند. معمولاً سه تا چهار سطح تعریف میشود:
| سطح | تعریف | مثال |
|---|---|---|
| بحرانی | سرویس کاملاً از کار افتاده، بدون راهحل موقت | سایت فروشگاه بالا نمیآید |
| بالا | قابلیت مهمی مختل، با راهحل موقت | درگاه پرداخت گاهی خطا میدهد |
| متوسط | مشکل محدود، کار متوقف نشده | گزارش ماهانه اشتباه محاسبه میشود |
| پایین | درخواست اطلاعات یا تغییر جزئی | تغییر رنگ یک دکمه |
کلید کار: تعریف هر سطح باید آنقدر مشخص باشد که دو نفر مستقل به یک نتیجه برسند. «مهم» و «فوری» تعریف نیستند.
۳. زمان پاسخ و زمان حل
برای هر سطح، دو عدد جدا. و تفاوتشان مهم است: زمان پاسخ یعنی مشتری بفهمد شنیده شده؛ زمان حل یعنی مشکل تمام شود.
۴. ساعات پشتیبانی
۲۴×۷ یا ۸×۵؟ تعطیلات رسمی چطور؟ این بند مستقیماً روی بند بعدی اثر میگذارد.
۵. نحوه محاسبه زمان
این بند تعیینکنندهترین و در عین حال بیشترینبار حذفشدهترین بخش SLAهاست. در ادامه جداگانه به آن میپردازیم.
۶. مسیر تشدید (Escalation)
اگر SLA نقض شد یا مشکل حل نشد، به چه کسی میرسد و در چه زمانی؟
۷. استثناها
مواردی که SLA اعمال نمیشود: قطعی سراسری اینترنت، حوادث قهری، تأخیر ناشی از خود مشتری، تغییراتی که مشتری بدون هماهنگی انجام داده.
۸. گزارشدهی و جریمه
چطور و چند وقت یک بار گزارش داده میشود، و اگر نقض شد چه اتفاقی میافتد.
سه نکتهای که تفاوت SLA کاربردی و SLA تشریفاتی را میسازند
۱. ساعت کاری، نه ساعت دیوار
تیکتی که پنجشنبه ساعت ۹ شب ثبت میشود را در نظر بگیرید. اگر بر حسب ساعت دیوار بشمارید، شنبه صبح که تیم سر کار میآید، ۳۶ ساعت گذشته - بدون اینکه کسی کوتاهی کرده باشد.
SLA باید بر حسب تقویم کاری محاسبه شود: ساعات کاری هر تیم، تعطیلات رسمی، و در صورت لزوم تقویم متفاوت برای دپارتمانهای مختلف.
اگر سیستم شما این را پشتیبانی نمیکند، دو گزینه بد دارید: یا SLA بیمعنا میشود، یا مجبورید اعداد را آنقدر شل بگیرید که تعهدتان بیارزش شود.
۲. توقف تایمر وقتی توپ در زمین مشتری است
اپراتور از مشتری مدرک خواسته و مشتری سه روز جواب نداده. اگر تایمر در این سه روز بشمارد، تیم شما بهخاطر تأخیر مشتری تنبیه میشود.
SLA درست باید حالت «منتظر مشتری» داشته باشد که تایمر را متوقف کند و بهمحض پاسخ مشتری دوباره راه بیندازد.
۳. هشدار قبل از نقض، نه بعد از آن
SLAیی که فقط بعد از نقض شدن به شما خبر میدهد، یک گزارش است نه یک ابزار مدیریت. سیستم باید پیش از رسیدن به مهلت هشدار بدهد - معمولاً در ۷۵ درصد زمان - تا فرصت اقدام باقی بماند.
SLA شما در سند Word است یا در سیستم؟
در جلسه شناخت رایگان، سطوح اولویت و اعداد فعلی شما را مرور میکنیم و نشان میدهیم چطور به یک موتور فعال با هشدار پیش از نقض تبدیل میشوند.
نمونه جدول SLA
نمونهای که میتوانید نقطه شروع قرار دهید (اعداد را با ظرفیت واقعی خودتان تنظیم کنید):
| سطح اولویت | زمان اولین پاسخ | زمان حل | ساعات پوشش |
|---|---|---|---|
| بحرانی | ۳۰ دقیقه | ۴ ساعت | ۲۴×۷ |
| بالا | ۲ ساعت | ۸ ساعت کاری | ۸×۵ |
| متوسط | ۴ ساعت کاری | ۲ روز کاری | ۸×۵ |
| پایین | ۱ روز کاری | ۵ روز کاری | ۸×۵ |
و اگر مشتریان با اهمیت متفاوت دارید، میتوانید سطح خدمت را هم لایهبندی کنید:
| سطح | دسترسپذیری | زمان پاسخ | زمان حل | پوشش |
|---|---|---|---|---|
| طلایی | ۹۹.۹٪ | زیر ۳۰ دقیقه | زیر ۴ ساعت | ۲۴×۷ |
| نقرهای | ۹۹.۵٪ | زیر ۲ ساعت | زیر ۸ ساعت | ۸×۵ |
| برنزی | ۹۸٪ | زیر ۴ ساعت | زیر ۱۶ ساعت | ۸×۵ |
پنج اشتباه رایج
- تعهد به عددی که ظرفیتش را ندارید. SLA جاهطلبانهای که مرتب نقض میشود، بدتر از SLA محافظهکارانهای است که همیشه رعایت میشود. اول ظرفیت فعلیتان را اندازه بگیرید، بعد تعهد بدهید.
- تعریف مبهم اولویت. اگر تعریف سطوح مشخص نباشد، هر مشتری همه چیز را «بحرانی» میداند و اولویتبندی بیمعنا میشود.
- اندازهگیری دستی. SLAیی که با اکسل پیگیری میشود، در عمل پیگیری نمیشود. باید در همان سیستمی که تیکتها را مدیریت میکند، خودکار محاسبه شود.
- تمرکز فقط روی زمان پاسخ. پاسخ سریعِ بیفایده هنوز بیفایده است. زمان حل و کیفیت هم باید در تصویر باشد.
- SLA بدون OLA. اگر تعهد بیرونی دارید ولی تیمهای داخلی به هم تعهدی ندارند، اولین گلوگاه داخلی کل SLA را زمین میزند.
چطور شروع کنیم؟
- یک ماه فقط اندازه بگیرید. بدون هدفگذاری، ببینید امروز واقعاً چقدر طول میکشد.
- صدک ۹۰ را ملاک قرار دهید، نه میانگین. میانگین موارد بد را پنهان میکند. اگر ۹۰ درصد تیکتها زیر شش ساعت حل میشوند، شش ساعت نقطه شروع واقعبینانهای است.
- سطوح اولویت را با مثال تعریف کنید، نه با صفت.
- SLA را در سیستم پیاده کنید، نه در سند Word.
- ماهانه بازبینی کنید و اگر جایی مرتب نقض میشود، اول علتش را پیدا کنید - شاید مشکل از عدد نیست، از فرآیند است.
SLA در مانوتل
در مانوتل، SLA بهجای بند قرارداد، یک موتور فعال است: محاسبه بر حسب تقویم کاری شما، توقف خودکار تایمر وقتی منتظر مشتری هستید، هشدار پیش از نقض، تعریف SLA جداگانه برای هر شرکت یا سطح مشتری، و گزارش دقیق نرخ رعایت به تفکیک تیم و موضوع.
سیستم تیکتینگ مانوتل · چطور نرخ حل در اولین تماس را افزایش دهیم؟
پرسشهای متداول
SLA مخفف Service Level Agreement یا توافقنامه سطح خدمات است: یک توافق مکتوب بین ارائهدهنده خدمت و دریافتکننده آن که مشخص میکند چه سطحی از خدمت، در چه زمانی و با چه تضمینی ارائه میشود. در پشتیبانی مشتری معمولاً به دو سؤال پاسخ میدهد: چقدر طول میکشد تا جواب بگیرم (زمان پاسخ) و چقدر طول میکشد تا مشکلم حل شود (زمان حل).
SLA توافق رسمی سطح خدمت بین شما و مشتری است و معمولاً ضمانت اجرا دارد. SLO هدف داخلی سطح خدمت است و ضمانت اجرا ندارد. OLA توافق بین تیمهای داخلی سازمان است. قاعده عملی: SLO شما باید سختگیرانهتر از SLA باشد - اگر به مشتری چهار ساعت تعهد دادهاید، هدف داخلی باید سه ساعت باشد.
تیکتی که پنجشنبه ساعت ۹ شب ثبت میشود را در نظر بگیرید. اگر بر حسب ساعت دیوار بشمارید، شنبه صبح که تیم سر کار میآید ۳۶ ساعت گذشته - بدون اینکه کسی کوتاهی کرده باشد. SLA باید بر حسب تقویم کاری محاسبه شود: ساعات کاری هر تیم، تعطیلات رسمی و در صورت لزوم تقویم متفاوت برای دپارتمانهای مختلف.
خیر. اگر اپراتور از مشتری مدرک خواسته و مشتری سه روز جواب نداده، شمردن تایمر یعنی تیم شما بهخاطر تأخیر مشتری تنبیه میشود. SLA درست باید حالت «منتظر مشتری» داشته باشد که تایمر را متوقف کند و بهمحض پاسخ مشتری دوباره راه بیندازد.
یک نقطه شروع رایج: بحرانی با ۳۰ دقیقه اولین پاسخ و ۴ ساعت زمان حل در پوشش ۲۴×۷؛ بالا با ۲ ساعت پاسخ و ۸ ساعت کاری حل؛ متوسط با ۴ ساعت کاری پاسخ و ۲ روز کاری حل؛ و پایین با ۱ روز کاری پاسخ و ۵ روز کاری حل. این اعداد باید با ظرفیت واقعی خودتان تنظیم شوند.
تعهد به عددی که ظرفیتش را ندارید؛ تعریف مبهم اولویت که باعث میشود هر مشتری همه چیز را بحرانی بداند؛ اندازهگیری دستی با اکسل که در عمل پیگیری نمیشود؛ تمرکز فقط روی زمان پاسخ در حالی که پاسخ سریعِ بیفایده هنوز بیفایده است؛ و SLA بدون OLA، که با اولین گلوگاه داخلی زمین میخورد.
یک ماه فقط اندازه بگیرید و بدون هدفگذاری ببینید امروز واقعاً چقدر طول میکشد. صدک ۹۰ را ملاک قرار دهید نه میانگین، چون میانگین موارد بد را پنهان میکند. سطوح اولویت را با مثال تعریف کنید نه با صفت. SLA را در سیستم پیاده کنید نه در سند Word. و ماهانه بازبینی کنید؛ اگر جایی مرتب نقض میشود شاید مشکل از عدد نیست، از فرآیند است.
