Руководство по организации технической поддержки

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

В этой статье мы разберем функции и особенности четырех линий поддержки, которые:

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

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

Первая линия техподдержки

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

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

С точки зрения компании первая линия позволяет не тратить время квалифицированных технических специалистов на банальное общение по телефону.

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

В задачи специалистов первой линии также входит держать клиентов в курсе решения их вопроса. Да и в целом нести в себе клиентоориентированность.

А с точки зрения конечного пользователя первая линия — это единая точка входа в сервисную компанию.

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

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

Первая линия может даже решать часть пользовательских вопросов. Но здесь важно не путать эту линию с профильными специалистами.

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

Кроме того, первая линия не занимается выездными работами.

Механика работы первой линии

Специалисты первой линии выполняют следующие действия:

• Принимают звонок или клиентское обращение по любому другому каналу связи. Непрофильные обращения — если позвонил не клиент или клиент обращается с проблемой, которая находится вне зоны компетенции компании — отфильтровываются.
• Регистрируют обращение в используемом средстве сбора информации (например, в бумажном журнале или в системе автоматизации хелпдеск, в зависимости от того, что используется в организации).
• Если обращение простое и его можно закрыть на первой линии, то специалист предлагает клиенту свое решение (обычно из списка типовых). Если оно помогло, закрывает заявку. Кстати, фиксировать заявку в системе автоматизации или журнале необходимо даже в этом случае, чтобы иметь полную картину работы техподдержки.
• Как правило, для распределения заявки между исполнителями на следующей линии, необходимы данные для ее классификации. Специалист первой линии задает клиенту дополнительные вопросы, если этой информации не было в первоначальном запросе.
• Объясняют клиенту, как работа с его заявкой будет осуществляться дальше — кто и в какие сроки возьмет ее в работу, когда ждать ответа.
• Созданную заявку передают конкретному специалисту или диспетчеру, осуществляющему распределение (в зависимости от принятой в компании технологии работы). На первой линии также могут выставляться приоритеты обращений.
• Первая линия может принимать участие и в дальнейшей работе по заявке, если от клиента потребуются уточнения. Как правило, именно специалисты первой линии звонят контактному лицу, чтобы выяснить необходимые подробности.
• После закрытия заявки зачастую именно специалисты первой линии собирают обратную связь от клиентов. Через некоторое время после завершения работы по обращению они выборочно обзванивают клиентов для получения развернутого отзыва.

Часть функций первой линии может быть автоматизирована, например при помощи help desk Окдеск.

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

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

Однако полностью заменить первую линию программным инструментом нельзя, поскольку функцию поддержания контакта с клиентом (и в целом следование политике клиентоориентированности) автоматизировать невозможно.

Какие специалисты нужны для первой линии

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

Инструменты первой линии

При приеме клиентских обращений по телефону первая линия работает с двумя основными инструментами:

• программная или аппаратная АТС;
• инструмент фиксации и обработки обращений — это может быть любое средство от бумажного журнала до облачной системы автоматизации help desk.

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

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

KPI первой линии

Обычно работу специалистов первой линии измеряют по аналогии с колл-центрами, применяя следующие метрики:

• количество обработанных обращений;
• время реакции на обращение;
• длительность обработки входящего обращения;
• доля заявок, закрытых при первом обращении.

Подробнее о KPI техподдержки мы писали ранее в этой статье.

Вторая линия техподдержки

Вторая линия занимается решением основной массы пользовательских проблем.

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

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

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

Механика работы второй линии

Специалисты второй линии выполняют следующие действия:

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

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

Какие специалисты нужны на второй линии

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

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

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

Инструменты второй и последующих линий

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

В ИТ это могут быть:

• средства удаленного доступа к рабочим местам клиентов;
• инструменты диагностики и мониторинга оборудования.

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

KPI второй и последующих линий

Работу специалистов второй линии можно оценивать по следующим метрикам:

• доля решенных обращений;
• длительность работы над каждым обращением;
• средняя оценка решенных заявок, выставленная клиентом.

Обратите внимание, эти KPI в большей степени фокусируются на качестве решения проблемы, а не на количестве обработанных заявок (как это было с KPI для первой линии). Рекомендуем обратиться к более подробному описанию каждой из этих метрик.

Отслеживать KPI, в частности контрольные сроки выполнения заявок на всех линиях поддержки в режиме реального времени помогают инструменты автоматизации хелпдеск.

Третья линия техподдержки

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

Как правило, это новые, ранее не проявлявшиеся проблемы или инциденты, имеющие масштабные последствия (и требующие быстрых и четких действий для устранения).

Выделение третьей линии связано с тем, что для решения некоторых вопросов нужны «дорогие» и редкие специалисты.

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

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

Механика работы третьей линии

Специалисты третьей линии:

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

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

Какие специалисты нужны на третьей линии

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

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

Четвертая линия техподдержки

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

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

Кстати, не всегда третья и четвертая линия разделены.

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

Как и коллеги с третьей линии, специалисты четвертой линии не общаются с конечными клиентами.

Вместо заключения

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

Главное, что должна быть продумана технология работы и правила передачи заявок между специалистами. Схема с линиями — общепринятый подход, который легко подстроить под собственные нужды. Помогают в такой подстройке инструменты автоматизации help desk. К примеру, Okdesk позволяет:

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

В этом материале мы расскажем на примере нашей компании, как организовать техническую поддержку клиентов. Для удобства как клиента так и самой компании, мы организовали ИТ-поддержку EFSOL по принципу «единого окна» — все обращения стекаются в одну точку и далее обрабатываются. Такой точкой является Ticket-система Абонцентр. Данный продукт является собственной разработкой компании, построенной на базе конфигурации 1С 8.3 «Управление торговлей». Инциденты в системе обрабатываются следующими способами (иллюстрация показана на рисунке 1):

Рисунок 1 — Схема регистрации инцидента

Постановка задачи клиентом

Web-интерфейс. Нужно заполнить форму на сайте. Здесь же возможно увидеть все свои задачи, статусы по ним, комментарии исполнителя и прочую информацию.

Email. Просто нужно отправить письмо на адрес Абонцентра с почты, которая указана при регистрации контрагента. По адресу отправителя будет происходить идентификация компании и конкретного ее сотрудника и далее инцидент будет передан закрепленному за клиентом ИТ-инженеру.

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

Проактивное реагирование на инцидент

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

За каждым клиентом закрепляется личный ИТ-инженер, который обрабатывает обращения клиента в рабочее время компании. В случае возникновения обращения на выходных с инцидентом работает дежурный ИТ-инженер, а в ночное время — служба круглосуточной поддержки. Если у дежурного инженера или круглосуточного оператора возникают трудности с разрешением инцидента — к его решению привлекается закрепленный инженер. Далее, если инженер не может разрешить инцидент, он поднимается на уровень руководителя модуля поддержки (TeamLead), то есть происходит горизонтальная эскалация. Если же у ТимЛида не достаточно организационных полномочий или ресурсов для решения задачи – происходит вертикальная эскалация инцидента и его разрешениям занимается руководитель ИТ-отдела. Схема показана на рисунке 2.

Рисунок 2 — Схема разрешения инцидента

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

Рисунок 3 — Схема закрытия инцидента

Время на прочтение
6 мин

Количество просмотров 1.9K

Привет, Хабр! Меня зовут Станислав Романов, я руковожу всем техническим контентом коммуникационной платформы МТС Exolve. О том, что такое МТС Exolve, вы можете узнать из этого материала. А в этой статье я расскажу о том, как грамотно организовать техподдержку, настроить все системы, и как расширить клиентскую базу и увеличить продажи без повышения рекламных бюджетов и модернизации производства. 

Исследования Invesp доказывают, что затраты на удержание существующих покупателей до 25 раз меньше, чем на привлечение новых. Больше половины потенциальных клиентов становятся реальными, узнав о качественном обслуживании. А 78% готовы простить некоторые проблемы, если до этого вопросы были успешно решены техподдержкой.

Инструкция по созданию подразделения 

Организация технической поддержки пользователей реальна. Ниже – инструкция, как запустить работу такого подразделения и не терять клиентов. 

Выбор каналов коммуникации

По исследованию Statista, в 2022 году клиентами используется:  

• электронная почта;

• чат в приложении или на сайте;

• соцсети;

• телефон;

• текстовые сообщения.

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

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

Настройка мониторинга

Необходимо отслеживать обращения и быстро отвечать на них. Опрос Forrester показывает, что клиенты успешнее покупают, если быстрее получают ответы на вопросы. 

Лучше собрать все каналы для мониторинга в одном окне. Это снижает себестоимость поддержки и увеличивает рентабельность бизнес-процессов. 

Формирование квалифицированной команды

Удобное ПО для работы техподдержки важно, но ещё важнее — сотрудники, которые будут общаться с клиентами.

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

Ещё важны soft skills, способность работать в коллективе, стрессоустойчивость. 

Запуск каналов самообслуживания

Эти каналы снижают нагрузку на сотрудников и увеличивают удовлетворённость клиентов. Вот примеры каналов:

• страница с ответами на часто задаваемые вопросы;

• база знаний на сайте интернет-магазина;

• чат-бот, способный решать типовые задачи.

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

Можно даже прибегнуть к боту на базе GPT-3, и с помощью PHP и JavaScript научить его отвечать на вопросы, опираясь на доступную базу знаний. Есть инструкции по этой теме.

Определение KPI

Чтобы выстроить и контролировать отдел технической поддержки, нужно выбрать характеристики эффективности — реально достижимые показатели. 

В качестве KPI можно использовать:

• время от обращения до первого ответа;

• среднее время реагирования на обращение клиента;

• общее количество обратившихся;

• количество сообщений, на которые менеджер не ответил в установленный регламентом срок;

• процентное соотношение поступивших и решённых запросов;

• оценка удовлетворённости клиента.

Можно вводить качественные метрики: грамотность, вежливость, полнота ответа оператора. 

Исследование Zendesk показывает, что 80% откажутся от дальнейшего общения с брендом при первом негативном опыте общения с представителями компании. Для отслеживания всех параметров качества важно документировать общение и контролировать его. 

Эти KPI вы можете считать сами, что трудно и долго; через любую систему для поддержки; если там маловато функций, то можно прибегнуть к сбору данных в любую платформу с помощью Statistics API.

Для формирования лояльного отношения к бренду и повышения индекса удовлетворённости стоит персонализировать общение. Это увеличивает конверсию на 8%. Лучше использовать скрипты для операторов. Тем более что 80% клиентов сообщили, что для них опыт взаимодействия с представителями так же важен, как качество продаваемых товаров или услуг.

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

Запрос обратной связи

Обязательная часть работы техподдержки — обратная связь от клиентов. Это помогает проконтролировать работу менеджеров, выявить и устранить «узкие места» в их работе. Для этого настраиваются CSI-запросы по почте, в виде голосового меню, сообщения в мессенджере, опроса на сайте. Мы писали об этом в блоге Exolve.

Типовые вопросы:

• помог ли оператор решить возникший вопрос?

• комфортно ли общаться с менеджером?

• как долго клиент ожидал ответа?

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

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

Пример 1

Компания по продаже путешествий предлагала свои услуги «холодному» кругу клиентов. Но с помощью уже используемых программ не могла отследить KPI подразделения в целом и результативность продаж каждого менеджера. 

С помощью коммуникационного сервиса Amadeus Travel API, который интегрировали в CRM, компания начала фиксировать результаты переговоров, оценивая их по нескольким метрикам: удовлетворённость клиента, длительность разговора, конверсия и другим. Благодаря этому удалось выявить успешных менеджеров. Они обучали новый персонал. В этом процессе пригодилась запись и анализ разговоров. 

В результате повысили объёмы продаж на 23%, не увеличивая штата менеджеров. В блоге Amadeus, кстати, немало полезных материалов для этой отрасли.

Пример 2

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

Тогда наняли разработчиков, которые создали собственное ПО для работы службы технической поддержки. Коммуникационный сервис для звонков и общения через мессенджеры подключался через API. 

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

Средства автоматизации

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

Самые очевидные системы: Юздеск, IntraDesk, Омнидеск. 

Но при интеграции сервисов с помощью API можно быстрее объединять все диалоги, из разных мессенджеров и каналов связи, которые получили негативные оценки. Руководитель получает возможность разобраться в профиле клиентов, причинах проблемы и принять управленческие решения.  

Преимущества очевидны:

• Менеджерам не нужно выполнять техническую работу. Множество рутинных задач уйдут на плечи API.

• Сотрудники получают доступ ко всем данным о клиенте. Благодаря этому они могут составить полную картину о нём, персонализировать поддержку и быстро решить проблему. 

• Поддержка независима от канала. Автоматизация позволяет коммуницировать с покупателями и заказчиками в любом месте и любое время. Вся история общения будет перед глазами.

• Разделение на уровни техподдержки. Можно создавать 3-4 линии с менеджерами разной квалификации, оптимизируя тем самым работу сотрудников и снижая затраты на оплату их труда. 

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

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

Спасибо за уделенное статье время! Надеюсь, наш опыт поможет вам в построении самой эффективной технической поддержки. Если у вас есть вопросы или замечания – с удовольствием отвечу на них в комментариях!

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

Начало

Для любой компании, чей бизнес связан с пребыванием в онлайне, рост и развитие приводят к увеличению не только прибыли, но и нагрузки. И вот вы сталкиваетесь с необходимостью масштабировать инфраструктуру и наращивать ресурсы, потому что без этого надёжная и непрерывная работа проекта просто невозможна. Нужны люди, которые будут следить за его работоспособностью и оперативно реагировать на возникающие проблемы. Общепринятое определение для такой команды — «служба технической поддержки».

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

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

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

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

3 линии

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

Первая линия

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

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

Вторая линия

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

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

Третья линия

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

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

Инструменты

База знаний

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

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

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

Мониторинг

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

Бэкапы

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

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

Тикетная система

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

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

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

Каналы взаимодействия

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

Менеджмент задач

Не всегда техподдержка 24/7 — это только реакция на аварии. Наши сотрудники обеспечивают полный цикл жизни задач по сопровождению системы:

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

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

Менеджмент инцидентов

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

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

Вместо вывода: 50 оттенков и 100 нюансов…

Организация службы техподдержки требует достаточно большого количества времени, ресурсов и не только. Обучение персонала, внедрение инструментов, адаптация процессов — всё это тернистый путь, полный скрытых грабель. На него можно вступить самостоятельно, получая зачастую сомнительное удовольствие от встречи с этими граблями и на собственном опыте разбираясь во всех оттенках и нюансах процесса организации службы техподдержки. Или можно довериться тем, кто уже разведал дорогу. У нас на поддержке находится более 400 разнообразных проектов, и мы всегда готовы принять к себе еще. Если же вы решили справиться собственными силами, мы всегда поддержим морально и проконсультируем по каждому шагу и этапу!

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