Одно простое решение, которое в нужный момент сделает вас значительно лучше конкурентов, — это создание выделенной функции технической поддержки. «Выделенной» — это значит, что отдельный человек (или люди) сидит и занимается только вопросами технической поддержки клиентов. Для многих руководителей студий не сразу становится очевидно, почему проекты, которые продавал и вел один человек, нужно передавать другому специалисту, который не в курсе деталей разработки, которому пока еще не доверяет клиент. Но...
Знаете, почему хорошие клиенты часто уходят? В первую очередь их не устраивает уровень технической поддержки. Новый сайт — это гипотеза того, что нужно бизнесу. А задачи в рамках техподдержки — это уже реальные потребности. Это тот самый момент, когда вы реально нужны клиенту. А скорость ответов вашего менеджера, уровень подготовки ответов и погружения в поставленные задачи — это залог доверия клиента. Конечно, можно больше заработать на разработке нового сайта, чем на дополнительных «хотелках» клиента. Именно поэтому менеджеры часто динамят запросы на поддержку, совершая ошибку, которую нельзя совершать.
Как только менеджер начинает выбирать, чем ему заниматься — обслуживать новых клиентов или отвечать на запросы от «старичков», — приходится создавать службу поддержки и внедрять Help Desk . Делать его источником прибыли и лояльных клиентов. Обсудим?
Здравый смысл. У службы поддержки есть две основные функции: 1) понять, что реально нужно клиенту, и 2) быстро найти решение. Звучит просто? Но как же непросто добиться, чтобы это работало! Проблема в том, что менеджер часто смотрит на запросы клиента как на что-то второстепенное. Хочет клиент — сделаем, лишь бы отстал... Но поймите: запросы в поддержку — отражение реальной жизни бизнеса. Это очень важно для клиента. Если научиться задавать вопросы и смотреть на запросы клиента под другим углом, то все сразу меняется.
Вот что я требую от менеджеров при поступлении запроса от клиента: 1) понять, в чем реально состоит проблема (задача), и коротко ее сформулировать в письменном виде; 2) понять, почему это важно для клиента, и выписать вторым абзацем; 3) в третьем абзаце описать, как можно решить эту задачу просто и без денег; 4) в четвертом абзаце описать, как можно красиво решить задачу за деньги и сколько это предварительно стоит; 5) написать письмо клиенту (даже если он звонил), в котором повторить его задачу, расписав ее комплексно, и предложить варианты решения.
Не устраивайте с клиентом пинг-понг в переписке. На том проводе сидят люди, которые больше всего ценят время и людей, которые ценят их время. Толковый менеджер напишет такое письмо клиенту, которого ему будет достаточно, чтобы принять решение. И если клиент смог ответить на ваше письмо просто указанием номера варианта, который вы ему предложили, — значит, вы все правильно сделали.
Ежедневно в службу поддержки WebCanape приходит
Мониторинг поддержки. Но вы будете правы, возразив, что людей с описанным подходом к заказчикам очень мало. Именно поэтому доверяй, но проверяй. Мы же хотим, чтобы все работало само, само себя контролировало и мотивировало. Для этого давайте выберем метрики, по которым будем контролировать работу службы поддержки, делая из обычных менеджеров клиенториентированных профессионалов.
Скорость ответа на запрос. Автоответ на письмо клиента должен уходить мгновенно от имени руководителя службы поддержки в максимально человечном виде. Типа: «Спасибо за запрос. В течение 20 минут я назначу менеджера, он свяжется с вами, как только изучит вопрос. Руководитель службы поддержки Сергей Алфимцев». Персональное письмо менеджер должен отправить клиенту в течение одного — трех часов. Метрика считается и включается в сводный отчет.
Количество писем в переписке с клиентом. Количество писем в переписке по одному вопросу не должно быть больше четырех. Это очень важная метрика. Если писем больше, то это повод для руководителя разобраться, в чем дело. И тут очень тонкий момент. Менеджеры любят писать, но не любят звонить. Так вот — звонить можно и нужно, просто потом все необходимо сформулировать письмом и отправить клиенту. Нужно что-то уточнить? Подними телефон и позвони клиенту, не пиши письма! Нужно подробно рассказать клиенту, что и как, — не звони (он не запомнит), а сформулируй в письме и отправляй. Такой подход существенно поднимает эффективность.
Скорость закрытия заявки. Независимо от типа заявки (платная, бесплатная), срок ее закрытия должен быть меньше либо равен сроку, который назвали клиенту. Эта метрика контролируется также автоматически, дополняя еженедельный отчет.
Рентабельность по заявке. Если мы делаем платную задачу, рентабельность должна быть не ниже плановой. Контролируем превышение времени разработчиков и фиксируем, если это произошло. Это повод разобраться, что было не так: постановка задачи, неправильная оценка, работа менеджера...
Отзыв клиента по решенной заявке. По факту смены статуса заявки на «Решено» клиенту автоматом должен уходить запрос на отзыв. Это стандартная функция заявочной системы. Но если есть возможность, то лучше всего наблюдать показатель NPS , который расскажет вам значительно больше, чем просто оценка менеджера.
Я описал основные показатели. Регламент работы службы поддержки должен быть обязательно зафиксирован в корпоративной wiki и строго контролироваться.
Пример регламента работы службы поддержки клиентов доступен в онлайн-курсе «Диджитал-агентство на конвейере».
Модель монетизации поддержки. Этот вопрос нельзя обойти стороной, так как он является предметом обсуждений любой веб-тусовки. Какие варианты могут быть? 1. Оплата по запросам. Пришел запрос, сделали оценку, получили оплату, сделали задачу. 2. Оплата по часам. Пришел запрос, примерно оценили, сделали задачу, посмотрели затраченное время, выставили счет клиенту, получили оплату. Либо выставили счет за все часы по всем задачам в этом месяце и получили оплату. 3. Оплата тарифного плана. Клиент подписывается на тарифный план, который включает определенное количество часов. Платит ежемесячно. В рамках этих часов идет работа. Если часы не израсходовал, то они сгорают.
Мы попробовали все три модели, и вот мои рекомендации. Если у вас много недорогих проектов (как в WebCanape), то легко приживается вариант № 1. По варианту № 2 чаще всего работаем, если клиент у нас на продвижении либо объем работ небольшой, до 30 часов в месяц ориентировочно. Вариант № 3 тоже хорошо подходит для WebCanape, но продавать его для небольших проектов сложно. По нему работаем сейчас только в рамках объемных проектов. Однако знаете, что я вам скажу? Можно сколько угодно играть с тарифами, но, если не прекратить пинг-понг с клиентом, служба поддержки всегда будет убыточна. Решайте в первую очередь вопрос с пинг-понгом.
Поддержкой сайтов, теоретически, могут заниматься и менеджеры по разработке сайтов. Но каждый запрос от клиентов по технической поддержке будет отвлекать менеджера от его основной работы — ведения проектов. Подумайте только, если таких запросов будут сотни, то менеджер по разработке сайтов не успеет завершить ни один проект. Здесь важно понимать, что масштабы и емкость проектов у менеджеров разработки и технической поддержки совершенно разные. В первом случае это могут быть десятки крупных проектов, а во втором — уже сотни обращений совершенно произвольного характера.
Сергей Алфимцев, руководитель службы поддержки клиентов
Приобрести книгу «Бизнес на конвейере, или Как построить прибыльное агентство в кризис» на сайте Ridero.
@webbizz — группа, в которой можно задать вопросы автору книги.
Проведите конкурс среди участников CMS Magazine
Узнайте цены и сроки уже завтра. Это бесплатно и займет ≈5 минут.