تصور کنید در ساعت شلوغ کاری، تماس‌های ورودی شرکت ناگهان با اختلال مواجه شوند. برخی مشتریان نمی‌توانند تماس بگیرند، کارشناسان از مشکل اطلاع دقیقی ندارند و مدیر مجموعه نیز نمی‌داند چه زمانی شرایط به حالت عادی برمی‌گردد.
در چنین موقعیتی، فقط پایداری فنی مرکز تماس اهمیت ندارد؛ نحوه شناسایی اختلال، اطلاع‌رسانی، پاسخ‌گویی پشتیبانی و امکان استفاده از مسیر جایگزین نیز تعیین‌کننده است.
SLA مرکز تماس یا توافق‌نامه سطح خدمات، چارچوبی برای مشخص کردن تعهدات قابل سنجش ارائه‌دهنده سرویس است. این توافق‌نامه می‌تواند موضوعاتی مانند دسترس‌پذیری، زمان پاسخ‌گویی پشتیبانی، نحوه رسیدگی به اختلال‌ها و مسئولیت طرفین را پوشش دهد.
اما وجود SLA به معنای تضمین نبود قطعی نیست. برای ارزیابی یک مرکز تماس ابری باید بدانید چه خدماتی تحت تعهد قرار دارند، اختلال چگونه تعریف می‌شود و هنگام بروز مشکل چه اتفاقی خواهد افتاد.
SLA مرکز تماس چیست؟
SLA مخفف Service Level Agreement و به معنای «توافق‌نامه سطح خدمات» است.
این توافق‌نامه مشخص می‌کند ارائه‌دهنده و مشتری درباره سطح ارائه خدمات، نحوه اندازه‌گیری عملکرد و مسئولیت‌های مرتبط با سرویس چه توافقی دارند.
در یک مرکز تماس ابری، SLA ممکن است شامل تعهدات مربوط به دسترس‌پذیری سامانه، خدمات پشتیبانی، مدیریت رخدادها و نحوه گزارش‌دهی باشد.
برای مثال، یک توافق‌نامه می‌تواند توضیح دهد که اگر مرکز تماس از دسترس خارج شود، اختلال از چه زمانی محاسبه می‌شود، چه کسی مسئول بررسی است و درخواست پشتیبانی چگونه پیگیری خواهد شد.
البته همه توافق‌نامه‌های سطح خدمات یکسان نیستند. ممکن است یک ارائه‌دهنده فقط تعهدات محدودی برای دسترس‌پذیری تعریف کند و ارائه‌دهنده دیگری دامنه گسترده‌تری از خدمات عملیاتی را در توافق‌نامه بگنجاند.
به همین دلیل، عنوان SLA به‌تنهایی کافی نیست؛ متن و محدوده تعهدات اهمیت دارد.
چه موضوعاتی باید در SLA مشخص باشند؟
یک توافق‌نامه شفاف، متناسب با خدمات مورد توافق، بهتر است به پرسش‌های زیر پاسخ دهد:
-
کدام بخش‌های سرویس تحت پوشش تعهدات هستند؟
-
دسترس‌پذیری چگونه تعریف و اندازه‌گیری می‌شود؟
-
چه شرایطی اختلال یا قطعی محسوب می‌شود؟
-
درخواست‌های پشتیبانی چگونه ثبت و اولویت‌بندی می‌شوند؟
-
زمان پاسخ‌گویی و رسیدگی چگونه تعیین می‌شود؟
-
مسئولیت اطلاع‌رسانی هنگام رخداد با چه کسی است؟
-
چه مواردی از محاسبات یا تعهدات مستثنا هستند؟
-
در صورت رعایت نشدن تعهدات، چه سازوکاری برای بررسی و جبران احتمالی پیش‌بینی شده است؟
وجود و جزئیات این موارد باید در قرارداد یا اسناد خدمات بررسی شود و نمی‌توان آن‌ها را برای تمام سرویس‌های ابری یکسان فرض کرد.
تفاوت SLA با ادعای پایداری سرویس چیست؟
عبارت‌هایی مانند «مرکز تماس پایدار» یا «زیرساخت قابل اعتماد» توصیف‌هایی کلی از ویژگی‌های مورد انتظار یک سرویس هستند.
این عبارت‌ها ممکن است به طراحی زیرساخت، کیفیت عملکرد یا تجربه استفاده از سامانه اشاره کنند، اما به‌تنهایی یک تعهد قابل اندازه‌گیری ایجاد نمی‌کنند.
در مقابل، SLA قرار است انتظارات را به شرایط و تعهداتی مشخص تبدیل کند.
| موضوع | ادعای پایداری | SLA |
|---|---|---|
| ماهیت | توصیف ویژگی یا کیفیت سرویس | توافق درباره سطح ارائه خدمات |
| قابلیت اندازه‌گیری | لزوماً دارای معیار مشخص نیست | باید معیارهای قابل سنجش داشته باشد |
| محدوده مسئولیت | ممکن است مبهم باشد | بر اساس مفاد توافق‌نامه تعیین می‌شود |
| شرایط اختلال | الزاماً توضیح داده نمی‌شود | می‌تواند نحوه رسیدگی و استثناها را مشخص کند |
| مبنای ارزیابی | توضیحات ارائه‌دهنده و تجربه عملی | معیارها و شرایط توافق‌شده |
برای مثال، اگر ارائه‌دهنده اعلام کند که مرکز تماس از زیرساخت پایدار استفاده می‌کند، هنوز مشخص نیست هنگام بروز اختلال چه تعهدی برای پاسخ‌گویی دارد.
اما اگر نحوه اندازه‌گیری دسترس‌پذیری، شرایط ثبت رخداد و مسئولیت پشتیبانی به‌صورت روشن در SLA آمده باشد، مشتری می‌تواند عملکرد سرویس را با مفاد توافق‌شده ارزیابی کند.
بنابراین، هنگام انتخاب مرکز تماس ابری باید هم ویژگی‌های عملیاتی سرویس و هم تعهدات مکتوب آن بررسی شوند.
دسترس‌پذیری یا Availability در مرکز تماس ابری یعنی چه؟
دسترس‌پذیری (Availability) نشان می‌دهد یک سرویس در چه بخشی از بازه ارزیابی، مطابق تعریف توافق‌شده، قابل استفاده بوده است.
در مرکز تماس ابری، دسترس‌پذیری می‌تواند به عملکرد بخش‌هایی مانند سامانه مدیریت تماس، امکان دریافت تماس، برقراری تماس خروجی یا دسترسی به امکانات مشخص اشاره داشته باشد.
اما یک نکته مهم وجود دارد: دسترس‌پذیری سامانه لزوماً با موفقیت همه تماس‌ها یا کیفیت مطلوب تمام مکالمات برابر نیست.
ممکن است پنل مدیریت مرکز تماس در دسترس باشد، اما به دلیل اختلال در یکی از مسیرهای ارتباطی، بخشی از تماس‌ها با مشکل مواجه شوند.
همچنین ممکن است سامانه ابری فعال باشد، اما کارشناس به دلیل اختلال اینترنت محل کار خود نتواند به آن متصل شود.
این وضعیت‌ها از نظر تجربه کاربر مشابه به نظر می‌رسند، اما علت و مسئولیت رسیدگی به آن‌ها یکسان نیست.
تفاوت قطعی کامل و اختلال جزئی
در ارزیابی پایداری باید میان قطعی کامل سرویس و اختلال بخشی از امکانات تفاوت قائل شد.
قطعی کامل زمانی رخ می‌دهد که سرویس موردنظر، مطابق تعریف فنی و قراردادی، به‌طور کلی از دسترس خارج شده باشد.
اختلال جزئی ممکن است تنها یکی از بخش‌های سامانه یا گروه مشخصی از کاربران را تحت تأثیر قرار دهد.
برای مثال، مرکز تماس ممکن است همچنان تماس ورودی دریافت کند، اما یک قابلیت مدیریتی یا مسیر خاص تماس به‌درستی کار نکند.
اینکه چنین وضعیتی در محاسبات SLA چگونه لحاظ شود، به تعریف سرویس و شرایط توافق‌نامه بستگی دارد.
چه اختلال‌هایی ممکن است رخ دهند؟
| سناریوی اختلال | اثر احتمالی بر کسب‌وکار | موضوعی که باید بررسی شود |
|---|---|---|
| اختلال در سامانه مرکز تماس | محدودیت در برقراری یا مدیریت تماس‌ها | محدوده تعهد دسترس‌پذیری |
| اختلال اینترنت شرکت | عدم اتصال برخی کارشناسان به سرویس | مسئولیت اتصال اینترنت و مسیر جایگزین |
| مشکل در مسیر ارتباط تلفنی | نرسیدن بخشی از تماس‌ها یا اختلال در مکالمه | مرز مسئولیت ارائه‌دهندگان مرتبط |
| اختلال در پنل مدیریت | محدودیت در مشاهده گزارش‌ها یا تغییر تنظیمات | تعریف اختلال جزئی در SLA |
| اختلال در کلاینت کاربر | مشکل در دریافت یا برقراری تماس توسط یک کارشناس | روش عیب‌یابی و تفکیک مشکل کاربر از سرویس |
برای هر سناریو باید مشخص شود منشأ مشکل کجاست و چه بخشی از آن تحت مسئولیت ارائه‌دهنده مرکز تماس قرار می‌گیرد.
پشتیبانی در SLA چه نقشی دارد؟
حتی در یک سامانه با طراحی مناسب نیز احتمال بروز اختلال وجود دارد. به همین دلیل، کیفیت خدمات پشتیبانی بخش مهمی از ارزیابی مرکز تماس ابری است.
برای کسب‌وکاری که تماس تلفنی یکی از کانال‌های اصلی ارتباط با مشتریانش محسوب می‌شود، مهم است بداند در زمان بروز مشکل چگونه می‌تواند درخواست پشتیبانی ثبت کند و چه فرایندی برای رسیدگی وجود دارد.
تفاوت زمان پاسخ و زمان رفع مشکل
یکی از موضوعاتی که هنگام بررسی SLA باید به آن توجه کرد، تفاوت میان زمان پاسخ‌گویی و زمان حل مشکل است.
زمان پاسخ‌گویی (Response Time): مدت‌زمانی است که طبق تعریف توافق‌شده، از ثبت یا شناسایی درخواست تا نخستین پاسخ معتبر تیم پشتیبانی سپری می‌شود.
زمان رفع یا حل مشکل (Resolution Time): مدت‌زمانی است که تا رفع مشکل بر اساس معیارهای توافق‌شده سپری می‌شود.
این دو مفهوم یکسان نیستند.
ممکن است تیم پشتیبانی درخواست را دریافت و بررسی اولیه را آغاز کرده باشد، اما برطرف کردن اختلال به اقدامات بیشتری نیاز داشته باشد.
بنابراین، تعهد به پاسخ‌گویی سریع لزوماً به معنای تعهد به رفع مشکل در همان بازه زمانی نیست.
همچنین باید مشخص شود آیا توافق‌نامه زمان رفع قطعی را تعهد می‌کند یا صرفاً هدف و فرایندی برای پیگیری آن تعیین کرده است.
اولویت‌بندی درخواست‌های پشتیبانی
همه درخواست‌ها تأثیر یکسانی بر فعالیت سازمان ندارند.
اختلالی که مانع دریافت تماس‌های اصلی شرکت می‌شود، معمولاً از نظر اثر کسب‌وکاری با مشکلی در نمایش یک گزارش مدیریتی متفاوت است.
به همین دلیل، در طراحی فرایند پشتیبانی می‌توان درخواست‌ها را بر اساس شدت و گستره اثر آن‌ها دسته‌بندی کرد.
هنگام بررسی خدمات پشتیبانی بهتر است مشخص شود سطح اهمیت هر رخداد چگونه تعیین می‌شود، درخواست‌ها از چه مسیرهایی ثبت می‌شوند و پیگیری آن‌ها در چه ساعات و شرایطی انجام خواهد شد.
مانیتورینگ و اطلاع‌رسانی رخدادها چه ارتباطی با پایداری دارند؟
مانیتورینگ یا پایش سرویس به معنای بررسی وضعیت عملکرد سامانه و شناسایی نشانه‌های اختلال است.
در یک مرکز تماس ابری، پایش می‌تواند بخش‌های مختلفی از زیرساخت و فرایند تماس را شامل شود؛ از وضعیت سرویس‌های اصلی گرفته تا عملکرد مسیرهای ارتباطی و برخی شاخص‌های تماس.
بااین‌حال، نوع پایش و جزئیات آن به ساختار فنی و امکانات ارائه‌دهنده بستگی دارد.
چرا مانیتورینگ اهمیت دارد؟
فرض کنید بخشی از تماس‌های ورودی یک مجموعه با مشکل مواجه شده‌اند، اما هنوز هیچ کاربری موضوع را گزارش نکرده است.
اگر سازوکار پایش مناسبی وجود داشته باشد، ممکن است نشانه‌های اختلال پیش از دریافت گزارش مشتری شناسایی شوند.
این موضوع می‌تواند به آغاز سریع‌تر بررسی مشکل کمک کند.
البته مانیتورینگ به معنای شناسایی قطعی همه اختلال‌ها نیست. برخی مشکلات ممکن است فقط در شرایط خاص، برای گروه محدودی از کاربران یا در مسیرهای مشخص رخ دهند.
به همین دلیل، گزارش کاربران و بررسی کیفیت تجربه تماس نیز در کنار پایش فنی اهمیت دارند.
اطلاع‌رسانی هنگام اختلال چگونه باید انجام شود؟
یکی از پرسش‌های مهم برای مشتری سازمانی این است که هنگام بروز اختلال گسترده، اطلاعات لازم چگونه در اختیار او قرار می‌گیرد.
بهتر است پیش از انتخاب سرویس مشخص شود آیا فرایندی برای اطلاع‌رسانی رخدادها وجود دارد و در صورت وجود، شامل چه اطلاعاتی می‌شود.
برای مثال، اطلاع‌رسانی می‌تواند وضعیت کلی رخداد، محدوده خدمات تحت تأثیر، اقدامات در حال انجام و تغییرات مهم وضعیت را پوشش دهد.
همچنین باید روشن باشد اطلاع‌رسانی خودکار انجام می‌شود یا مشتری باید از طریق پشتیبانی پیگیری کند.
مانیتورینگ و اطلاع‌رسانی زمانی ارزش بیشتری دارند که به اقدام عملی برای مدیریت رخداد متصل باشند، نه صرفاً نمایش وضعیت سامانه.
مسیر جایگزین تماس چه کمکی به تداوم سرویس می‌کند؟
مسیر جایگزین تماس یکی از راهکارهایی است که می‌تواند برای کاهش اثر برخی اختلال‌ها یا شرایط عدم دسترسی مورد استفاده قرار گیرد.
منظور از مسیر جایگزین این است که اگر شرایط تعریف‌شده‌ای برقرار شود، تماس به‌جای مقصد یا مسیر اولیه، به مقصد دیگری هدایت شود.
برای مثال، فرض کنید تماس‌های شرکت به یک گروه مشخص از کارشناسان می‌رسند. اگر مقصد اصلی در شرایط تعیین‌شده در دسترس نباشد، می‌توان در صورت پشتیبانی سیستم، مسیر دیگری برای هدایت تماس تعریف کرد.
این مسیر ممکن است شامل یک داخلی دیگر، گروه پاسخ‌گویی جایگزین یا مقصد مجاز دیگری باشد.
تفاوت مسیر جایگزین تماس با افزونگی زیرساخت
این دو مفهوم نباید با یکدیگر اشتباه گرفته شوند.
مسیر جایگزین تماس به تغییر مقصد یا مسیر هدایت تماس در شرایط مشخص اشاره دارد.
افزونگی زیرساخت (Redundancy) به وجود اجزای جایگزین در معماری فنی مربوط می‌شود تا در صورت خرابی یک جزء، امکان ادامه فعالیت از طریق جزء دیگر فراهم باشد.
وجود مسیر جایگزین تماس به‌تنهایی نشان نمی‌دهد که تمام اجزای شبکه، سرورها یا زیرساخت ارتباط تلفنی دارای افزونگی هستند.
همچنین مسیر جایگزین فقط زمانی مؤثر است که شرایط فعال‌سازی آن به‌درستی تعریف شده باشد و مقصد جایگزین واقعاً در دسترس قرار داشته باشد.
سناریوهای کاربردی مسیر جایگزین
برای طراحی تداوم پاسخ‌گویی می‌توان سناریوهایی مانند هدایت تماس در صورت عدم پاسخ داخلی اصلی، انتقال تماس‌ها به گروه دیگری در شرایط تعیین‌شده یا استفاده از مقصد جایگزین در ساعات مشخص را بررسی کرد.
اما نباید فرض کرد هر نوع اختلال زیرساختی الزاماً باعث فعال شدن مسیر جایگزین خواهد شد.
برای مثال، اگر بخشی از زیرساخت مسئول اجرای قواعد مسیریابی نیز از دسترس خارج شده باشد، ممکن است مسیر جایگزین طبق انتظار عمل نکند.
بنابراین، لازم است از ارائه‌دهنده پرسیده شود مسیر جایگزین در چه شرایطی فعال می‌شود، چه وابستگی‌هایی دارد و چگونه می‌توان عملکرد آن را آزمایش کرد.
نسخه پشتیبان تنظیمات و داده‌ها چرا اهمیت دارد؟
پایداری مرکز تماس فقط به برقراری تماس محدود نمی‌شود. اطلاعات و تنظیمات سامانه نیز برای ادامه فعالیت سازمان اهمیت دارند.
در یک مرکز تماس ممکن است داده‌هایی مانند ساختار داخلی‌ها، تنظیمات منشی تلفنی، قواعد مسیریابی، مخاطبان، گزارش تماس و فایل‌های ضبط مکالمات وجود داشته باشند.
این داده‌ها از نظر کاربرد و اهمیت یکسان نیستند و لزوماً با یک روش نگهداری یا پشتیبان‌گیری نمی‌شوند.
پشتیبان‌گیری از تنظیمات مرکز تماس
تنظیمات مرکز تماس مشخص می‌کنند تماس‌ها چگونه وارد سامانه شوند، به کدام داخلی یا صف برسند و در شرایط مختلف چه مسیری را طی کنند.
اگر این تنظیمات به دلیل خطا یا تغییر نامناسب از بین بروند، بازسازی دستی آن‌ها ممکن است زمان‌بر باشد.
وجود روش مشخص برای پشتیبان‌گیری و بازیابی تنظیمات می‌تواند در مدیریت چنین شرایطی مفید باشد.
پیش از انتخاب سرویس باید مشخص شود کدام تنظیمات قابل بازیابی هستند و مسئولیت تهیه و نگهداری نسخه پشتیبان با چه کسی است.
پشتیبان‌گیری از گزارش‌ها و فایل‌های ضبط مکالمه
گزارش‌های تماس و فایل‌های ضبط‌شده ممکن است برای پیگیری مشتریان یا بررسی کیفیت پاسخ‌گویی اهمیت داشته باشند.
بااین‌حال، وجود قابلیت ضبط مکالمه یا گزارش تماس لزوماً به معنای ارائه نسخه پشتیبان مستقل، نگهداری نامحدود یا امکان بازیابی همه اطلاعات نیست.
در این زمینه بهتر است مواردی مانند مدت نگهداری داده، امکان خروجی گرفتن، محدوده پشتیبان‌گیری و شرایط بازیابی به‌صورت دقیق بررسی شوند.
همچنین اگر اطلاعاتی از طریق اتصال CRM یا API به سامانه‌های دیگر منتقل می‌شوند، باید مسئولیت نگهداری و بازیابی آن اطلاعات در هر سامانه مشخص باشد.
تفاوت بکاپ با بازیابی موفق
تهیه نسخه پشتیبان فقط بخشی از فرایند حفاظت از داده‌هاست.
بخش مهم دیگر، امکان بازیابی اطلاعات در شرایط موردنیاز است.
بنابراین، بهتر است علاوه بر پرسیدن اینکه آیا بکاپ وجود دارد، درباره روش بازیابی، محدوده داده‌های قابل بازگردانی و فرایند آزمایش بازیابی نیز سؤال شود.
در برنامه‌ریزی تداوم کسب‌وکار، دو مفهوم دیگر هم می‌توانند مفید باشند:
RTO یا هدف زمان بازیابی: بازه زمانی هدف برای بازگرداندن سرویس پس از اختلال.
RPO یا هدف نقطه بازیابی: میزان فاصله زمانی داده‌هایی که ممکن است در فرایند بازیابی از دست بروند و سازمان آن را قابل قبول می‌داند.
این مفاهیم لزوماً بخشی از تمام SLAها نیستند و تنها در صورت توافق باید به‌عنوان تعهد ارائه‌دهنده در نظر گرفته شوند.
قبل از انتخاب مرکز تماس ابری چه سؤال‌هایی از ارائه‌دهنده بپرسیم؟
برای ارزیابی واقعی SLA مرکز تماس، بهتر است به‌جای تکیه بر توصیف‌های کلی، پرسش‌هایی مطرح کنید که پاسخ آن‌ها قابل بررسی باشد.
جدول زیر می‌تواند به‌عنوان راهنمای گفت‌وگو با ارائه‌دهنده سرویس استفاده شود.
| موضوع | سؤال مهم پیش از قرارداد |
|---|---|
| محدوده SLA | دقیقاً کدام بخش‌های مرکز تماس تحت پوشش توافق‌نامه هستند؟ |
| دسترس‌پذیری | دسترس‌پذیری سرویس چگونه محاسبه و گزارش می‌شود؟ |
| اختلال جزئی | اگر فقط بخشی از تماس‌ها یا امکانات دچار اختلال شوند، چه وضعیتی در SLA ثبت می‌شود؟ |
| استثناها | چه اختلال‌هایی از تعهدات دسترس‌پذیری مستثنا هستند؟ |
| پشتیبانی | خدمات پشتیبانی در چه روزها و ساعت‌هایی ارائه می‌شوند؟ |
| زمان پاسخ | زمان پاسخ‌گویی و زمان رفع مشکل چگونه تعریف و از یکدیگر تفکیک می‌شوند؟ |
| مدیریت رخداد | اختلال چگونه ثبت، اولویت‌بندی و پیگیری می‌شود؟ |
| اطلاع‌رسانی | در صورت بروز اختلال گسترده، مشتری از چه مسیری مطلع می‌شود؟ |
| مسیر جایگزین | در چه شرایطی می‌توان تماس‌ها را به مقصد دیگری هدایت کرد؟ |
| تداوم ارتباط | در صورت اختلال اینترنت شرکت یا مسیر ارتباط تلفنی، چه گزینه‌هایی وجود دارد؟ |
| پشتیبان‌گیری | کدام تنظیمات و داده‌ها پشتیبان‌گیری می‌شوند و بازیابی آن‌ها چگونه انجام می‌شود؟ |
| گزارش‌دهی | آیا اطلاعات لازم برای بررسی عملکرد سرویس در اختیار مشتری قرار می‌گیرد؟ |
| مسئولیت طرفین | چه بخش‌هایی بر عهده ارائه‌دهنده و چه مواردی بر عهده مشتری است؟ |
| عدم تحقق تعهدات | در صورت رعایت نشدن SLA، چه فرایندی برای بررسی موضوع و جبران احتمالی تعریف شده است؟ |
پاسخ این سؤال‌ها باید با نوع فعالیت شرکت و میزان وابستگی آن به تماس تلفنی تطبیق داده شود.
برای مثال، سازمانی که در ساعات مشخصی پاسخ‌گوست، ممکن است نیازهای متفاوتی نسبت به مجموعه‌ای داشته باشد که در چند شیفت فعالیت می‌کند.
چگونه پایداری مرکز تماس را از دید کسب‌وکار ارزیابی کنیم؟
بررسی SLA ضروری است، اما برای انتخاب مرکز تماس ابری کافی نیست. بهتر است اثر اختلال بر فرایندهای واقعی شرکت نیز در نظر گرفته شود.
سناریوی اول: اختلال در اینترنت دفتر
فرض کنید سامانه ابری فعال است، اما اینترنت دفتر شرکت قطع شده است.
در این شرایط، حتی اگر سرویس ارائه‌دهنده در دسترس باشد، ممکن است کارشناسان داخل دفتر نتوانند از طریق اتصال فعلی خود تماس‌ها را مدیریت کنند.
بنابراین، سازمان باید بررسی کند آیا روش جایگزینی برای اتصال کاربران وجود دارد و چه زیرساختی برای استفاده از آن لازم است.
اگر کارکنان از اپلیکیشن یا کلاینت تلفنی استفاده می‌کنند، وضعیت اتصال آن‌ها نیز به شبکه مورد استفاده وابسته خواهد بود.
سناریوی دوم: اختلال در دریافت تماس‌های ورودی
در این وضعیت، لازم است ابتدا مشخص شود مشکل مربوط به مرکز تماس، مسیر ارتباط تلفنی یا بخش دیگری از زنجیره تماس است.
سپس باید بررسی شود چه کسی مسئول عیب‌یابی است، آیا مسیر جایگزینی برای شرایط رخ‌داده تعریف شده و مشتری سازمانی چگونه از وضعیت مطلع می‌شود.
این سناریو اهمیت تعیین دقیق محدوده خدمات در SLA را نشان می‌دهد.
سناریوی سوم: اختلال در ساعات شلوغ تماس
برای تیم فروش یا پشتیبانی، اختلال در ساعات پرترافیک می‌تواند باعث افزایش تماس‌های بی‌پاسخ و عقب افتادن پیگیری‌ها شود.
در چنین شرایطی، علاوه بر رفع مشکل فنی، امکان بررسی گزارش تماس‌ها و شناسایی ارتباطات ازدست‌رفته نیز اهمیت دارد.
در صورت در دسترس بودن داده‌های لازم، تیم می‌تواند پس از رفع اختلال تماس‌های نیازمند پیگیری را شناسایی کند.
سناریوی چهارم: تغییر اشتباه در تنظیمات تماس
گاهی مشکل ارتباطی ناشی از خرابی زیرساخت نیست، بلکه یک تغییر نامناسب در تنظیمات مسیر تماس یا داخلی‌ها باعث اختلال می‌شود.
در این حالت، کنترل دسترسی کاربران، ثبت تغییرات در صورت پشتیبانی سامانه و امکان بازگردانی تنظیمات می‌توانند به مدیریت بهتر رخداد کمک کنند.
این مثال نشان می‌دهد پایداری عملیاتی فقط به ارائه‌دهنده وابسته نیست و شیوه مدیریت سامانه توسط سازمان نیز در آن نقش دارد.
چه عواملی بر تداوم سرویس مرکز تماس ابری تأثیر می‌گذارند؟
تداوم پاسخ‌گویی معمولاً حاصل عملکرد مجموعه‌ای از اجزا و فرایندهاست، نه یک قابلیت واحد.
برای ارزیابی بهتر، می‌توان این عوامل را در سه بخش در نظر گرفت.
زیرساخت و ارتباطات
عملکرد سرویس ابری، ارتباطات شبکه، مسیرهای تلفنی و روش اتصال کاربران از عواملی هستند که می‌توانند بر دسترسی به تماس‌ها اثر بگذارند.
به همین دلیل، بررسی مرز مسئولیت هر بخش اهمیت دارد.
طراحی فرایند پاسخ‌گویی
ساختار داخلی‌ها، صف‌های تماس، منشی تلفنی، مسیرهای جایگزین و ساعات کاری تعیین می‌کنند تماس‌گیرندگان در شرایط مختلف چگونه به مقصد مناسب برسند.
اگر این فرایندها متناسب با ساختار واقعی سازمان طراحی نشده باشند، حتی در زمان عملکرد عادی سرویس نیز ممکن است برخی تماس‌ها به مقصد مناسب نرسند.
آمادگی تیم و فرایند مدیریت اختلال
سازمان باید بداند هنگام بروز مشکل چه کسی آن را بررسی می‌کند، چه افرادی باید مطلع شوند و کارشناسان تا زمان رفع اختلال چه اقداماتی می‌توانند انجام دهند.
آمادگی عملیاتی، در کنار امکانات فنی و تعهدات خدماتی، نقش مهمی در کاهش اثر اختلال بر مشتریان دارد.
ویپانو چه امکاناتی برای مدیریت تماس‌های سازمانی ارائه می‌کند؟
ویپانو (Voipano) ارائه‌دهنده راهکارهای تلفن سازمانی و مرکز تماس ابری است.
در میان قابلیت‌های ویپانو، امکاناتی مانند تعریف و مدیریت داخلی‌ها، صف تماس، منشی تلفنی IVR، انتقال تماس، گزارش تماس، مدیریت آنلاین، ساعات و شیفت کاری و مسیر جایگزین تماس در شرایط مشخص وجود دارد.
این قابلیت‌ها می‌توانند در طراحی فرایند پاسخ‌گویی و مدیریت تماس‌های سازمانی مورد استفاده قرار گیرند.
برای مثال، کسب‌وکار می‌تواند ساختار داخلی‌های خود را متناسب با واحدهای مختلف تنظیم کند، از صف تماس برای سازمان‌دهی تماس‌های ورودی استفاده کند و در شرایط مشخص، مسیر جایگزینی برای تماس‌ها در نظر بگیرد.
بااین‌حال، وجود امکانات مدیریت تماس به‌تنهایی بیانگر سطح مشخصی از SLA، میزان دسترس‌پذیری یا تضمین تداوم سرویس نیست.
برای تصمیم‌گیری درباره استفاده از مرکز تماس ابری ویپانو، لازم است جزئیات تعهدات خدماتی، شرایط پشتیبانی، نحوه مدیریت اختلال‌ها و امکان اجرای سناریوهای جایگزین متناسب با نیاز کسب‌وکار به‌صورت جداگانه بررسی شوند.
اگر پایداری تماس‌ها برای فعالیت شرکت شما اهمیت بالایی دارد، بهتر است پیش از انتخاب سرویس، سناریوهای حساس کسب‌وکار خود را مشخص کنید و درباره قابلیت‌ها و شرایط خدمات مرتبط با آن‌ها از تیم ویپانو توضیح بخواهید.
جمع‌بندی: SLA را با شرایط واقعی اختلال بسنجید
SLA مرکز تماس ابری ابزاری برای شفاف کردن انتظارات و تعهدات خدماتی است، اما به‌تنهایی تضمین نمی‌کند که هیچ اختلالی رخ نخواهد داد.
برای ارزیابی یک سرویس باید در کنار دسترس‌پذیری، به محدوده تعهدات، زمان پاسخ‌گویی پشتیبانی، نحوه مدیریت رخدادها، اطلاع‌رسانی، مسیرهای جایگزین و امکان بازیابی تنظیمات و داده‌ها توجه کرد.
همچنین لازم است میان اختلال زیرساخت ارائه‌دهنده، مشکل اینترنت سازمان و خطاهای ناشی از تنظیمات داخلی تفاوت قائل شد؛ زیرا مسئولیت و روش رسیدگی به هرکدام ممکن است متفاوت باشد.
معیار اصلی انتخاب فقط این نیست که سرویس چقدر پایدار معرفی می‌شود؛ بلکه باید بدانید هنگام اختلال چه اتفاقی می‌افتد، چه کسی مسئول رسیدگی است و کسب‌وکار شما چه گزینه‌هایی برای ادامه پاسخ‌گویی دارد.
با مطرح کردن این پرسش‌ها پیش از قرارداد، می‌توانید مرکز تماس ابری را بر اساس نیازهای واقعی سازمان و تعهدات قابل بررسی انتخاب کنید.