Польза ABCDX-сегментации клиентов для всех отделов компании

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

ABCDX-сегментация клиентов:

• A сегмент — продукт очень нужен, поэтому покупают быстро/покупают часто/платят много.
• B сегмент — продукт нужен, но есть возражения. Платят много, средний цикл продажи.
• C сегмент — есть потребность в продукте, но ценность невысокая, поэтому готовы платить мало и имеют ряд существенных возражений.
• D сегмент — задают много вопросов/выносят мозг, а потом всё равно не покупают.
• X сегмент — самый “жирный” клиент, готовы много и долго платить, но им нужен особенный продукт, которого у нас пока нет.

Как с ними правильно работать:

1. Сфокусировать самых сильных сотрудников на работе с A-B сегментом
2. Разрешить сильным сотрудникам не заниматься C-D сегментом.
3. Автоматизировать продукт для C-D сегмента.
4. Поставить KPI маркетингу по привлечению не всех подряд клиентов, а с приоритетом на A-B сегмент.
5. Программисты и product-менеджеры должны работать на X-сегмент а не на C и D сегменты.

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

• Самый сильный инженер поддержки, как правило, ещё и очень ответственный, поэтому он может долго и терпеливо переписываться с клиентом-истеричкой из сегмента D
  (я люблю клиентов, но встречаются и такие, да 🙈).
  Периодически к этой беседе вынужден подключаться head of support, в результате уже два самых высокооплачиваемых и/или сильных сотрудника успокаивают одного-единственного клиента, хотя эти ресурсы вполне можно вложить в другие активности.
  Да, мы очень клиентоориентированные и хотим помочь всем и всегда, но бывают случаи, когда надо вернуть деньги или аккуратно подвести черту в беседе, после чего уделить время более приоритетным клиентам.
• Отличная, много раз себя окупившая, проактивная практика — периодически писать письма клиентам из сегмента А, спрашивать как дела и просить не стесняться обращаться, если есть вопросы. Обычно клиенты в восторге, что им лично пишет руководитель тех.поддержки и спрашивает, чем мы им можем помочь. Часто в ответ действительно приходят вопросы, которые можно разбирать в спокойном порядке. Например, один раз нам пожаловались на пару некритичных (с точки зрения клиента) моментов в поведении одного из устройств, а по нашему опыту это рано или поздно привело бы к поломке. Поэтому мы сделали диагностику, выслали “подменное” устройство и спокойно починили клиентское. Клиент был в полном восторге. И да, получилось в миллион раз лучше, чем если бы мы просто реактивно подождали полгода, пока всё сломается, и дальше реагировали уже на жалобу.
• Пользователи с триальной версией ПО хорошо конвертируются в покупающих продукт клиентов, но надо знать меру в поддержке.
  Например, мы как-то выпустили софт для пользователей-непрофессионалов с сенсорами (меньше 200$ за устройство), они завалили техподдержку вопросами по настройке такого сенсора в триальной версии софта. В результате оставалось нищенски мало времени на помощь текущим клиентам, купившим устройства за 20 000$. Со временем, конечно, приоритезировали этот поток запросов, но осадочек остался.
• У компании может быть десятки тысяч клиентов по всему миру, но когда выходит новый масштабный релиз и на какую-нибудь новую фичу приходит 10 жалоб в техподдержку, у команды саппорта может создаться стойкое ощущение, что жалобы идут отовсюду и фича зло. Даже если таких жалоб всего 10 на 50 000 новых установок софта, саппорт всё равно будет мыслить в категориях несчастных “жалобщиков”, так уж мы устроены 😄
  В лучшем случае, этот настрой испортит настроение команде саппорта, в худшем — ещё и программистов расстроит, пока команды будут вместе наливать утром кофе на кухне.
  В таких ситуациях надо включать голову, разбирать внутри команды, от клиентов каких категорий идут жалобы и баги ли это вообще. Иначе в обеих командах будет упадёт мораль, и программисты начнут работать на запросы клиентов из категории C и D. Понятно, что случаи бывают разные и иногда это действительно страшные баги, но бывает, что клиенты просто “недоразбираются” с новым функционалом и автоматически приписывают ему ошибки, которых в реальности нет.

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

А ещё заходите в навигатор по блогу, там ещё много интересных материалов и полезных заданий. До встречи в новых статьях!

Ссылка на видео: