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

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

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

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

В одной компании были просто менеджеры, которые на самом деле совмещали множество ролей: service manager, sales manager, product manager, bizdev, partnership manager, pre-sale manager, account manager. В этой ситуации работа сосредотачивалась на реактивных вопросах, а не на проактивных. А значит об увеличении продаж не могло быть и речи. Понятно, что в данной ситуации рекомендуется разграничить функции внутри команды, пересмотреть структуру и только потом доносить новые цели по выручке.

Пример: в одной компании просьба оценить удовлетворенность приходила автоматически по почте при закрытии каждой заявки, причем не бизнес-заказчику, а его инженеру. По сути, происходила оценка не услуги, а работы инженеров и/или работы администратора технической поддержки, который произвел звонок с просьбой поставить оценку. Формула расчета тоже была странной. При ближайшем рассмотрении стало ясно, что данные, которые собирали таким способом, больше отвечали требованиям Satisfaction Rate по конкретной заявке. Satisfaction Rate тоже полезный инструмент для менеджера по Customer Success, но он не отменяет NPS.