Построение процессов техподдержки

Построение процессов техподдержки
Для того, чтобы организовать техническую поддержку необходимо разобраться, для чего она нужна, как она работает и как устроена изнутри.
Создание технической поддержки не должно происходить спонтанно, ведь в текущих реалиях, техническая поддержка все чаще представляет собой отдельные подразделения со своей методологией. Очень важно правильно выстроить структуру подразделения, разработать регламенты работы и обзавестись командой.
Обычно, по всем вопросам изменения, консультации и поддержки продукта заказчик обращается к технической поддержке через согласованный канал коммуникации. Далее, в зависимости от типа обращения, его эскалируют на соответствующий уровень от L1 до L3 для дальнейшего решения. Помимо работы с обращениями клиента, в задачи технической поддержки так же входит сбор обратной связи и повышение лояльности клиентов.
Запросы от клиента могут быть нескольких типов:
1. Инцидент. Сообщение о сбое / недоступности услуги.
2. Запрос на обслуживание. Это запрос пользователя на консультацию или обслуживание.
3. Запрос на изменение. Этот вид запроса подразумевает внесение изменений, добавление или удаление поддерживаемого функционала.
4. Именно эти запросы отрабатывают специалисты различных линий поддержки.
Cпециализированные сотрудники, которые являются точкой контакта между пользователями услуги и специалистами IT-отдела. Они общаются непосредственно с пользователями (телефонная линия, чаты и мессенджеры, почта), отвечают на их несложные типовые вопросы и проводят консультацию.
Обладает расширенным набором инструментов, большей технической компетенцией и более глубоким пониманием поддерживаемого продукта. Они решают более сложные и нестандартные вопросы, которые не требуют прямого вмешательства в код продукта.
Это разработчики продукта. В их зону ответственности входит решение запросов, которые не могут решить специалисты первых двух линий из-за высокой сложности.
Так же стоит учитывать, что если функционал поддерживаемого приложения находится у стороннего поставщика услуг, то необходимая информация будет передаваться внешнему специалисту согласно установленного регламента.
Не зависимо от типа запроса, услуга должна предоставляться в сервисное время, прописанное в SLA.
Чтобы соблюдать согласованный уровень качества, специалисты поддержки изучают приложение клиента (заказчика). Этот этап часто называют «Передача сервиса».
Сам этап Передачи сервиса может состоять из нескольких последовательных шагов:
1. Шаг подготовки, на котором проводится общий анализ и оценка возможных рисков, изучается история клиентских запросов и подготавливаются прочие запросы.
2. Вторым шагом следует Передача услуг. Здесь проводится передача знаний (обучение), подготовка и написание документации и рабочих инструкций, а также настройка необходимого окружения.
3. Третьим шагом следует Поддержка. Осуществляется запуск проекта и подготовка отчетной документации об успешной передаче сервиса на поддержку. На всех шагах часто происходит сбор информации, чтобы зафиксировать вводные данные, подготовиться к обучению и для написания актуальной базы знаний.
Если у вас уже создано соглашение SLA, определена структура и зоны ответственности по уровням, можно переходить к созданию/определению каналов взаимодействия с пользователями и клиентом. Это поможет систематизировать поступающие обращения и упорядочить действия сотрудников поддержки. Это так же позволяет отследить историю взаимодействия с пользователем/клиентом, и при необходимости провести анализ и выгрузить статистику обращений. Идеально, если все коммуникации реализованы в одном инструменте.
Немаловажным фактором в организации работы и рабочих процессов является задание командного духа и настроя команды. Можно проводить различные мероприятия, ежедневные/еженедельные встречи с командой. Если сотрудники будут обмениваться опытом и мыслями, обсуждать новые идеи и применять их в дальнейшей работе, то заряд позитива и рабочий настрой быстро пойдут в гору. Не стоит забывать, что в сервисе работают люди, и от их настроя, понимания специфики работы и знания особенностей продукта, зависит огромная часть успеха технической поддержки в целом.

Инструменты для построения процессов техподдержки

Для технической поддержки важны инструменты, используемые в работе. Под инструментами подразумевается всё то, что ежедневно используется в работе, от сложных систем мониторинга до базы данных и таблицы с шаблонами ответов.
База знаний
В работе технической поддержки не обойтись без базы знаний. Здесь содержится описание поддерживаемых продуктов, различные инструкции и описание ошибок, уровни эскалации и многое другое.
Во первых, база знаний поможет систематизировать все шаблоны ответов и возможные кейсы, которые не придется искать в разных документах и переписках с коллегами. Во вторых, создание базы знаний позволяет разработать шаблон решений на большую часть поступающих обращений.
Во первых, база знаний поможет систематизировать все шаблоны ответов и возможные кейсы, которые не придется искать в разных документах и переписках с коллегами. Во вторых, создание базы знаний позволяет разработать шаблон решений на большую часть поступающих обращений.
При создании базы знаний нужно учитывать, какую информацию могут вносить специалисты разных уровней, обозначить их зоны ответственности.
Системы мониторинга
Так как одной из основных задач сотрудников технической поддержки является своевременное реагирование на инциденты и сбои в системе, стоит задуматься об организации системы мониторинга. Однако важно проработать определенный порядок действий и эскалации при работе с алертами. Сотрудники должны знать, к кому обращаться в случае спорных ситуаций.
Кроме того, важно отслеживать нагрузку на сотрудников и качество поступающих алертов.
Система тикетов
Если помимо реакции на инциденты нужно фиксировать и решать задачи, то в работе пригодится система тикетов. Система позволит хранить и анализировать информацию по рабочим задачам, что поможет повысить качество работы.
Подводя итог, организация технической службы IT-сервиса трудоемкий процесс, включающий в себя формирование полноценной базы знаний для аккумулирования всей собранной информации по проекту, включая решение по багам, инцидентам, часто возникающим типовым ситуациям и их решениям. Налаженную систему алертинга и мониторинга по системам, чтобы появилась возможность отслеживать инциденты и вовремя на них реагировать, видеть изменения, происходящие в системе. И для фиксации обращений формируется дополнительно зона коммуникации с пользователем, иначе тикет-система. Это может быть мессенджер, почта, битрикс, своя система клиента или полноценный Help Desk сервис. Сбор информации по обращениям пользователей, позволяет провести аналитику сервиса и выявить проблемные зоны и недоработки, которые напрямую влияют на бизнес клиента и останавливают рабочие процессы. Комплексный подход к техподдержке оказывает положительное влияние на сервис как и для разработчиков продукта, освобождая им время для более важных и сложных задач, так и для самих пользователей, облегчая им погружение в сложный IT-процесс, минимизируя взаимодействие с разработчиками и позволяя им не отвлекаться от своих прямых задач в бизнесе.
Прокрутить вверх

Обсудить проект

Заполните форму и мы свяжемся с вами в течение рабочего дня