Сложная техническая поддержка и мотивация: часть первая
Это моя первая заметка, поэтому буду пользоваться подсказками, выплывающими справа снизу о том, что нужно рассказать о личном опыте, что нужно быть естественным — таким же, как в жизни.
Меня зовут Кравчик Юрий, я директор и соучредитель компании «Интерра» — оператора ГЛОНАСС мониторинга транспорта и других подвижных и не очень объектов. По сути, это кусок IoT, который появился значительно раньше, чем IoT.
Моя компания начала работу в 2007 году, тогда в ней работал один человека, позже стала одним из заметных участников российского рынка. На втором году жизни компании уже появилась необходимость в построении технической службы и частью этой службы, безусловно, должен был стать отдел технической поддержки (ТП).
Имея значительный опыт в построении эффективного отдела продаж, именно этот опыт я хотел применить в конструировании отдела технической поддержки. И совершенно не представлял на сколько мелких кусочков разобьется эта идея, но обо всем по порядку.
Обычно построение отдела технической поддержки подчиняется ряду сложившихся постулатов, большая часть которых описана как ITIL.
ITIL (произносится как «айти́л», англ. IT Infrastructure Library — библиотека инфраструктуры информационных технологий) — библиотека, описывающая лучшие из применяемых на практике способов организации работы подразделений или компаний, занимающихся предоставлением услуг в области информационных технологий.
Некоторые показатели и принципы работы действительно подходят большинству структур технической поддержки, чем бы она ни занималась. Перечислю основные из них:
- Все заявки в техническую поддержку должны быть зарегистрированы и иметь уникальный номер, который используется «красной нитью» весь период жизни технической заявки.
- Ключевыми измерителем работы с заявками является хронометраж — «время реакции» — условное время между регистрацией заявки и началом работы над ней. «Время решения» — время с момента начала работы над заявкой до завершения с предоставлением ответа заявителю.
- Особо ценным трофеем является умение получать оценку заявителя по закрытой (решённой) заявке.
- Техническая поддержка разделяется на уровни с чётким разделением полномочий и компетенций, чем выше уровень, тем более сложные задачи может решать его житель или тем более они специфические, или больше ресурсов и доступов предоставлено.
Первым шагом на нашем пути запуска технической поддержки было создание среды для регистрации технических заявок и обеспечения первого пункта вышеперечисленных постулатов.
Мы выбрали программное решение и осуществили его поверхностное внедрение, а именно настроили справочники, выдали доступы и научили пользоваться тем, что выдали одного в 2008 году сотрудника технической поддержки, координатора выездных работы и менеджеров отдела продаж.
Единственная задача, которая начала с переменным успехом решаться на момент 2008 года, — это регистрация части поступивших обращений. Сотрудник ТП работал за фикс, эффективность его работы могла зависеть от гороскопа, погоды в доме, фаз луны, вкусности чая, пробки утром.
Проблемы, с которыми мы столкнулись на этом первом этапе:
- Не все заявки регистрируются: «А зачем её регистрировать, если мы сразу ответили на вопрос?» Кстати, эта проблема существует во многих службах технической поддержки разных операторов чего бы то ни было, где существует малейшая возможность так сделать.
- Масса заявок может быть зафиксирована в одной.
- Скорость решения заявки и реакция на неё зависит исключительно от проактивной позиции сотрудника ТП или от её отсутствия.
- Тексты некоторых заявителей, которые они озвучивали по телефону, были настолько суровыми, насколько они могли быть изысканными по подбору выражений — началась текучка сотрудников ТП с диагнозом «стрессоплавучесть».
На этом этапе в отделе технической поддержки работало уже три сотрудника. Какие же ответные меры мы приняли для возврата ситуации в регулируемое русло:
- Обучение сотрудников технической поддержки эффективному ведению телефонной беседы и приемов сохранения рамок приличного телефонного диалога.
- Написание серии регламентов с последующим их внедрением. Как создавать заявку, как работать с заявкой, как сообщать результаты, каким образом фиксировать результат.
- Программное туннелирование всего, что только можно, сегментация типов заявок и этапов их выполнения в зависимости от типов.
- Создание первой мотивационной схемы для сотрудников технической поддержки.
Остановимся на мотивационной схеме подробнее. Суть схемы была достаточно простой и достаточно логичной. Каждый инцидент (заявка) оценивался руководителем в баллах в зависимости от сложности, и каждый сотрудник имел план набора баллов на месяц. Зарплата зависела от выполнения и перевыполнения плана по баллам.
Рыба ищет, где глубже, а мотивированный сотрудник ищет, как обмануть мотивацию.
С этого момента любой движение любой конечностью сотрудника ТП регистрировалась в системе, почесал пятку — вот вам инцидент. Количество закрываемых инцидентов увеличилось вдвое за счёт максимального дробления заявок на отдельные.
Абсолютно все сотрудники с какого-то момента начали выполнять план на 100% и более, независимо от его недостижимости. Безусловно существенную роль играет руководитель отдела и то, насколько он беспристрастно использует мотивационную схему, однако пробелы в таком подходе были ясны, как экран ноутбука ночью.
Мы не получили проактивность, мы не решили задачу обеспечения быстрой реакции и быстрой работы с инцидентом и, что более важно, мы не сделали наш технический сервис достаточно быстрым и качественным для наших клиентов, как этого требовал рынок.
Что выбрать дальше и как действовать? В чём же сложность технической поддержки оператора ГЛОНАСС? В нашем случае техническая поддержка решает комплекс разносторонних задач:
а) Классическая регистрация и обработка технических заявок внешних и внутренних.
б) Приемка и фиксация выездных работ инженеров-установщиков в различных системах. После проведения монтажа оборудования или сервисных работы инженер-установщик обязан «сдать» их в техническую поддержку, где дежурный проверяет штатную работу всех функций, установленного оборудования и подтверждает качественно выполненную работу инженером.
в) Первичная подготовка оборудования для последующего монтажа или передаче заказчику. Любое оборудование в нашей сфере требует первичной проверки, прошивки, выведения на связь, комплектации SIM-картой, заведения на облачный сервис и прочих подготовительных действий.
г) Обработка различных бизнес-процессов, связанных с абонентским обслуживанием (приостановка, возобновление, блокировка).
д) Удалённое и выездное обучение внешних и внутренних пользователей и техническая поддержка выездных переговоров.
е) Сопровождение тестовой эксплуатации (пилотных проектов), которую мы предоставляем бесплатно нашим потенциальным клиентом. Такое сопровождение регулируется отдельным регламентом, описывающим всесторонний контроль и предупреждение любых сбойных ситуаций.
На этом этапе у нас семь человек в технической поддержке, мы занимаемся её дальнейшим тюнингом:
- Разделили нашу техническую поддержку на три уровня по компетенциям и обязанностям, при этом с учётом нашей специфики оставили каждому старшему уровню все обязанности предыдущего.
- Ввели обязательную практику обучения сотрудников отдела продаж сотрудниками отдела технической поддержки II уровня и обязательную практику обучения сотрудниками III уровня сотрудников II и I уровня. Наша схема предполагала, что мы совершенно не против, чтобы все перешли на III уровень. Переход от уровня к уровню был возможен только после прохождения комплексного обучения и сдачи экзамена с хорошими баллами. Переход на III уровень требовал дополнительной сертификации по экзамену поставщика ключевой для нас облачной платформы.
- Мотивация зависела от уровня, на котором находится сотрудник, и включала обязательные часы обучения, баллы за решение инцидентов, определенное количество дежурств по приемке выездных работ, баллы за смарт задачи, демотивирующие коэффициенты за срыв сроков решения заявок, либо срыв смарт задач. Одним из спорных и одновременно действенных демотивирующих показателей стало право на подачу служебной записки руководителем отдела продаж о штрафе за несоблюдения регламента проведения тестовой эксплуатации.
- Заказчик при закрытии заявки получал письмо с возможностью оценки качества ее выполнения в один клик, однако сбор оценок в количестве достаточном для анализа оставлял желать лучшего.
Мы получили на этом этапе значительно более дееспособное и активное подразделение. Обеспечили цикличность внутреннего обучения и передачи навыков между уровнями и между отделами. Следующая наша цель — это формирование постоянного SLA для нашей работы в целом. И обеспечение специальных SLA для ключевых заказчиков.
Об этом я напишу во второй части. Немного про Agile, Kanban, кайдзен в технической поддержке.
1. Какие программные решения используются для приёма/обработки заявок?
2. Я правильно понимаю, что ваши клиенты - это компании? Как к вам приходят заявки, от одного представителя клиента или от любого сотрудника его организации?
3. Как распределены обязанности в отделе? Ну, кроме уровней. Кто обрабатывает входящие заявки, какой функционал у сотрудников, есть ли кто-то, кто не ездит по вызовам etc.?
Цикл ваших статей обещает быть очень интересным. Жгите.
1.1. Сервис деск TerraSoft собственным разработками - во первых интеграция с 1С - собственные разработанные удобные веб сервисы для просмотра например онлайн расписания работ - разработан кабинет абонента - пишет заявки сразу в сервис-деск с выставлением реквизитов откуда получено
1.2. Битрикс 24 с открытыми линиями в том числе для технической поддержки, разработали ЧатБот БотАня - которая забегает в разные системы в том числе в сервисдеск и в кабинет Билайна и в другие сервисы. Это же бот оповещает отдел продаж о закрытии инц/заявок по их клиентам
1.3. Биллинг в 1с разработанные самостоятельно поверх УТ11 с стыковкой с сервисдеск
2. Клиенты - компании да , контактных лиц в каждой компании может быть несколько
Заявки приходят от ограниченного круга лиц. Это закреплено в SLA
3. Задачи распределяются в соответствии с расписанием - каждый пробует все роли. Распределение новых заявок осуществляет или рук отдела или тим лид или сотрудник берет сам, проявляя проактивность. Тимлид сменные - это новая тематика - расскажу об этом во второй части.
Спасибо за то что делитесь опытом. Можно ли в следующей части побольше конкретики и цифр ( план/факт и достигнутые kpi, выручка/прибыль)?
Голой теории про Agile/Kanban - завались... Но вот реальный опыт с описанием достигнутых результатов - это очень интересно, тем более в таком глобальном проекте.
Добавлю во второй части и цифры и кейсы
Канбан и Agile я практикую помимо этого основного бизнеса
Да, начальный замес дров хороший. Почитаем.
Чуть позже внимательнее перечитал за завтраком. Появились вопросы:
1. Почему техническая поддержка выполняет в том числе не технические, а административные процедуры, которые должны выполнять менеджеры (пункты б и г)?
2. "при этом с учетом нашей специфики оставили каждому старшему уровню все обязанности предыдущего." - насколько повышалась ответственность и, соответственно, зарплата?
3. Какова была текучка кадров в момент тюнинга?
Комментарий недоступен