Кейс: как мы внедряли аналитику общения с клиентом в Whatsapp для онлайн-школы

Связали сделки в Битриксе с переписками с клиентами в Wazzup и разложили все на удобные дашборды в Power BI, чтобы искать корреляции продаж с общением. Кейс будет полезен онлайн-школам, курсам и сервисам, где продажи идут через мессенджеры. Внутри — скрины, инструменты и этапы.

Привет! Меня зовут Роман Абрамов, я руководитель «cntrl+». Мы занимаемся внедрением бизнес-аналитики на основе данных о финансах, продажах, рабочем времени и производстве.

Прошлой осенью мы начали работать с одной крупной онлайн-школой. Ребята в компании повернуты на аналитике данных — у них уже был опыт работы с Power BI и аналитиками.

Началось сотрудничество с довольно обыденных вещей в Битриксе: выручка, конверсии, циклы — в общем все, что связано со сделками. Об этом мы писали в предыдущем кейсе. Но самое интересное началось после того, как мы реализовали основной блок.

Следите за руками: есть номер в Whatsapp, на который пишут потенциальные клиенты онлайн-школы и с которого отвечают менеджеры компании. Но при этом менеджеры отвечают не в Whatsapp, а в Битриксе, который интегрирован с Wazzup, который сводит все сообщения в одно место. Еще разок: отдел продаж общается с клиентом через Битрикс, и там же находится вся переписка с клиентом и вообще все данные.

Раз сделку технически можно смотреть вместе c перепиской, можно отследить влияние общения на продажи. Определить это влияние мы как раз и хотели.

Раньше в компании никто не понимал, сколько сообщений приходит менеджерам, сколько ответов они пишут, как отвечают в принципе и отвечают ли. На рынке просто нет решений, которые позволяют это увидеть. Все, что связано со сделками — пожалуйста, но отдельной аналитики по перепискам в Wazzup нет. Поэтому по факту мы создавали с нуля аналитику коммуникаций в мессенджере.

Поставили цель — внедрить решение, которое позволит оценивать работу менеджеров относительно переписки с продажами. Что оно должно было уметь:

Считать скорость обмена сообщениями. Мы хотели знать, как быстро менеджеры отвечали клиенту. И насколько быстро сам клиент отвечает менеджеру. Если клиент отвечает в четыре утра, мы считали скорость ответа с начала рабочего дня (9:30), а не фактического вопроса клиента, чтобы не увеличивать скорость на пустом месте.

Отображать количество входящих и исходящих сообщений на графике. Зачем? Чтобы понимать насколько быстро менеджеры справляются и с входящими сообщениями.

Кроме того, в процессе мы придумали небольшую хитрость: менеджеры должны работать плавно, без пиков по нагрузке. Условно, каждый час менеджер должен был обрабатывать 150 сообщений. Обработал 100 — плохо, обработал 300 — тоже плохо. Чтобы не было ситуаций, когда менеджер начинает свой день с кофе, потом раскидывает накопившееся и так по кругу. На графике это может быть похоже на пилу — видны все отклонения от плана.

Считать «разговариваемость». Если менеджеры пишут пять сообщений, а клиент в ответ — одно, похоже, это не очень хорошо. Поэтому у менеджеров появилась задача — разговорить клиента и приблизить отношение исходящих и входящих сообщений к 1:2. На графике руководитель, соответственно, видел график отклонений от этих показателей.

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

Чтобы все это реализовать, мы подключились к API Битрикса и Wazzup, и выгружали из последнего данные в БД. На сервере шли промежуточные расчеты, которые поступали Power BI, где мы очищали данные и собирали отчет. Данные в Power BI обновляются каждые три часа.

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

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

Параллельно мы долго обсуждали с заказчиком вид выгрузки — как все это должно было выглядеть. Из Power BI создали дашборд в вебе, доступ к которому имеют руководители компании и РОПы.

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

Но главный выхлоп в другом. Теперь руководство компании видит, как работают его сотрудники и может влиять на показатели; все процессы просто стали более осознанными.

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

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

Как все сделаем — расскажу здесь и в своем телеграм-канале, где делюсь советами по оцифровке бизнеса.