Сложная техническая поддержка и мотивация: часть первая

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

Меня зовут Кравчик Юрий, я директор и соучредитель компании «Интерра» — оператора ГЛОНАСС мониторинга транспорта и других подвижных и не очень объектов. По сути, это кусок IoT, который появился значительно раньше, чем IoT.

Моя компания начала работу в 2007 году, тогда в ней работал один человека, позже стала одним из заметных участников российского рынка. На втором году жизни компании уже появилась необходимость в построении технической службы и частью этой службы, безусловно, должен был стать отдел технической поддержки (ТП).

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

Обычно построение отдела технической поддержки подчиняется ряду сложившихся постулатов, большая часть которых описана как ITIL.

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

• Все заявки в техническую поддержку должны быть зарегистрированы и иметь уникальный номер, который используется «красной нитью» весь период жизни технической заявки.
• Ключевыми измерителем работы с заявками является хронометраж — «время реакции» — условное время между регистрацией заявки и началом работы над ней. «Время решения» — время с момента начала работы над заявкой до завершения с предоставлением ответа заявителю.
• Особо ценным трофеем является умение получать оценку заявителя по закрытой (решённой) заявке.
• Техническая поддержка разделяется на уровни с чётким разделением полномочий и компетенций, чем выше уровень, тем более сложные задачи может решать его житель или тем более они специфические, или больше ресурсов и доступов предоставлено.

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

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

Единственная задача, которая начала с переменным успехом решаться на момент 2008 года, — это регистрация части поступивших обращений. Сотрудник ТП работал за фикс, эффективность его работы могла зависеть от гороскопа, погоды в доме, фаз луны, вкусности чая, пробки утром.

Проблемы, с которыми мы столкнулись на этом первом этапе:

1. Не все заявки регистрируются: «А зачем её регистрировать, если мы сразу ответили на вопрос?» Кстати, эта проблема существует во многих службах технической поддержки разных операторов чего бы то ни было, где существует малейшая возможность так сделать.
2. Масса заявок может быть зафиксирована в одной.
3. Скорость решения заявки и реакция на неё зависит исключительно от проактивной позиции сотрудника ТП или от её отсутствия.
4. Тексты некоторых заявителей, которые они озвучивали по телефону, были настолько суровыми, насколько они могли быть изысканными по подбору выражений — началась текучка сотрудников ТП с диагнозом «стрессоплавучесть».

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

1. Обучение сотрудников технической поддержки эффективному ведению телефонной беседы и приемов сохранения рамок приличного телефонного диалога.
2. Написание серии регламентов с последующим их внедрением. Как создавать заявку, как работать с заявкой, как сообщать результаты, каким образом фиксировать результат.
3. Программное туннелирование всего, что только можно, сегментация типов заявок и этапов их выполнения в зависимости от типов.
4. Создание первой мотивационной схемы для сотрудников технической поддержки.

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

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

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

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

Что выбрать дальше и как действовать? В чём же сложность технической поддержки оператора ГЛОНАСС? В нашем случае техническая поддержка решает комплекс разносторонних задач:

а) Классическая регистрация и обработка технических заявок внешних и внутренних.

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

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

г) Обработка различных бизнес-процессов, связанных с абонентским обслуживанием (приостановка, возобновление, блокировка).

д) Удалённое и выездное обучение внешних и внутренних пользователей и техническая поддержка выездных переговоров.

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

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

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

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

Об этом я напишу во второй части. Немного про Agile, Kanban, кайдзен в технической поддержке.