Клієнти пишуть у підтримку, але протягом 20 хвилин ніхто не відповідає. Вони починають дублювати запити, шукати інші канали зв’язку і, зрештою, дратуватися. Менеджер упевнений, що звернення вже в роботі, спеціаліст вважає, що часу ще достатньо, а керівник дізнається про проблему лише після скарги клієнта. Це призводить до погіршення клієнтського досвіду та втрати часу, а отже – до зниження прибутку.
Так виглядає сервіс без чітких строків реакції та правил обробки звернень. SLA (Service Level Agreement, Угода про рівень послуг) допомагає задати ці правила, а Planfix допомагає забезпечити їх виконання й контролювати швидкість відповідей підтримки та вирішення тікетів.
Розберемо, як це працює, і покажемо, як перетворити Planfix на повноцінну систему управління сервісом.
Домовимося про терміни: SLI, SLO, SLA та SLM
Управління рівнем сервісу починається з розуміння базової термінології й обертається навколо чотирьох абревіатур: SLI, SLO, SLA, SLM. Щоб не плутатися, розберімося, що кожна з них означає.
SLI (Service Level Indicator) – індикатор рівня обслуговування. Це фактичний, вимірюваний показник роботи сервісу.
Наприклад, система моніторингу фіксує, що середній час відповіді служби підтримки становив 18 хвилин. Це і є індикатор рівня обслуговування – швидкості реакції на звернення клієнтів.
SLO (Service Level Objective) – цільовий рівень обслуговування. Це цільове значення для обраного SLI, тобто рівень, якого сервіс прагне дотримуватися.
Наприклад, компанія визначає, що перша відповідь служби підтримки має бути надана не пізніше ніж через 15 хвилин після надходження запиту.
При цьому саме по собі SLO не зобов’язує сторони до будь-яких юридично значущих дій, а скоріше є внутрішньою ціллю, на яку орієнтується команда.
SLA (Service Level Agreement) – угода про рівень обслуговування. Це формалізована угода, у якій рівень сервісу закріплюється як зобов’язання, включно з правилами вимірювання та наслідками порушення.
Наприклад, договір з клієнтом містить чітко прописану швидкість реакції на звернення: перша відповідь має бути отримана не пізніше ніж через 15 хвилин. Критично важливий інцидент має бути вирішений не пізніше ніж через 2 години.
SLM (Service Level Management) – управління рівнем обслуговування. Це процес і набір інструментів, які допомагають забезпечувати надання послуг клієнтам і контролювати їх відповідність рівню, прописаному в SLA.
Наприклад, клієнт надсилає повідомлення в підтримку, а SLM-інструмент попереджає менеджера, якщо час очікування відповіді наближається до критичного.
З термінологією визначилися, тепер розберімося з новими можливостями в Planfix і тим, чому їх можна використовувати як повноцінний SLM-інструмент.
Контроль часу реакції: запобігаємо до порушення
В SLA одним із ключових параметрів зазвичай є час реакції – скільки хвилин або годин проходить від надходження запиту клієнта до першої відповіді співробітника.
Наприклад, якщо клієнт хмарного сховища даних скаржиться на неможливість авторизуватися в акаунті, згідно з SLA, оператор сервісу повинен відповісти не пізніше ніж через 20 хвилин.
Щоб контролювати цей показник, до автоматичних сценаріїв Planfix додано подію – «Перевищено час очікування клієнтом відповіді»:
Якщо з моменту надходження звернення проходить більше заданого часу, сценарій запускає передбачені дії. Наприклад: запускає передбачені дії. Наприклад:
- відправляє нагадування співробітнику підтримки;
- сповіщає менеджера, який контролює роботу підтримки;
- підвищує пріоритет звернення.
Важливо: таймер доцільно налаштовувати з запасом, щоб сповіщення працювали як попередження, а не просто фіксували факт порушення SLA.
Контроль строків вирішення: стежимо за тікетом до кінця
Інший важливий SLA-показник – час вирішення тікета. Для контролю цього параметра в автоматичні сценарії додано подію – «Перевищено час перебування завдання в статусі».
Наприклад, якщо для вирішення проблеми потрібна участь розробників, тікет переводиться у статус «Технічні роботи», а сценарій попереджає менеджера або відповідальну особу, якщо робота затягується й строки наближаються до критичних:
Такий підхід дає змогу контролювати не лише швидкість реакції на інциденти, а й час повного вирішення проблеми клієнта.
Облік робочого часу та часових поясів
Чітко прописані строки відповідей служби підтримки та вирішення інцидентів – це добре, але…
Що робити, якщо запит у підтримку надійшов о 2-й годині ночі? Або вранці 1 січня?
Щоб не виникало таких питань, у SLA зазвичай уточнюється, як саме вимірюється швидкість реакції на інциденти: з урахуванням графіка та робочого часу підтримки чи просто за календарним часом.
Таке уточнення можна зробити і під час налаштування сценаріїв у Planfix:
Також у системі можна задати для різних співробітників різні часові пояси та робочий графік. Це може бути важливо, якщо ваша компанія надає послуги одночасно в кількох регіонах.
Очікування даних від клієнта та перезапуск строків
Якщо в процесі потрібне уточнення інформації від клієнта, статус завдання можна переключити на «Очікуємо відповіді» або близький за змістом.
Після отримання даних тікет повертається в статус «Опрацювання», і відлік строку усунення інциденту починається заново.
Для відстеження загального строку вирішення тікета можна налаштувати окремий звіт. При цьому дані можна групувати за проєктами, типами запитів, виконавцями або, наприклад, вивести середній час обробки звернень:
Різні умови SLA для різних клієнтів і запитів
Різні SLA для різних клієнтів
Рівень сервісу, обумовлений у SLA, може відрізнятися залежно від значущості клієнта, тарифного плану, історії взаємодії з ним та інших факторів.
Досягти такої сегментації користувачів у Planfix можна за допомогою різних клієнтських шаблонів або полів із мітками, які запускають різні ланцюжки автоматичних дій з різними:
- строками реакції служби підтримки;
- строками вирішення інциденту;
- політиками сповіщень та ескалації.
Наприклад, для клієнтів із тарифним планом «Преміум» допустимий строк відповіді підтримки може становити 15 хвилин, а строк вирішення інциденту – не більше двох годин.
Для клієнтів на тарифі «Стандарт» ці строки можуть становити 30 хвилин і три години відповідно.
Таким чином система підтримує різні рівні SLA, що відповідають укладеним з клієнтами угодам.
Різні процеси для різних типів інцидентів
Окрім сегментації клієнтів, важливо також розрізняти типи їхніх запитів.
Критичні інциденти обробляються в першу чергу.
Менш пріоритетні звернення, наприклад запитання щодо документації або некритичні уточнення, можуть опрацьовуватися довше, однак не повинні залишатися без уваги.
У Planfix тип інциденту можна:
- задати вручну – для цього співробітник підтримки проставляє позначку в спеціальному користувацькому полі;
- визначити автоматично за допомогою Planfix AI. У цьому разі текст звернення передається інтелектуальному помічнику, він його аналізує й визначає, до якої категорії з найбільшою ймовірністю належить запит.
Залежно від типу інциденту запускаються різні сценарії їх обробки. Технічні помилки можуть мати одні строки й послідовність дій, запитання щодо навчання – інші, а критичні збої потребують негайної ескалації до старшого спеціаліста.
Навіщо бізнесу потрібні SLA та інструменти контролю якості сервісу
Для того, щоб формалізувати очікування клієнтів і відійти від суб’єктивної оцінки якості послуг.
Якщо розгорнути відповідь детальніше, чітко прописані орієнтири та цілі допомагають команді працювати за зрозумілими стандартами. Клієнти знають, чого очікувати від сервісу, співробітники – що від них вимагається, а керівники бачать ефективність роботи й слабкі місця процесів.
Ми показали базові сценарії контролю SLA та управління якістю сервісу. Але це лише початок.
У Planfix можна побудувати набагато складнішу автоматизацію з багаторівневою ескалацією, автоматизованими ланцюжками сповіщень, власними статусами та умовами перезапуску строків.
У підсумку ви задаєте стандарти якості, а Planfix робить так, щоб вони виконувалися. Налаштуйте систему один раз і перетворіть управління сервісом на передбачуваний, прозорий і керований процес, у чому Planfix вам допоможе.
Залишилися питання? Пишіть нам у Службу підтримки. Ми з радістю відповімо на всі ваші запитання. Покращуйте свої робочі процеси за допомогою Planfix.