Как двухуровневая система техподдержки освободила отдел разработки от рутинных саппорт-задач

Kate · 26 Мар 2022

Компания iSpring 20 лет разрабатывает решения для дистанционного корпоративного обучения. Клиенты находятся в 172 странах, поддержка работает в режиме 24/7 на семи языках. В месяц обрабатываем примерно 7300 обращений по всем каналам связи: по телефону, электронной почте, в чате.

97% кейсов закрываются со статусом «Довольный клиент». Но так было не всегда: чем больше становилось клиентов, тем сильнее мы начали проседать. Особенно страдали кейсы, которые отдавались в разработку.

Из-за невыстроенных процессов к разработчикам попадали и сложные, и достаточно лёгкие задачи, которые на самом деле можно было бы решить силами обычной техподдержки. Это увеличило время обработки запросов. Самый коллапс случился в пандемию: компании массово стали покупать решения для дистанционного обучения. Пришлось срочно реорганизовывать работу.

Меня зовут Арина, я руководитель отдела технической поддержки iSpring. Расскажу, как переход к двухуровневой системе поддержки помог сократить время решения задач с трёх дней до трёх часов, снизить нагрузку на отдел и перестать дёргать разработчиков из-за лёгких задач.

Почему при прежней структуре техподдержки отдел не справлялся

До 2021 года отдел техподдержки состоял из одной линии: любой сотрудник в смене принимал обращение от клиента и делал всё, что в его силах. Если не хватало доступов и компетенции решить вопрос, он заводил задачу и отправлял в чат отдела разработки, занимающийся саппортовыми обращениями.

Уровень сложности задач зависел только от грейда сотрудника: запросы распределялись по уровню сложности между новичками и старшими. В каждой смене обязательно находился сотрудник грейда ПРО (он же middle) или выше. Если вопрос не получалось решить стандартными средствами техподдержки, его передавали в отдел разработки.

На первый взгляд иерархия соблюдалась. На самом деле чётких правил передачи запроса в отдел тестирования и разработки не существовало, любой сотрудник мог передать задачу туда, что и приводило к коллапсу. Техподдержку эта ситуация устраивала — но разработчики начали говорить, что запросы из саппорта отнимают много времени. Когда случилась пандемия и количество клиентов быстро выросло, мы поняли, что отсутствие иерархии вредит обоим отделам.

Схема передачи запросов до появления второй линии
Каждый год база клиентов росла. Особенно большой скачок произошел после мирового локдауна во всем мире: компании перешли на удаленный режим работы, спрос на продукты для дистанционного обучения значительно возрос.

Без выстроенной системы обработки запросов начался хаос:

Новичкам не хватало навыков, чтобы исследовать проблему клиента и найти решение самостоятельно. Им часто казалось, что они нашли баг, и они сразу передавали задачи на отдел разработки — не спрашивая мнения более опытных коллег.
Отдел техподдержи задавал вопросы разработчикам в личном чате и отвлекал их от работы. Правила, что нельзя писать в личку, раньше не было — мы ввели его позже.
Некоторые задачи стояли в очереди у отдела тестирования и разработки по несколько дней.

У нас появилось две серьёзные проблемы:

Разработчики и тестировщики тратили время на решение банальных задач вроде «посмотреть, кто удалил обучающий курс» — вместо того, чтобы заниматься развитием продукта.
Техподдержка сильно задерживала ответы клиентам: по кейсам, которыми занимались разработчики, срок доходил до трёх дней. Это тормозило или полностью блокировало работу по корпоративному обучению, которую вели клиенты внутри компаний.

Как теперь работает техподдержка

Предстояло реорганизовать работу и убрать коллапс. Мы вдохновились опытом других ИТ-компаний и решили внедрить двухуровневую систему техподдержки, чтобы:

Все задачи пропускать через вторую линию техподдержки и отдавать разработчикам, только после того как все возможные данные будут собраны.
Разгрузить разработчиков, чтобы к ним попадали только сложные задачи, которые не может решить техподдержка.

Схема передачи запросов через вторую линию
Теперь техподдержка состоит из:

первой линии,
второй линии,
отдела разработки — отдела с дежурными тестировщиками и программистами. Они решают задачи, которые не смогли решить сотрудники первой и второй линий.

Первая линия:

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

Если возникает вопрос, который первая линия решить не может, заводится задача для второй линии. Перед тем как передать задачу, первая линия собирает все вводные и проверяет, что проблема действительно существует.

Вторая линия:

Выступает в качестве экспертов для первой линии.
Закрывает простые задачи, которые передала первая линия.
Проверяет задачи, заведённые первой линией. Если есть замечания, помогает первой линии довести исследование до конца и собрать все данные перед передачей в разработку.

Важно: вторая линия не делают работу за первую линию, при этом первая линия — это не просто секретари. Они тоже решают серьёзные вопросы.

Решает задачи, для которых нужно удалённое подключение к компьютеру клиента.

Непосредственно с проджект-менеджером саппорта может общаться только вторая линия: сотрудники первой линии такого права не имеют. Разработчики получают только проверенные запросы с максимумом вводных.

Что понадобилось для открытия второй линии

Первый шаг: собрать команду второй линии внутри отдела техподдержки

Для второй линии выбрали пять самых сильных сотрудников отдела. Критерии отбора:

Работает в компании больше трёх лет.
Обладает детальными знаниями по продвинутой функциональности продукта: работа со спецификацией стандарта SCORM, взаимодействие продуктов через API, SSO — настройка единого входа.
Может урегулировать любой запрос с клиентом.
Проводит встречи с ИТ-службой клиентов.
Самостоятельно пишет документации и делает учебные курсы для всех сотрудников отдела.
Анализирует совместимости SCORM-курсов, сделанных в нашем редакторе, со сторонними LMS (системами управления обучением).

Была сложность: моментально освободить их от звонков и входящих писем мы не могли. Этот процесс идёт постепенно и продолжается до сих пор: вторая линия продолжает брать звонки и письма — но только по необходимости. Сейчас мы нанимаем и обучаем сотрудников для первой линии, чтобы освободить вторую линию от принятия входящих запросов.

Второй шаг: передать задачи разработчиков и выдать доступы второй линии

Разработчики подготовили набор типовых запросов и обучили сотрудников второй линии, как их решать:

Восстановление удалённых материалов в СДО — системе дистанционного обучения.

Сотрудник второй линии с помощью внутренних возможностей продукта может найти удалённый материал и восстановить его. Ранее этими возможностями могли воспользоваться только сотрудники отдела разработки.

Проверка, почему обучающиеся не получили уведомления в СДО.

Сотрудник второй линии по запросу клиента может проанализировать логи запросов к системе и определить, имеется ли событие отправки письма в дату и время, указанные клиентом.

Первичное исследование логов: например, поиск ошибок сервера.

Есть ситуации, которые блокируют нормальное использование системы дистанционного обучения. Выявить источник проблемы бывает сложно: причина может крыться в медленном интернете, неправильно настроенной интеграции с сервисом веб-конференций, некорректно настроенном подключении SSO или ошибочном поведении самой СДО.

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

Третий шаг: прописать правила взаимодействия между всеми

Схема работы над запросами выглядит так:

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

Какую пользу принесла двухуровневая система техподдержки

Сократили время ответа клиентам. Срок решения типовых задач сократился от трёх дней до трёх часов.

Нагрузка на отдел тестирования снизилась на 15% уже на второй месяц после введения второй линии. Такой быстрый эффект произошел, потому что часть задач до них вообще не доходит: мы решаем их силами первой и второй линии.

Программисты занимаются только сложными задачами и перестали тратить время на рутинные обращения. Разработчики теперь решают только действительно критичные проблемы.

Открытие второй линии стало драйвером роста для отдела технической поддержки. Появилась определённость: появилось понимание, какие задачи нужно выполнять, чтобы расти и повышать грейд. С момента введения второй линии три сильных инженера технической поддержки перешли на еще более высокий грейд и стали старшими инженерами.

Отдел разработки не отвлекается на личные сообщения в чатах, а разбирает сообщения только в специально отведённом чате от отдела техподдержки. Информация не хранится в личных переписках с разными людьми: она проходит через опытных инженеров второй линии и документируется для общего доступа.