«Убедитесь, что каждый сотрудник вашей компании точно знает, какую ценность ищут ваши клиенты и как ваша компания и сотрудник, в частности, могут на это повлиять».
В этой главе опишу особенности ролей на примере строительного магазина. Расскажу о 5 классических ролях в компании и объясню, чем чревата путаница в них, а главное, как этого избежать. В конце покажу кейс об инженере-проектировщике крупной компании.
Существует 5 ролей (отделов) в компании, которые отвечают за взаимодействие и работу с клиентом и продуктом: Account manager, Project Manager, Product Manager, Support Manager и Customer Success Manager. Что касается CS, то чаще всего, особенно в небольших компаниях, его роль выполняют project (Pj) или account (A).
Если в начале становления компании такой подход уместен с целью экономии ресурсов, то по мере роста компании совмещение ролей или неправильное понимание роли CS приводит к негативным последствиям: низкой продуктивности, снижению лояльности клиентов и т. д.
Чтобы вы лучше поняли, как работают роли, предложу простую аналогию. Представим в качестве компании строительный магазин. Теперь попробуем соотнести 5 ролей по позициям в нашем выдуманном магазине.
A (Account) – продавец-консультант. В магазине он помогает клиентам подобрать строительное оборудование и инструменты. Продавец-консультант предлагает товары на основе текущих запросов клиентов, а также рассказывает об акциях и спецпредложениях. Таким образом, он стимулирует их к покупке.
CS (Customer Success) – персональный продавец-консультант. Он помогает клиентам решать более сложные задачи, такие как выбор оборудования для конкретного строительного проекта. Он предоставляет информацию о продуктах, советует оптимальные решения и помогает в составлении комплексного списка необходимого оборудования и материалов.
Он отвечает за организацию обучающих семинаров для клиентов и внедрение новых сервисных услуг. Эта роль включает тесное взаимодействие с клиентами для понимания их потребностей и обеспечения успешного использования приобретённой техники в их проектах.
S (Support) – сотрудник информационного стенда. Он отвечает за помощь в решении проблем после покупки. Если клиент обнаруживает недостатки в приобретённом оборудовании или инструментах, сотрудник информационного стенда помогает в обмене товара или возврате денег.
Pr (Product) – заведующий отделом товаров. Он управляет ассортиментом строительной техники и инструментов в магазине. Отвечает за закупку, наличие и качество товаров, а также за их соответствие потребностям клиентов.
Pj (Project) – специалист по управлению проектами (замдиректора магазина). Он сфокусирован на помощи в ведении проектов клиентов от начала и до конца. Основная задача – это реактивное решение задач, возникающих в процессе реализации проекта клиентом, без углубления в долгосрочные потребности или стратегическое планирование успешности проекта.
Pj обеспечивает выполнение всех этапов проекта клиента, доступность ресурсов для покупателя и решение любых проблем в случае их возникновения. Это включает координацию между различными отделами магазина для обеспечения своевременной поставки товаров, поддержку в технических вопросах и быстрое реагирование на запросы клиента в процессе реализации проекта.
Ещё раз подчеркну, что Pj работает на решение оперативных задач (реактивный подход), а CS работает над стратегическими вопросами клиента (проактивный подход).
Думаю, теперь вам стало яснее, как эти роли отличаются друг от друга.
Таблица. Особенности взаимодействия различных типов менеджеров с клиентами
На это влияют 3 основные причины:
1. Сходство в задачах – несмотря на уникальность каждой роли, все они направлены на одну главную цель: обеспечение наилучшего опыта для клиента. По этой причине бывает, что одна стратегическая цель приводит к дублированию тактических задач.
2. Динамичный характер бизнеса – как правило, это касается новых и быстрорастущих компаний, где роли могут изменяться, а также тех случаев, когда бизнесу приходится адаптироваться под внезапные условия рынка, например пандемию.
3. Недостаток чёткой коммуникации – в отсутствие ясно определённых ролей и ответственностей сотрудники могут начать выполнять задачи, которые традиционно не входят в их компетенцию.
Для наглядности приведу кейс, а вы попытайтесь ответить, какой причиной вызвана ситуация.
Крупное архитектурное бюро через давнего подрядчика закупило новое ПО. После чего столкнулось с проблемой: главный инженер-проектировщик не может эффективно использовать новые инструменты 3D-моделирования для разработки строительных проектов.
В этом случае задача CS заключалась в проведении индивидуального обучения и консультирования, чтобы обеспечить плавный переход на обновлённую версию ПО и демонстрацию преимуществ новых функций для рабочего процесса бюро.
Но вместо этого инженеру-проектировщику пришлось пройти несколько «кругов ада», где его встречали то Account, то Support.
Account, с которым обычно взаимодействовал инженер-проектировщик и к которому он обратился в первую очередь, стремился быстро решить вопрос клиента, но был не полностью осведомлён о технических нюансах обновления. По этой причине он предоставил лишь общие рекомендации и направил клиента к обучающим материалам на сайте.
Инженер-проектировщик также отправлял запрос в техподдержку, но Support не смог предложить решение, потому что его задача – решение технических проблем, а не обучение пользователей.
В результате клиент чувствовал себя «брошенным», что привело к снижению продуктивности и удовлетворённости от продукта. В конечном счёте успех был достигнут, но только после того как CS узнал об этой проблеме. Правда, если бы A или S вовремя сообщили ему о проблеме клиента, то добиться решения можно было бы быстрее, позитивнее и с меньшими временными издержками.
Для решения ситуации CS провёл встречу с инженером-проектировщиком, чтобы убедиться, что тот освоил новые инструменты. Также CS направил полный пакет обучающих материалов и дополнительно организовал встречу с экспертом для проведения обучения.
Что стало причиной неприятной ситуации? Этому послужило классическое дублирование задач и невыстроенная должным образом коммуникация между сотрудниками.
Для этого нужно:
1. Определить роли и распределить ответственность – создать подробное описание для каждой должности, где чётко указаны задачи и сферы ответственности. Это поможет избежать пересечения функций и недопонимания.
2. Сделать регламент взаимодействия между отделами – прописать процедуру координации действий между отделами, например, как CS должен передать возможность доппродажи Account, в каких случаях и кто должен инициировать такие действия.
3. Формализовать процессы – например, разработать специальный протокол или алгоритм действий при идентификации возможности доппродажи. Он должен включать шаги по передаче информации, согласования с клиентом и заключению договора.
4. Проводить регулярные встречи и отчёты – проведение регулярных собраний и составление отчётов о проделанной работе позволяет отслеживать выполнение функций и корректировать действия в случае отклонения от установленных процедур.
Отмечу, что даже внедрение одного из перечисленных пунктов значительно улучшит эффективность работы.
CS должен взаимодействовать со всеми менеджерами. Иначе он не сможет помочь клиенту достичь целей. В кейсе про инженера-проектировщика я уже объяснял, что CS был обязан коммуницировать с Account и Support. В противном случае все вовлечённые в данный процесс стороны теряют время на каком-то из этапов.
Таблица. Точки взаимодействия CS и других менеджеров