Привет, Хабр! Меня зовут Дима, я руковожу отделом информационных технологий бэк‑офиса в «Петрович‑Тех».

Представьте: пользователи не могут начать работу в системе. Не испытывают сложности через день или неделю, а прямо на старте не имеют возможности начать пользоваться продуктами компании.

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

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

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

В примерах в этой статье речь пойдёт в первую очередь о внутренних пользователях, сотрудниках компании. Проблемы, с которыми коллеги могут столкнуться “прямо на старте” – например, не запускается удаленный рабочий стол, где работает 1С; такие ситуации могут быть критическими блокерами для рабочих процессов. Именно для внутренних пользователей мы исторически делали описываемые ниже изменения в процессах; с внешними юзерами стали практиковать подобное позже.

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

Цель проекта по реорганизации поддержки сформулировали так: для 60% обращений уменьшить время ожидания до 4 часов, то есть в 12 раз.

Главной проблемой, для которой требовалась скорость решения, была сложность с подключением в работу: не открывается 1С, не запускается программа для приёма звонков, не включается VPN. В поисках причин мы декомпозировали продукты. Например, упомянутый выше VPN мы разложили по типам ошибок: 691, 806, 807 и так далее. Нашли типы запросов, из-за которых происходит сбой подключения в работу – у программы по звонкам это запросы о запуске, подключении гарнитуры, открытии анкеты. Решением была консультация пользователей: куда посмотреть и что нажать для исправления.

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

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

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

Конечно, не обошлось без трудностей.

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

Тогда для усиления команды мы пошли искать внешних исполнителей. ИТ-аутсорс выставил цены, на которые мы не были морально готовы в тот момент, так что мы попробовали отдать задачу аутсорсинговому контакт-центру. Опыт их консультаций был успешным: их сотрудники были мотивированы на работу с обращениями, потому что мы платили за число обработанных заявок – они отрабатывали доход компании. 

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

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

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

Тогда мы решили создать первую линию внутри компании. Начали с одного специалиста, который вручную брал задачи из очереди. Сотрудник до этого работал на второй линии, механика не изменилась, так что показатели по отделу не улучшились.

Процесс требовал полной реконструкции.

Запуск первой линии: что сработало

Итак, мы решили сделать две линии поддержки: первую – чтобы быстро решать простые обращения, не задерживая их в общей очереди с сложными; вторую – для решения сложных обращений.

Вариант, который пережил запуск, продолжает существовать и развиваться, состоит из нескольких составляющих. Это процессы, люди, интерфейс и метрики эффективности. Рассмотрим их по порядку.

Процессы

Чтобы увеличить скорость обработки заявок, мы приняли решение не переписываться с пользователями, а созваниваться и консультировать голосом. Для этого пришлось задействовать отдельное программное обеспечение. Мы настроили интеграцию между ВАТС и ServiceDesk. 

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

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

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

Теперь процесс занимает 10 секунд: специалист первой линии нажимает на кнопку, и исполнитель второй линии назначается автоматически с помощью ServiceDesk. 

Сейчас в правиле выбора исполнителя стоит 19 условий передачи. Например, если обращение пришло от подразделения Контакт-центр по типу "Проблема в работе ПК", "Оргтехника", "Проблема с сетью", то запрос перенаправляется на системного администратора Контакт-центра. Если пришло обращение от любого сотрудника компании по корпоративному порталу, то назначается на специалиста второй линии поддержки, отвечающего за портал. Общую схему условий передачи можно посмотреть на скриншоте ниже.

В правилах автоматизации прописаны шаблоны ответов для пользователей и комментарии для первой линии, что кому требуется сделать. Например, такие скрипты уменьшают время на обработку заявок:

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

• Автор не отвечает на комментарий первой линии 2 часа, необходимо позвонить автору и уточнить информацию. В случае, если не удастся дозвониться, нажмите кнопку "Недозвон".

• Вторая линия вернула обращение на первую линию.

Всего сделано 12 настроек автоматизации. С их помощью мы не тратим время сотрудников поддержки.

Люди

Неожиданно минусом изначального варианта решения стало то, что на первой линии у нас был специалист из второй. Сотрудник отвык от общения голосом и при любой возможности продолжал работу текстом. Мы решили проблему, когда перевели его с первой линии на роль старшего специалиста. Прагматическая сторона здесь заключалась в том, что была доказана эффективность первой линии и согласован рост команды до 6 специалистов. Нужен был лидер для работы с персоналом и дальнейшего развития направления. А мы тем временем взяли нового сотрудника первой линии.

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

• Нет инструкции

• Инструкция не работает

• Просили передать (определенному сотруднику)

• Выдача оборудования в офисе

• Категоризация

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

С новыми решениями сотрудники могут перезвонить пользователям в удобное для них время, а пользователи – оценить качество обслуживания после разговора или решения тикета в ServiceDesk. Также мы создали дополнительное поле с ID для удалённого подключения, чтобы сотрудник мог оперативно войти и решить проблему без лишних уточнений у пользователей.

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

Интерфейс

Мы постарались сделать интуитивно понятный интерфейс для первой линии. Столкнулись со сложностью формирования процесса в ServiceDesk: не было разделения времени первой и второй линии, SLA первой линии мог влиять на аналогичный показатель второй линии и наоборот. Мы отделили SLA друг от друга для корректного подсчёта. Для этого нам пришлось полностью переделывать воркфлоу, добавлять новые статусы и переходы. 

При всей комплексности новый интерфейс разграничивает линии поддержки. Каждый сотрудник видит только свои кнопки, все элементы появляются при определенных условиях. Например, вначале есть только кнопка «В работу», после её нажатия появляется «Не дозвонились» и «Решено».

Так как информации для первой линии очень много, мы создали отдельную базу знаний.

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

Метрики

Первая линия за год пропускает через себя 28 000 тысяч обращений и работает с 15 ИТ-сервисами, поэтому требуется отслеживать показатели эффективности на каждом шаге. 

У нас порядка 30 метрик, которые мы оцениваем, чтобы держать на высоком уровне качество работы первой линии. Мы смотрим на следующие показатели: 

• время в очереди, 

• время решения, 

• доля переданных обращений с первой на вторую линию, 

• доля возвращённых со второй на первую линию, 

• количество пропущенных вызовов, 

• удовлетворённость в заявках и в звонке, 

• опоздание выхода на линию специалистом первую линии и другие.

Для рассмотрения спорных ситуаций мы используем записи разговоров и запись рабочего стола. Так мы отслеживаем, какие проблемы есть в работе, и оперативно отлаживаем процесс.

Мы ограничили время, которое может использовать специалист первой линии на решение одной заявки. Сотрудник сам определяет, передать задачу на вторую линию или доделать самостоятельно, но у каждого есть показатель: 80% обращений решаются в течение 10 минут. То есть 20% обращений могут обрабатываться дольше. 

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

Распределение обращений по сложности помогает держать высокий уровень сервиса и планировать ресурс на разные периоды загрузки. Более подробно можно посмотреть в лучших мировых практиках ITIL в описании процесса Service Desk.

Первая линия: довольные пользователи, мотивированные сотрудники

Реорганизация поддержки началась в 2021 году. Сейчас на первой линии работает 15 человек. Для них составлено 8 разных графиков, чтобы перекрывать нагрузку в пиковые моменты, а в минимально загруженные периоды не держать лишних специалистов.

Какие результаты мы получили:

• Пользователей с простыми обращениями довольны скоростью нашей работы: по оценкам в ServiceDesk удовлетворенность выросла с 92% до 96%.

• Вторая линия избавилась от “неинтересных” запросов.

• Бонусом мы получили кадровый резерв для второй линии и более мотивированных сотрудников: порядка 40% специалистов из первой линии получили рост во вторую.

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

Надеюсь, этот опыт подсветит вам если не готовый вариант решения для обработки потока входящих запросов, то пути к нему и острые углы по дороге!