Оглавление

1. Тарифы
   1.1 Индивидуальные тарифы и ограничения

2. Процессы

3. Система поддержки
   3.1 Социальность, отзывы, лайки
   3.2 Отчёты, FAQ
   3.3 Время реакции, поддержка 24/7, Telegram-бот
   3.4 Планирование работ
   3.5 Статистика

4. Проблемы и решения
   4.1 Проблемы с клиентами
   4.2 Внутренние проблемы

5. Модель рентабельности и KPI

6. Что почитать?

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

Единственным сотрудником в отделе тоже был я и в мои обязанности входил перевод новостей из .doc-файлов, присылаемых клиентом, в административную панель сайта. Сохранив картинки и текст в нужных полях, я фиксировал 15 минут работы в специально созданный .xls-файл, а в конце месяца, просуммировав все работы, высылал клиенту счёт.

На сегодняшний день в отделе технической поддержки Progressive Media работает 10 человек; у нас более 25 проектов на постоянном обслуживании, среди которых такие клиенты, как SsangYong, Hoff, издательство «Красивые дома»; ведущий разработчик проводит code review перед каждым коммитом; типовой договор содержит SLA; для сотрудников предусмотрен KPI; многочисленные бизнес-процессы подробно описаны и проиллюстрированы BPMN-схемами; система техподдержки собирает всевозможную статистику и интегрирована c ERP, клиенты автоматически получают прозрачные отчёты о работах, а о критических проблемах на проектах напоминает специальный Telegram-бот.

В статье я подробно расскажу о том, как всё это устроено.

Тарифы

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

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

Отсутствие ежемесячных платежей подразумевает то, что подрядчик бронирует ресурсы для выполнения задач клиента за свой счёт. Причем в соответствии с договором и SLA подрядчик обязуется обеспечивать определенное время реакции и решение проблем клиента. Каким образом? Что делает подрядчик, если в один момент вдруг все его клиенты активизировались и заваливают задачами каждый день? А такое бывает часто: саппорт – это непрогнозируемый объём работ.

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

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

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

Что интереснее: работать с постоянно развивающимися проектами или менять телефоны на сайтах клиентов раз в полгода, пусть и без абонентской платы?

Думаю, это интересный вопрос для дискуссии в комментариях.

1.1 Индивидуальные тарифы и ограничения

Наши тарифы начинаются от 16 рабочих часов в месяц, цены вместе с презентацией услуги высылаем по запросу клиентов. Стоимость часа на данный момент одинакова для всех тарифов, но по договору мы обязуемся выработать только включенные часы. Впрочем, допработы предусмотрены (по такой же ставке) и мы охотно их выполняем, но предупреждаем клиента, что дополнительные работы выполняются только при наличии свободных ресурсов. Таким образом, мотивацией сменить тариф становится гарантия выработки забронированного объёма часов.

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

С некоторыми клиентами у нас индивидуальные тарифы, например, мы поддерживаем Hoff.ru – над этим проектом работает отдельная команда из 4 человек и процессы там отличаются от всех остальных проектов.

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

Процессы

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

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

Эта информация передаётся менеджеру поддержки, которого я представляю клиенту вместе с доступами в тикетную систему.

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

• Новый клиент.

• Изменение тарифного плана.

• Работа с обращениями (основной и самый сложный процесс).

• Передача проекта между менеджерами.

• Перевод разработчика в отдел ТП.

• Снятие клиента с поддержки.

Каждый процесс проиллюстрирован подробной BPMN-схемой. Моделирование бизнес-процессов и BPMN – тема отдельной статьи, подготовкой который мы сейчас занимаемся. Следите, скоро на CMSMagazine.

Система поддержки

Постоянно совершенствующаяся система поддержки Progressive Support – наша гордость. Система плотно интегрирована с коробочным «Битрикс-24», а также имеет отдельные интерфейсы для клиентов, менеджеров и администратора.

В системе предусмотрены следующие основные сущности: «Проект», «Обращение» (тикет), «Задача». Клиент (юридическое лицо) может иметь несколько проектов, за каждым проектом закреплен наш персональный менеджер (при необходимости можно подключить несколько менеджеров). У клиента также может быть несколько аккаунтов.

При создании обращения менеджер при необходимости уточняет требования, после чего ставит задачу разработчику. Таким образом, задача привязана к обращению. Если по обращению планируются объёмные работы, менеджер может раздробить их на несколько задач.

Задача – это обычная задача в «Битрикс-24», с которой работает специалист в привычном ему интерфейсе (с системой поддержки работают только клиенты и менеджеры). За основу дизайна мы также взяли «Битрикс-24», чтобы соблюдать общность с основным рабочим инструментом в компании.

Подобная структура позволяет нам:

• использовать функционал задач «Битрикс-24», в частности, трекать время по задачам;

• реализовать и постоянно модифицировать интерфейс для клиента (не каждый клиент сможет работать, например, в Jira);

• получать любую необходимую статистику (подробнее об этом далее);

• реализовать любой новый функционал средствами PHP + API «Битрикс 24» (например, у нас уже есть интеграция с Telegram, мы также отслеживаем срок окончания регистрации домена и автоматически уведомляем об этом клиентов, а сейчас мы планируем интегрироваться с сервисом Deploy HQ).

3.1 Социальность, отзывы, лайки

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

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

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

Отдельного упоминания заслуживают публикации. Пару раз в неделю мы размещаем в системе ссылки на интересные статьи на темы юзабилити, ecommerce, повышение конверсий, аналитики и т.п. Это стимулирует дополнительные продажи, повышает компетенции клиентов (а мы заинтересованы в этом) и даёт нам «лайки» :)

3.2 Отчёты, FAQ

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

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

3.3 Время реакции, поддержка 24/7, Telegram-бот

Время реакции на обращение – один из ключевых показателей услуги поддержки. Клиенты часто интересуются «А есть ли у вас 24/7?». Причем, в процессе переговоров выясняется, что ставить новые задачи и обсуждать их в нерабочее время, в общем-то, никто не собирается. Поэтому в формате 24/7 интересует в основном серверная поддержка, а это отдельная тема.

Но если возникает авария (это тип обращения в соответствии с нашим SLA, критичность которого является наивысшей), то наше время реакции составляет 15 минут. Для того, чтобы увеличить скорость реакции на аварии мы решили уведомлять менеджера через телефон – наиболее эффективный способ. Хотя большую часть времени менеджер находится онлайн, но бывают и перерывы, например, я иногда устраиваю собрания и планерки, которые могут длиться около часа.

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

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

3.4 Планирование работ

Как упоминалось выше, саппорт – это всегда непрогнозируемая нагрузка. Клиент не будет готовить список задач в начале месяца, он будет ставить их тогда, когда ему удобно, и мы должны адаптироваться под эти требования. На практике это означает, что всегда будут «завалы» (все клиенты вдруг активизировались и завалили нас задачами) и простои (клиенты заняты своими делами и не ставят задачи).

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

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

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

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

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

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

3.5 Статистика

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

Помимо этого, с помощью системы я отслеживаю следующие показатели:

• Эффективность менеджера

Количество проектов, которые ведёт менеджер; время реакции; количество положительных и отрицательных отзывов, «лайков» и «дислайков».

Отдельно рассчитывается норма выработки часов. До поддержки, ещё на этапе разработки проекта, мы, как и многие компании на рынке, закладываем в стоимость работ проектный менеджмент в размере 20%. На поддержке мы решили снизить этот показатель до 15%.

• Общая выработка часов, эффективные и неэффективные часы

• Отзывы и лайки

Проблемы и решения

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

4.1 Проблемы с клиентами

Среди среднего или малого бизнеса основных проблемы две: обоснование оценки («почему так долго? Тут ведь 10 минут делать») и отчёты («Почему это заняло 10 минут? Почему я должен платить за это?»).

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

Задачи от его менеджера приходили примерно вот так.

Как менеджеры, так и разработчики настолько устали от этого, что от клиента мы попросту отказались. Как показала нам модель рентабельности (подробнее об этом далее) – отказались не зря, так как почти ничего не потеряли, а менеджеры и разработчики с воодушевлением приступили к работе над новыми проектами.

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

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

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

После этого разработчики готовят свои комментарии и мы предлагаем клиенту провести рефакторинг (уже платно), делая акцент на то, что если рефакторинг не сделать, то каждая задача будет выполняться дольше (программистам нужно разбираться с чужим кодом) и менее качественно (может вызвать регрессии кода). Естественно, это объясняется клиенту на понятном ему языке.

4.2 Внутренние проблемы

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

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

Не так всё просто и с менеджерами: для поддержки сложного (как в техническом, так и с точки зрения менеджмента) проекта нужен менеджер с компетенциями, почти такими же, как и руководитель проекта (в производстве). Да, у нас в системе предусмотрена опция «Скопировать текст обращения в задачу», но это работает крайне редко: таких обращений мало, а много тех, где менеджеру необходимо погрузиться в задачу довольно глубоко и предложить решение (или несколько) клиенту.

Модель рентабельности и KPI

Рентабельность направления посчитать не так сложно. Доход делится на две части:

• Постоянные ежемесячные платежи клиентов (абонентская плата);

• Платежи на дополнительные работы (доп. продажи менеджеров – отличаются от месяца к месяцу).

Расход – сумма зарплат всех сотрудников. Конечно, здесь следует учесть налоги, рабочее место, отпуска, больничные и т.п. Очень хорошие формулы расчёта приводит в своем вебинаре Борис Сидоров, рекомендую ознакомиться.

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

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

Что почитать?

Не так много студий рассказывают о том, как у них построен процесс поддержки. Точнее, я нашел всего два интересных и подробных материала на эту тему: статья Владимира Завертайлова из «Сибирикс» и уже упомянутый выше вебинар Максима Лагутина и Бориса Сидорова.

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