L1, L2 і L3 підтримка: що робить кожен рівень і хто має на ньому працювати

Один із наших клієнтів прийшов до нас із рівнем ескалації 73%. Три чверті кожного звернення потрапляло до технічної команди. Коли ми розклали типи проблем, виявилося: 68% з тих ескалованих звернень мали закриватися на L1 - скидання паролів, перевірка статусів транзакцій, питання щодо функцій, відповіді на які вже були в базі знань. Технічна команда обробляла запити, які займали в інженера 4 хвилини кожен. Агент L1 вирішував той самий запит за 90 секунд. Різниця у вартості одного звернення: у 12 разів.

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

Навіщо існує рівнева модель

Рівнева модель підтримки має одну мету: узгоджувати складність проблеми з вартістю людини, яка її вирішує. Час інженера L3 коштує у 10–20 разів дорожче за час агента L1. Кожен рутинний запит, що досягає старшого інженера - це неправильно витрачені гроші.

Орієнтовна вартість обробки одного звернення: агент L1 - $3–8 за вирішене звернення; спеціаліст L2 - $15–30; інженер L3 - $40–100+. За 1 000 звернень на місяць різниця між правильно та неправильно збудованою структурою може перевищувати $30 000 на місяць лише за рахунок неправильно розподіленого часу інженерів - і це ще без урахування того, що вони не будують продукт.

Рівні - це не ступені старшинства. Це зони відповідальності. Агент L1 - не молодший L2. Він спеціаліст іншого профілю: швидка ідентифікація та вирішення відомих проблем, і чиста передача невідомих на наступний рівень.

Що насправді робить L1

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

Перелік завдань правильно налаштованого агента L1:

• Моніторинг черги по всіх активних каналах - чат, email, телефон
• Категоризація проблеми під час першого контакту - ідентифікувати, не діагностувати
• Вирішення відомих проблем за базою знань - 65–80% загального обсягу
• Перевірка системних логів і транзакцій для задокументованих типів аномалій
• Ескалація на L2 зі структурованою нотаткою передачі, коли проблема виходить за межі регламенту
• Документування кожної взаємодії з достатнім контекстом для продовження без повторних запитань

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

Обсяг: L1 має обробляти 65–80% загального потоку. Якщо менше - або база знань неповна, або критерії ескалації надто широкі. Профіль команди: навчені агенти з глибоким знанням продукту, сильною письмовою комунікацією і швидким розпізнаванням закономірностей. Знання галузі важливіші за технічну глибину.

Що насправді робить L2

L2 обробляє проблеми, що вимагають технічних знань або доступу до систем, якого немає у L1. Це не «складніші» проблеми в абстрактному сенсі - це проблеми з іншим шляхом вирішення.

Обсяг завдань L2:

• Поглиблена діагностика, що потребує знання продукту або технічної підготовки
• Зміна конфігурацій і налаштувань акаунту, що потребує доступу до бекенду
• Сортування багів - відтворення проблеми, підтвердження того, що це баг продукту, а не помилка користувача, фіксація для L3
• Перевірки на рівні API та дебаг інтеграцій для B2B-клієнтів
• Складні суперечки щодо платежів, що потребують розслідування на рівні транзакцій
• Обробка ескалацій від L1 з повним переглядом контексту перед дією

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

Що ламає L2: звернення від L1 без контексту, що змушують L2 починати розслідування з нуля. Нотатка передачі - це не формальність. Вона визначає, чи витратить L2 5 хвилин або 45 на звернення, яке має займати 5.

Що насправді робить L3

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

Обсяг завдань L3:

• Аналіз першопричин для повторюваних або системних проблем
• Дебаг на рівні коду - виявлення багів, написання виправлення або створення детального тікета для інженерного спринту
• Інфраструктурні інциденти - проблеми з базою даних, збої деплою, збої інтеграцій зі сторонніми сервісами
• Безпекові ескалації, що потребують негайної реакції інженерів

Обсяг: менше 5% за здорової операції. Якщо L3 обробляє більше 5–10% загального потоку - або продукт має серйозні проблеми зі стабільністю, або рівні L1/L2 не виконують свою функцію. Профіль: старші інженери, DevOps, або виділені інженери підтримки, вбудовані в продуктову команду.

Як рівні взаємодіють між собою

Передача: як виглядає якісна ескалація

Нотатка ескалації - це місце, де більшість компаній втрачає час. Погана передача L1→L2 виглядає так: «Користувач має проблему з платежем». Агент L2 отримує це і починає розслідування з нуля - звʼязується з користувачем, зʼясовує деталі, переглядає лог транзакцій, встановлює, що вже було випробувано. Витрачений час: 30–45 хвилин на звернення, для якого L1 міг підготувати контекст за 5.

Якісна нотатка передачі L1→L2 містить:

• Опис проблеми з деталями: «Користувач повідомляє про невдале поповнення о 14:32 UTC через Przelewy24 (PL), ID транзакції #TXN-88472»
• Що перевірено: «Лог транзакцій показує таймаут шлюзу, а не помилку користувача. Задокументоване обхідне рішення не підходить - цей шлюз повернув код помилки 502, а не задокументований 504»
• Що повідомлено користувачу: «Повідомили користувача, що ми розслідуємо ситуацію, SLA відповіді - 2 години»
• Пріоритет із поясненням: «Середній - користувач чекає 20 хвилин, акаунт у доброму стані»

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

Що ми бачимо, коли приходимо в зламану структуру

Коли новий клієнт залучає нас для ведення L1, ми починаємо з аудиту рівня ескалації та змісту нотаток. Картина повторюється: рівень ескалації 40–70%, нотатки майже без корисного контексту.

Вирішення рідко полягає в заміні агентів. Зазвичай проблема в:

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

Клієнт, з якого ми почали цю статтю, - рівень ескалації 73%. Після шести тижнів перебудови бази знань, налаштування доступу до інструментів і визначення критеріїв ескалації показник закриття на L1 становив 71%. Ті самі агенти. Інший процес.

5 ознак того, що ваша структура рівнів зламана

1. Команда L2 або інженери обробляють скидання паролів і питання оплати. Якщо спеціалісти торкаються рутинних запитів - межа ескалації не працює.
2. Рівень ескалації вище 40%. Або обсяг L1 надто вузький, або база знань не охоплює те, що реально надходить.
3. Нотатки ескалації не містять ID транзакцій, вжитих дій або комунікації з користувачем. L2 починає розслідування заново за кожним зверненням.
4. Немає визначеного SLA між L1 і L2. Без SLA немає відповідальності, і середній час передачі вимірюється годинами, а не хвилинами.
5. Ви не відстежуєте, який відсоток обсягу обробляє кожен рівень. Без вимірювання немає управління - і ви не помітите, коли баланс зміниться.