Делать техподдержку это как ехать на велосипеде, который горит. И ты горишь. И все горит. И ты в аду.
Как выбраться из ада, потушить велосипед и отстроить прибыльную услугу с идеальным клиентским сервисом, расскажу в статье.
Буквально пару лет назад услуги студии ограничивались разработкой и продвижением сайтов. Сайты были простыми, обслуживания требовали минимального, за доп работами клиенты приходили редко и не системно.
Однако по мере роста бюджетов и сложности проектов, задачи по поддержке возникали все чаще и вслед за этим возникла необходимость систематизировать эту работу.
Версия техподдержки 1.0
Задачи принимались по любым каналам: почта, телефон, мессенджеры. Менеджер бросал работу и тут же бежал их оценивать После оценки передавал клиенту.
Письменно, а чаще - на словах заключалось соглашение о выполнении Задача уходила в работу После работы долго согласовывали сделанное и приводили в соответствие с тем, что есть.
Как результат, задачи терялись, многократно пересогласовывались, исполнение и сдача затягивалась. Клиенты были недовольны и при этом несколько задач трудоемкостью по 5-6 часов, намертво блокировали менеджера на неделю.
Версия техподдержки 2.0
Всех клиентов перевели в этикетную систему. Задачи перестали теряться, появился более системный подход. Но остались проблемы с документооборотом, правильным сбором данных, оценкой задач и учетом рабочего времени.
Свои проблемы и клиентские пожелания мы собрали в один список и выработали регламент поддержки, при котором максимально соблюдаются интересы обеих сторон.
В итоге получили список пожеланий обеих сторон:
Что хочет от поддержки клиент
Ставить задачи в удобный ему канал
Всегда понимать, сколько это будет стоить
Вести минимум бумажной работы
Максимально быстро получать задачи выполненными
Получать мгновенный отклик от менеджера и программиста
Что хочет от поддержки студия
Принимать задачи в единую тикетную систему
Получать задачи максимально подробно, чтобы быстро и точно оценить
Вести минимум бумажной работы
Равномерно загружать менеджеров и программистов
Максимально быстро сдавать выполненную работу
Как видите, часть пожеланий пересекается, а часть наоборот, выглядит противоположной.
Как мы разрешаем противоречия и обеспечиваем выполнение пожеланий обеих сторон в реальных проектах.
Техподдержка версия 3.0
Главная сложность - перевести клиента, не привыкшего к таcк трекерам на постановку задач в тикетах.
Первое время приходится часто отвечать на звонки словами «напишите в Тикет», но через время это начинает происходить само.
Для ведения проектов мы используем дописанный под нас Битрикс24.
Тикеты формируют входящую очередь на менеджера и позволяют ему работать без прерываний в режиме равномерной загрузки при неравномерном входящем потоке задач. В среднем ответ на тикеты приходит через 2 часа, максимальное время ответа - 4 часа. Для этого достаточно проверять тикеты дважды в день.
Из них уже менеджер формирует очередь на оценку и на исполнение программисту.
Вторым шагом нужно приучиться запрашивать максимально подробные вводные до того, как начать оценку и работу по задаче. Это позволяет точно и с минимальными рисками оценивать работу, а затем выполнить ее без правок за один подход.
Таким образом клиент всегда понимает, сколько будет стоить задача до ее начала, а менеджер может планировать краткосрочную загрузку программиста.
Важно понимать, что оценка задачи, это тоже задача. И соответственно, если клиент ставит несколько задач и не окупает их, то он создает избыточную нагрузку на разработчиков. В этом случае договором регламентируется оплата времени, потраченного на оценку.
Для максимального снижения бумажной работы, между Клиентом и Студией заключается Договор, опирающийся в своей сути на этикетную систему: оценку времени в тикетах, постановку и приемку в них задач. Обмен документами совершается один раз в месяц в установленную дату.
Чтобы задачи ставились в работу максимально оперативно, нужно долгосрочное планирование времени разработчика и менеджера. Для этого существует предоплатная система расчетов. Клиент выкупает изначально определенное количество времени, которое «сгорает», если не было использовано за месяц (или за год, если пакет времени большой).
Теперь программист заблокирован под его задачи и может приступить к ним сразу после согласования и оценки.
Это позволяет также планировать время загрузки в долгосрочной перспективе.
Учет рабочего времени
Над задачей работают программист, тестировщик, менеджер, иногда - дизайнер и верстальщик.
Их время учитывается тайм трекером при выполнении задач и идет для расчета внутренних KPI
Сложности, которые возникают в поддержке сейчас, складываются в отдельную группу в Битрикс24, обсуждаются и внедряются в работу.
Бумажные формальности
Шаблон договора поддержки можно скачать по ссылке
Результаты внедрения
В рамках новой системы мы можем закрывать до 600 часов техподдержки в месяц и при необходимости можем достаточно быстро масштабироваться на больший объем.