SLA چیست؟ توافقنامه سطح خدمات در پشتیبانی مشتری، با نمونه فارسی

SLA تعهد قابل اندازه‌گیری تیم به مشتری است، نه یک شعار. این راهنما دو عدد اصلی SLA، سطح‌بندی، نقش تقویم ایران و مسیر تشدید را با نمونه فارسی توضیح می‌دهد.

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

SLA بدون سطح‌بندی بر اساس اولویت و نوع مشتری واقعی نیست، و بدون ابزار اندازه‌گیری فقط یک ادعاست.

تقویم و ساعت کاری ایران باید در محاسبه SLA لحاظ شود، وگرنه عددها به مشتری تعهد اشتباه می‌دهند.

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

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

SLA به زبان ساده: تعهد قابل اندازه‌گیری

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

همین اندازه‌پذیری است که SLA را از بازاریابی جدا می‌کند. وقتی عددی روی کاغذ می‌آید، هم مشتری می‌داند چه انتظاری داشته باشد و هم تیم می‌داند بر چه اساسی قضاوت می‌شود. SLA خوب، انتظار مشتری را واقعی می‌کند و از تیم در برابر توقع‌های نامحدود محافظت می‌کند. SLA بد، یا عددی می‌دهد که تیم نمی‌تواند به آن برسد، یا آن‌قدر مبهم است که هیچ‌وقت نقض‌شده حساب نمی‌شود.

سه سطح مفهوم: SLA، SLO و OLA

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

رابطه این سه ساده است: OLAها و SLOهای داخلی باید طوری تنظیم شوند که در مجموع SLA بیرونی محقق شود. اگر به مشتری قول حل ظرف یک روز کاری داده‌اید اما تیم فنی داخلی هیچ تعهدی به پاسخ سریع ندارد، SLA بیرونی شما روی هواست. برای شروع لازم نیست هر سه را رسمی کنید؛ اما دانستن اینکه SLA بیرونی بدون تعهد داخلی پشتوانه ندارد، از همان ابتدا شما را از وعده‌های غیرقابل‌تحقق دور نگه می‌دارد.

دو عدد اصلی: زمان پاسخ اولیه و زمان حل

قلب هر SLA پشتیبانی دو عدد است و این دو عمداً از هم جدا نگه داشته می‌شوند. عدد اول زمان پاسخ اولیه است: از لحظه‌ای که درخواست ثبت می‌شود تا اولین پاسخ انسانی یا معنادار. عدد دوم زمان حل است: از ثبت تا بسته شدن واقعی مسئله. جدا نگه داشتن این دو مهم است، چون پاسخ سریعِ بی‌نتیجه و حل درستِ دیرهنگام دو شکست کاملاً متفاوت‌اند و درمان‌های متفاوتی می‌خواهند.

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

سطح‌بندی بر اساس اولویت و نوع مشتری (نمونه فارسی)

SLA یکسان برای همه درخواست‌ها واقعی نیست. قطعی کامل سرویس برای یک مشتری سازمانی و یک سؤال عمومی از یک بازدیدکننده نباید تعهد یکسان بگیرند. به همین دلیل SLA بر اساس اولویت و گاهی نوع مشتری سطح‌بندی می‌شود. یک نمونه ساده و قابل کپی برای یک کسب‌وکار کوچک ایرانی می‌تواند سه سطح داشته باشد.

سطح بحرانی، برای مواردی مثل قطعی سرویس یا خطای پرداخت که مشتری را کاملاً متوقف می‌کند: زمان پاسخ اولیه یک ساعت کاری و زمان حل تا پایان همان روز کاری. سطح مهم، برای مشکلاتی که کار مشتری را دشوار می‌کنند اما راه دور زدن دارند: زمان پاسخ اولیه چهار ساعت کاری و زمان حل تا دو روز کاری. سطح عادی، برای سؤال‌های عمومی و درخواست‌های غیرفوری: زمان پاسخ اولیه یک روز کاری و زمان حل تا سه روز کاری. این عددها نمونه‌اند، نه نسخه؛ باید با ظرفیت واقعی تیم شما تنظیم شوند. قاعده مهم این است که تعداد سطح‌ها را کم نگه دارید؛ سه سطح روشن بهتر از هفت سطحی است که هیچ‌کس به‌درستی به خاطر نمی‌سپارد. برای اینکه این سطح‌بندی در عمل کار کند، باید بتوان اولویت هر تیکت را در همان لحظه ثبت مشخص کرد، همان‌طور که در راهنمای سیستم تیکتینگ چیست درباره اجزای استاندارد تیکت گفته‌ایم.

ساعت کاری، تعطیلات و تقویم ایران

یک اشتباه پرهزینه این است که SLA را با زمان تقویمی ساده محاسبه کنیم، نه زمان کاری. اگر بگویید «ظرف چهار ساعت پاسخ می‌دهیم» و درخواستی ساعت ده شب جمعه بیاید، آیا واقعاً تا دو بامداد جمعه پاسخ خواهید داد؟ SLA واقعی بر اساس ساعت کاری تعریف می‌شود، نه ساعت دیواری. یعنی شمارش زمان فقط در بازه کاری تیم پیش می‌رود و بیرون از آن متوقف می‌ماند.

برای یک تیم ایرانی، این یعنی تقویم شمسی، تعطیلات رسمی و روزهای پنجشنبه و جمعه باید در محاسبه لحاظ شوند. ابزار پشتیبانی خارجی که تقویم و تعطیلات ایران را نمی‌شناسد، ممکن است SLA شما را اشتباه محاسبه کند و به تیم هشدار نقض بدهد در حالی که هنوز داخل تعهد هستید، یا برعکس. تنظیم درست ساعت کاری و تقویم، پیش‌شرط این است که عددهای SLA به مشتری تعهد درست بدهند، نه تعهد خیالی.

SLA بدون ابزار اندازه‌گیری فقط ادعاست

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

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

وقتی SLA نقض شد: مسیر تشدید

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

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

رابطه SLA با شاخص‌های رضایت

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

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

جمع‌بندی و نمونه بند قرارداد

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

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

پرسش‌های پرتکرار

SLA در پشتیبانی مشتری دقیقاً یعنی چه و چه عددهایی باید داشته باشد؟

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

تفاوت زمان پاسخ اولیه و زمان حل در SLA چیست؟

زمان پاسخ اولیه از ثبت درخواست تا اولین پاسخ معنادار است و زمان حل از ثبت تا بسته شدن واقعی مسئله. این دو جدا نگه داشته می‌شوند چون پاسخ سریعِ بی‌نتیجه و حل درستِ دیرهنگام دو شکست متفاوت‌اند و یک پیام خودکار «ثبت شد» را نباید پاسخ اولیه حساب کرد.

آیا برای یک تیم کوچک نوشتن SLA زود نیست؟

نه، اما لازم نیست پیچیده باشد. یک تیم کوچک می‌تواند با یک SLA داخلی ساده و سه سطح اولویت شروع کند تا انتظار تیم روشن شود، و بعد وقتی قرارداد سازمانی پیش آمد، SLA بیرونی رسمی بنویسد. شروع ساده بهتر از نبود هرگونه تعهد اندازه‌پذیر است.