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