Deskhero
Українська
Спробувати безкоштовно

← Back to articles

Як автоматизувати нагадування про SLA, перш ніж вони призведуть до порушень

Як автоматизувати нагадування про SLA, перш ніж вони призведуть до порушень

Автоматизовані нагадування про SLA мають показати тікет, доки ще є час діяти, а потім зробити прострочений тікет неможливо не помітити. Правильне налаштування залежить від системи підтримки. Деякі платформи надають вбудовані сповіщення про наближення дедлайну та порушення SLA, тоді як для власного робочого процесу можуть знадобитися заплановані перевірки й чітко визначені кроки ескалації.

Почніть із годинника, а не зі сповіщення:

  • Визначте окремі цільові показники для першої відповіді та вирішення.
  • Вирішіть, чи використовують цільові показники календарний час або робочі години.
  • Оберіть статуси тікета, які призупиняють відлік часу до вирішення.

Порада професіонала: Перевірте кожен стан SLA на тестових тікетах, перш ніж покладатися на сповіщення в робочому середовищі. Додайте випадки з наближенням дедлайну, порушенням SLA, призупиненням, перепризначенням і вже завершені випадки.

Ключові висновки

Надійні нагадування починаються з точних дедлайнів. Час сповіщень, одержувачі та процедури ескалації мають налаштовуватися після того, як саму політику буде правильно визначено.

Пункт Деталі
Визначте обидва відліки Відстежуйте першу відповідь і вирішення окремо, оскільки вони завершуються за різними подіями.
Враховуйте робочий час Використовуйте робочий графік, якщо ночі та вихідні не мають зараховуватися до цільового показника.
Налаштуйте статуси призупинення Призупиняйте цільовий час вирішення, доки тікет очікує на клієнта або іншу зовнішню сторону.
Обирайте одержувачів свідомо Переконайтеся, що сповіщення про наближення дедлайну та порушення SLA отримує хтось, хто може діяти щодо тікета.
Перевірте перед запуском Перевірте дедлайни, поведінку призупинення та доставку сповіщень за допомогою контрольованих тікетів.
Спочатку використовуйте вбудовані функції SLA Система підтримки з вбудованими політиками, робочими графіками, сповіщеннями, фільтрами та звітністю дає змогу уникнути окремого робочого процесу з періодичним опитуванням.

Авторитетна документація та інструкції для подальшого ознайомлення

Приклад для конкретної платформи дивіться в документації Jira щодо автоматизованих подальших дій. У ній описано як заплановані правила, так і підхід із порогом SLA, зокрема рекомендацію спочатку протестувати рішення на невеликій області запиту, перш ніж розширювати її.

Зміст

Покрокове створення автоматизації нагадувань про SLA

Перед налаштуванням сповіщення точно запишіть, що вимірює кожен SLA. Цільовий час першої відповіді та цільовий час вирішення — це різні відліки. Визначте, яка подія тікета запускає кожен відлік, яка подія його завершує, а також чи залежить дедлайн від календарного часу або робочого графіка.

Потім налаштуйте шлях нагадування.

  1. Визначте політику. Пов’яжіть групи та пріоритети з цільовими показниками першої відповіді й вирішення. Додайте загальну політику для тікетів, які не відповідають конкретнішому правилу.
  2. Налаштуйте робочий календар. Додайте робочі години та часовий пояс, що застосовуються до цільового показника. Якщо зобов’язання діє безперервно, використовуйте календарний час.
  3. Налаштуйте поведінку призупинення. Виберіть статуси, які зупиняють відлік часу до вирішення, доки команда очікує на інформацію. Перевірте, чи можна призупиняти відлік часу першої відповіді, оскільки багато систем обробляють його інакше.
  4. Увімкніть сповіщення. Визначте, хто отримує повідомлення про наближення дедлайну та порушення SLA, а також які підтримувані канали використовуватиме система підтримки.
  5. Додайте операційну реакцію. Задокументуйте, що має зробити одержувач: наприклад, відповісти, змінити пріоритет, перепризначити тікет або залучити керівника. Сповіщення та коригувальна дія не обов’язково мають бути одним технічним правилом.

Якщо система підтримки не має вбудованих порогів SLA, запланований робочий процес може перевіряти відкриті тікети та порівнювати їхні дедлайни з поточним часом. Приклад опитування кожні 15 хвилин задокументовано компанією LOW/CODE, але відповідний інтервал залежить від найкоротшого цільового показника, обмежень API, робочих годин і допустимої для команди затримки. Зберігайте стан сповіщення, щоб наступні запуски не надсилали те саме повідомлення повторно.

Як обрати пороги, що не спричиняють втому від сповіщень

Корисне попередження залишає одержувачу достатньо часу для відповіді. Порогове значення у відсотках може працювати у власній системі, але фіксований період попередження часто легше зрозуміти для політик із різною тривалістю.

  • Час ще комфортно дозволяє виконати ціль: Залишайте тікет видимим у звичайних поданнях черги, не надсилаючи попередження.
  • Дедлайн наближається: Повідомте відповідального користувача або групу, доки цільовий показник ще можна виконати.
  • Порушення SLA: Позначте тікет як прострочений і дотримуйтеся задокументованого процесу ескалації команди.

Не копіюйте універсальний поріг у 80 відсотків, не перевіривши базові цільові показники. Для цілі в одну годину він залишає 12 хвилин, тоді як для цілі у три дні — понад половину дня. Виміряйте, скільки часу команді насправді потрібно для дії.

Повторні нагадування швидко створюють інформаційний шум. Вбудовані сповіщення системи підтримки мають надсилатися під час переходу стану, а не після кожного оновлення екрана. Власний робочий процес із періодичним опитуванням має фіксувати факт надсилання повідомлення про наближення дедлайну або порушення SLA й скидати цей стан лише тоді, коли політика справді запускається заново.

Як обрати пороги, що не спричиняють втому від сповіщень: оглядова схема

Що мають містити сповіщення SLA та куди їх надсилати

Сповіщення має ідентифікувати тікет, показувати дедлайн і чітко пояснювати очікувану реакцію. Не додавайте дані клієнта, які не потрібні одержувачу.

  • ID тікета та посилання, щоб одержувач міг відкрити правильний діалог.
  • Тип цільового показника, наприклад перша відповідь або вирішення.
  • Дедлайн або тривалість прострочення у недвозначно визначеному часовому поясі.
  • Поточний статус, пріоритет, група та відповідальний, якщо ці поля впливають на відповідальність.
  • Один наступний крок, наприклад відповісти, перепризначити тікет або попросити керівника його переглянути.

Використовуйте канали, які команда підтримки вже відстежує. Внутрішньосистемних та електронних сповіщень часто достатньо, якщо вони надійно доходять до відповідального або відповідальної групи. Якщо потрібна окрема система пейджингу чи обміну повідомленнями, переконайтеся, що система підтримки підтримує цю інтеграцію, перш ніж будувати процес навколо неї.

Порада професіонала: Показуйте точний дедлайн або зворотний відлік. Конкретний час легше визначити за пріоритетністю, ніж розпливчасте попередження.

Що мають містити сповіщення SLA та куди їх надсилати: оглядова схема

Як забезпечити точність таймерів SLA за допомогою статусів призупинення

Надійність нагадування залежить від надійності його годинника. Цільові показники вирішення зазвичай призупиняються, коли тікет очікує на клієнта, але конкретні статуси мають відповідати реальному робочому процесу команди.

  • Виберіть чітко визначені статуси призупинення та задокументуйте, чому кожен із них зупиняє відлік.
  • Відновлюйте відлік, коли тікет залишає статус призупинення.
  • Перевірте тікети, які переходять у статус призупинення та виходять із нього більше одного разу.
  • Переконайтеся, що цільові показники першої відповіді та вирішення дотримуються однакових правил призупинення.

Робочі графіки вирішують іншу проблему. Вони виключають неробочі години із самого цільового показника, тоді як статуси призупинення виключають час залежно від стану тікета. Налаштуйте та перевірте обидва параметри. Вихідні не мають зараховуватися до цільового показника, розрахованого за робочими годинами, а тікет у будній день, що очікує на клієнта, має залишатися призупиненим, навіть коли команда працює.

Тестування та налаштування перед тим, як довірити процес автоматизації

Використовуйте контрольовані тікети, щоб перевірити повний життєвий цикл. Історичні дані можуть допомогти визначити реалістичні цільові показники, але тест у реальному стані краще підходить для перевірки доставки сповіщень і змін дедлайнів.

  1. Охопіть кожну політику. Створіть тестовий тікет для кожної комбінації групи та пріоритету, яка може вибрати іншу політику SLA.
  2. Використовуйте короткі тимчасові цільові показники. Перевірте стани наближення дедлайну та порушення SLA, не чекаючи годинами або днями, а потім відновіть реальні значення.
  3. Перевірте статуси призупинення. Призупиніть і відновіть відлік часу до вирішення та переконайтеся, що дедлайн змінюється очікуваним чином.
  4. Перевірте одержувачів. Протестуйте призначений і непризначений тікет, щоб правильні люди отримували кожне сповіщення.
  5. Перегляньте запис. Переконайтеся, що в тікеті зазначено застосовану політику, а також коли кожен відлік було виконано або пропущено.

Після запуску переглядайте хибні попередження та пропущені передачі відповідальності. Якщо сповіщення точні, але їх усе одно ігнорують, проблема може бути у відповідальності або чисельності персоналу, а не в часі спрацювання порогів.

Як Deskhero обробляє нагадування про SLA

У Deskhero є спеціальні політики SLA. Вони відокремлені від загальних правил автоматизації, які не є запланованими або залежними від часу.

  • Власники та адміністратори можуть упорядковувати політики SLA, що відповідають групам і пріоритетам тікетів. Перша політика, що відповідає умовам, визначає цільові показники першої відповіді та вирішення.
  • Кожна політика може використовувати іменований щотижневий робочий графік із власним часовим поясом або рахувати календарний час.
  • Відлік часу до вирішення призупиняється у статусах, вибраних у робочому просторі. Відлік часу першої відповіді не призупиняється.
  • Deskhero позначає тікет як такий, що перебуває під ризиком, протягом останніх 60 хвилин перед наступним дедлайном і позначає його як прострочений після завершення дедлайну.
  • Фонове завдання запускається кожні п’ять хвилин і надсилає внутрішньосистемні сповіщення та дайджест електронною поштою відповідальному, а якщо тікет не призначено — членам групи. Користувачі можуть керувати каналами сповіщень SLA для кожної групи.

Список тікетів містить стовпець SLA та фільтри SLA, на інформаційній панелі виділяються тікети під ризиком і прострочені тікети, а часова шкала тікета фіксує події політики та відліків. Розділ Statistics надає подання щодо виконання SLA після запуску робочого процесу.

Що відстежувати після запуску сповіщень

Перше питання — чи запобігають нагадування порушенням SLA. Порівнюйте кількість тікетів під ризиком із кількістю тікетів, у яких згодом було пропущено цільовий показник, а потім досліджуйте випадки, у яких попередження не допомогли.

Відстежуйте виконання цільового показника першої відповіді та виконання цільового показника вирішення окремо. Також переглядайте кількість тікетів, для яких дедлайн настане протягом періоду попередження, кількість уже прострочених тікетів і політики або комбінації груп і пріоритетів, що спричиняють найбільше пропусків.

Доповнюйте відсотки операційним контекстом. Високий загальний відсоток може приховувати одну чергу, у якій регулярно порушується SLA. Раптове падіння показника може бути наслідком зміненого робочого графіка, доданого пріоритету або прогалини у відповідальності, а не повільнішої роботи.

Керування SLA, що перекриваються, без конфліктів сповіщень

Тікет може мати як цільовий показник першої відповіді, так і цільовий показник вирішення. Розглядайте їх як окремі відліки, оскільки відповідь завершує лише перший із них. Цільовий час вирішення триває, доки тікет не досягне події, що підтверджує його виконання.

Інтерфейс тікета має показувати, який із невиконаних дедлайнів настане наступним, зберігаючи водночас деталі обох цільових показників. Фільтри та звітність також мають розрізняти першу відповідь і вирішення, щоб один позитивний показник не приховував проблеми в іншому.

Якщо для клієнтів діють різні зобов’язання, використовуйте окремі політики, що відповідають стабільним полям тікета, таким як група та пріоритет. Розміщуйте конкретні політики перед загальною, а потім перевіряйте тікет на кожній важливій комбінації. Не вигадуйте приховані рівні контрактів, яких користувачі не можуть побачити або перевірити в тікеті.

Готовність до аудиту під час автоматичної роботи SLA

Зберігайте запис про застосовану політику, розраховані дедлайни та час виконання або пропуску кожного відліку. Якщо зміна групи, пріоритету чи графіка спричиняє перерахунок дедлайну, цю зміну також має бути можливо відстежити.

Документуйте зміни політик за межами вхідної скриньки сповіщень. Фіксуйте, хто схвалив зміну, коли вона набула чинності та чи застосовується до наявних тікетів. Це спрощує відповіді на подальші запитання клієнтів і запобігає непомітним змінам значення звіту SLA.

Під час перевірки контрактів підтверджуйте поведінку платформи, а не припускайте, що кожна видима подія є журналом аудиту. Часова шкала тікета Deskhero фіксує застосування політики SLA та результати відліків, тоді як розділ Statistics відображає виконання. Організаціям із формальними вимогами до зберігання даних слід перевірити, чи відповідають ці записи їхнім власним зобов’язанням.

Як писати повідомлення SLA для користувачів, менеджерів і клієнтів

Внутрішні сповіщення та оновлення для клієнтів мають різне призначення. Зосередьте кожне з них на тому, що його читач може зробити далі.

Сповіщення для користувачів мають починатися з посилання на тікет, типу цільового показника, дедлайну та негайної дії. Не додавайте абзац із поясненням політики, коли користувачеві потрібно працювати з тікетом.

Огляди для менеджерів мають показувати закономірності в межах групи, пріоритету або політики. Один пропущений тікет потребує дії, тоді як повторні пропуски потребують рішення щодо персоналу або процесу.

Комунікація для клієнтів має бути точною та конкретною. Якщо команда очікує затримку, оновлення, перевірене людиною, може встановити реалістичний час наступного контакту. Не розкривайте внутрішні позначки сповіщень і не обіцяйте термін вирішення, якого команда не може забезпечити.

Підключення автоматизації SLA до інструментів, які ви вже використовуєте

Почніть із вбудованих функцій SLA, якщо вони охоплюють потрібні політики, календарі, стани призупинення, сповіщення, фільтри та звітність. Вбудовані дедлайни зазвичай надійніше узгоджуються зі змінами тікетів, ніж паралельна електронна таблиця.

Якщо вбудована підтримка обмежена, команди використовували плагіни спільноти та обхідні рішення, описані на форумах. Перш ніж покладатися на такий підхід, перевірте стан його обслуговування та сумісність версій.

Окремий робочий процес може бути доречним, коли кілька систем мають передавати дані в один канал ескалації. Спочатку визначте єдине джерело істини. Дублювання розрахунків SLA у системі підтримки та на рівні інтеграції може призвести до розбіжностей, особливо щодо часових поясів, робочих годин, статусів призупинення та перепризначення.

Погляд редакції: важливе не сповіщення, а дія

Сповіщення про наближення дедлайну корисне лише тоді, коли відповідальність чітко визначена. Одержувачеві потрібні дозвіл, контекст і час, щоб просунути тікет уперед.

Точність таймера має бути першою. Неправильний робочий графік або конфігурація призупинення створюють упевнені, але оманливі сповіщення. Виправте розрахунок дедлайну, перш ніж змінювати формулювання повідомлення або додавати канали.

Створюйте процес у такому порядку: цільові показники політики, робочі графіки, поведінка призупинення, одержувачі сповіщень, операційна реакція та звітність. Така послідовність пов’язує нагадування з дедлайном, який усі розуміють.

Запустіть нагадування про SLA без міграційного проєкту

Deskhero підключається до Gmail або Microsoft 365 із двосторонньою синхронізацією, тож команди можуть зберегти наявну адресу підтримки, додавши спільну обробку тікетів і політики SLA.

Deskhero

Налаштуйте цільові показники першої відповіді та вирішення за групою і пріоритетом, за потреби додайте щотижневий робочий графік і виберіть статуси, які призупиняють вирішення. Після цього Deskhero показуватиме наступний дедлайн, виділятиме тікети, для яких дедлайн настане протягом однієї години, сповіщатиме відповідальних користувачів і фіксуватиме результати SLA.

30-денний безкоштовний пробний період не потребує кредитної картки. Підключіть одну поштову скриньку, налаштуйте невеликий набір політик і перевірте повний життєвий цикл SLA, перш ніж поширювати налаштування на інші групи.

Джерела

Поширені запитання

У чому різниця між SLA, SLO та SLI?

SLA — це зобов’язання щодо рівня обслуговування між сторонами. SLO — це цільовий показник ефективності сервісу, який часто використовується всередині компанії для дотримання цього зобов’язання. SLI — це виміряне значення, за допомогою якого оцінюють цільовий показник.

Що вважається сповіщенням про порушення SLA?

Сповіщення про порушення означає, що невиконаний дедлайн першої відповіді або вирішення минув. Сповіщення про наближення дедлайну відрізняється, оскільки команда все ще має час виконати цільовий показник.

Що означає SLA на 4 години?

Це означає, що дія, визначена політикою, наприклад перша відповідь або вирішення, має бути виконана протягом чотирьох годин відповідно до розрахунків цієї політики. Відлік може використовувати календарний час або робочий графік.

Чим SLA відрізняється від KPI?

SLA визначає зобов’язання щодо обслуговування. KPI вимірює ефективність і може використовуватися для відстеження багатьох цілей, які не є контрактними дедлайнами.

Чи може Deskhero автоматизувати нагадування про SLA без власного коду?

Так. Deskhero має вбудовані політики SLA, фіксований період попередження про наближення дедлайну, виявлення порушень, внутрішньосистемні та електронні сповіщення, фільтри тікетів, подання інформаційної панелі та звітність SLA. Ці функції відокремлені від загальних правил автоматизації.