Содержание
Линии технической поддержки делят обращения по сложности. Первая линия принимает заявку и решает типовое, вторая разбирается в нетиповом с помощью логов и настроек, третья исправляет причину в коде и инфраструктуре. Трудности обычно начинаются именно на третьей: первые две в компании есть, а сложные инциденты копятся, потому что разбирать их некому или разработчики заняты новыми функциями.
Три линии на одном примере
Определения легко забываются, поэтому проследим за одним обращением. Клиент платформы пишет: «Не приходит письмо со ссылкой для входа».
| Линия | Кто работает | Что делает в этом случае | Какие доступы нужны |
|---|---|---|---|
| Первая | Специалист поддержки | Проверяет адрес и папку спама, отправляет письмо повторно | Админка, база знаний |
| Вторая | Инженер поддержки, администратор | Смотрит логи почтового сервиса, видит сбой очереди, перезапускает её | Логи, мониторинг, настройки |
| Третья | Разработчик, архитектор | Находит, что очередь падает на письмах с большим вложением, правит код и выпускает релиз | Код, инфраструктура, право на релиз |
Заметьте, что каждая линия закрывает обращение по-своему. Первая помогла одному клиенту. Вторая вернула работу сервиса для всех на сегодня. Третья сделала так, что сбой не вернётся. Если в компании работают только первые две линии, клиенты будут получать письма, но очередь продолжит падать снова и снова.
Кто на какой линии в компании вашего размера
Названия из учебников рассчитаны на большие компании. В жизни линии распределяются по тем людям, которые есть.
- Команда до 5 человек. Первую линию ведёт менеджер или сам основатель. Вторую и третью закрывает один разработчик. Система держится, пока он на месте и не занят срочной разработкой. О риске такой схемы мы писали в статье «Уходит разработчик или вся команда».
- Команда 5-20 человек. Появляется отдельная поддержка на первой линии, иногда один администратор на второй. Третья линия это продуктовые разработчики, которые разбирают инциденты между задачами.
- Команда от 20 человек. Вторая линия становится отдельной группой, появляется дежурство. Третья линия остаётся самой дефицитной: людей, которые понимают систему целиком, всегда мало.
Отдельный дежурный на третьей линии появляется поздно, и до этого момента сложные инциденты конкурируют с планом разработки. Обычно план побеждает: у него есть сроки и заказчик, а у повторяющегося сбоя только раздражённые клиенты.
Как понять, что третья линия не справляется
Обращения при этом могут закрываться вовремя, и по отчётам всё выглядит нормально. Смотреть нужно на другое.
- Одни и те же сбои повторяются. Вторая линия знает их наизусть и держит инструкцию, как быстро всё поднять.
- Задачи на исправление лежат месяцами. Они есть в трекере, но каждый раз уступают новым функциям.
- Разработчиков дёргают в рабочее время. Срочный инцидент ломает план спринта, а сроки релизов ползут.
- Обходные пути становятся нормой. Сотрудники заранее знают, что в понедельник надо перезапустить выгрузку.
- Никто не может объяснить причину. На вопрос «почему упало» отвечают «нагрузка» или «такое бывает».
- Страшно выпускать релизы. Команда не уверена, что сломается следующим, поэтому релизы становятся реже.
Сколько стоит обращение, ушедшее выше
Каждая передача на следующую линию стоит денег, поэтому две крайности вредны одинаково. Если передавать всё подряд, эксперты будут заниматься сбросом паролей. Если не передавать ничего, клиент неделями будет ждать ответа.
Для ориентира есть данные MetricNet по службам ИТ-поддержки: обращение на первом уровне стоит около $22, а с передачей на следующий $91, то есть примерно в четыре раза дороже. В среднем 17,8% обращений, закрытых уровнем выше, могла решить и первая линия, а у разных компаний этот показатель различается от 2,7% до 35,1%. Цифры из внутренней поддержки крупных компаний и опубликованы в 2018 году, абсолютные суммы устарели, но соотношение показывает, где теряются деньги.
Чтобы передачи работали, договоритесь о трёх вещах:
- Критерии передачи. Когда обращение уходит выше: нет решения в базе знаний, затронуты деньги или данные клиентов, прошло оговорённое время. Единого стандарта по времени нет, его задают приоритет инцидента и ваш SLA.
- Что передаётся вместе с заявкой. Что произошло, у кого, когда, что уже пробовали, ссылка на логи. Если третья линия заново выясняет всё у клиента, половина времени потеряна.
- Обратная связь вниз. Третья линия нашла решение, и оно попадает в инструкцию второй или первой. Иначе следующая такая заявка снова дойдёт до самого дорогого специалиста.
Какую линию можно отдать наружу
Внешней команде можно передать любую линию, но смысл у этого будет разный.
| Линия | Зачем отдавать | На что смотреть | Что оставить у себя |
|---|---|---|---|
| Первая | Нужны ночи и выходные, большой поток типовых заявок | Знание продукта, тон общения с клиентами | База знаний и контроль качества ответов |
| Вторая | Нужно дежурство и контроль инфраструктуры, своего администратора нет | Сроки реакции, доступ к логам | Решение о приоритетах |
| Третья | Сложные инциденты копятся, своей экспертизы не хватает | Опыт в чужом коде, согласование релизов | Продуктовые решения и план развития |
Для компании с собственной первой линией самая частая история выглядит так: заявки клиентов остаются внутри, потому что свои люди лучше знают продукт, а сложные инциденты и разбор причин уходят внешней команде. Разработчики возвращаются к плану, а сбои при этом разбирают люди, которых не отвлекают новые функции.
Такая схема работает при нескольких условиях:
- Общая очередь задач. Внешняя команда работает в вашем трекере или в связанном с ним, иначе заявки теряются между системами.
- Понятные границы. Записано, кто решает, что инцидент критичный, и кто нажимает кнопку релиза ночью.
- Согласованные изменения. Правки внешней команды и релизы своих разработчиков не должны конфликтовать на боевой системе.
- Код и доступы у вас. Репозиторий и серверы принадлежат компании, а внешней команде выдаётся доступ с правами по задаче.
Когда звать внешнюю команду
Если первая и вторая линии у вас есть, а сложные инциденты копятся, начинать с найма не обязательно: поиск такого специалиста занимает месяцы, и ещё несколько месяцев он будет изучать систему. Подключить внешнюю команду можно быстрее, но ей тоже нужно разобраться в системе, поэтому первый шаг это разбор.
Мы подключаемся там, где своей команде не хватает рук. На аудите разбираем архитектуру, данные и нагрузку, находим первопричины и отдаём план работ с приоритетами. Отчёт остаётся у вас. Дальше систему можно взять на поддержку по SLA: сроки реакции записаны в договоре, а повторяющийся сбой уходит в план работ.
Частые вопросы
Что такое 3 линия поддержки?
Третья линия это разработчики и архитекторы, которые работают с причиной сбоя в коде и инфраструктуре. К ним попадают обращения, которые нельзя решить инструкцией или настройками. Результат их работы обычно это исправление и релиз.
Чем вторая линия поддержки отличается от третьей?
Вторая линия разбирается в проблеме с помощью логов, настроек и мониторинга, но систему не переписывает. Третья может изменить код, схему базы или инфраструктуру, чтобы сбой больше не повторялся.
Нужны ли все три линии небольшой компании?
Нужны три роли, но не три отдела. Один человек может совмещать вторую и третью линии. Важно понимать, кто отвечает за каждую роль и что будет, если этот человек занят или уйдёт.
Сколько времени обращение должно идти до третьей линии?
Единого стандарта нет. Сроки зависят от приоритета: критичный сбой, влияющий на деньги, передают сразу, а обычные заявки сначала разбирают первая и вторая линии. Правила стоит закрепить в SLA.
Можно ли передать наружу только третью линию?
Да, это распространённая схема: своя поддержка общается с клиентами, а внешняя команда разбирает сложные инциденты. Нужны общая очередь задач, понятные границы ответственности и согласованные релизы.
