Мы сильно обрадовались новому контракту и уже представляли, как логотип клиента приукрасит наше портфолио. Но все оказалось не так радужно. Расскажем, как мы работали с дочкой крупной российской IT-компании, и почему у нас не получилось сделать крутой проект.
Продукт клиента — SaaS в сфере B2B, который работает по формату абонентской платы. Пользователь регистрируется, проходит авторизацию, пополняет свой счет и использует сервис.
Наша задача — помочь клиенту «собрать» аналитику. Для этого нужно было выстроить процессы колл-центра, внедрить CRM и «свести» сквозную аналитику по ключевым показателям.
Перед тем, как заниматься аналитикой, нужно подготовить ландшафт для ее сбора: структурировать процессы продаж и настроить интеграции с сервисами. В процессах мы обнаружили несколько проблем:
Далее сделали карту со структурой взаимодействия всех систем.
В ней показано, по какой логике должны идти события, и на каких этапах собирается аналитика. Основные данные берем из CRM и соотносим их с данными по рекламе и конверсиям. Собираем в myBI, визуализируем в Power BI.
Продажи у клиента велись в Enybox CRM, их мы перенесли в amoCRM для удобства интеграции. Логику продаж получилось собрать в три воронки.
Три последовательные воронки
Первая воронка — консультации. Нужна была, чтобы довести клиента до регистрации на платформе. Вторая воронка — фиксация первых оплат. Далее пользователь подтверждал свою регистрацию. А мы, в свою очередь, отмечали момент оплаты и каждое новое пополнение.
Для нормальной работы системы аналитики нужно собирать все события = отмечать конверсионные действия. События уже попадали в систему аналитики, но изначально их было только два типа, что недостаточно для отчетов.
Пример дашборда
После того, как собирались данные по конверсиям, нужно было сделать из них отчет. Основной инструмент визуализации данных — Microsoft Power BI.
В момент конверсии на сайте генерировался отдельный ID для синхронизации рекламных систем и CRM. По этому ID мы связывали данные расходов и доходов. Так мы соотносили данные и могли строить по ним отчеты.
График rolling-retention'а сервиса с 1 по 12 месяц
Retention показывает, насколько пользователи вовлечены в приложение, и как часто они в него возвращаются. Но из-за того, что сервис работает в формате пополнений, пришлось поменять этот показатель на rolling-retention. Он показывает то же самое что и ретеншн, но подразумевает что все время, которое пользователь не пополнял кабинет, он тоже использовал сервис.
Конверсия сильно зависела от количества новых клиентов и начала их оплат. Первые 9 месяцев мы получали примерно по 430 новых регистраций и по 90 оплат от новых пользователей ежемесячно. Конверсия в покупку в месяц регистрации составила 20%, по данным за 12 месяцев.
Была возможность видеть аналитику по касаниям клиента как в моменте простого перехода на сайт, так и в момент регистрации и дальнейших оплат. Накапливали данные, чтобы найти самые конверсионные цепочки:
Пользователь увидел рекламу → пошел на сайт → спустя время зашел и поискал в контексте → зарегистрировался, но не оплатил → погрели письмом → предложили тест драйв → потестил → ОП «дожал» на первую оплату → 3 года стабильных оплат.
В самом начале инициаторы проекта отложили старт до осени (обратились весной). Такие «пробелы» в работе происходили не раз. Но мы не задумывались об этом и принимали как должное. Главными проблемами были коммуникация и бюрократия в процессах нашего клиента. Так можно изобразить весь временной отрезок работы над проектом:
Причиной пробелов в разработке была структура работы клиента. Мы работали совместно с командой клиента и часть задач можно было выполнить только на его стороне по причине высокой секьюрности процессов.
Все менеджеры и разработчики на их стороне работали по двухнедельным итерациям. Но они постоянно ставили наш проект последним по приоритету и часто наши задачи не попадали в «спринт».
За время проекта менеджер со стороны клиента (стейкхолдер) поменялся пять раз. Наверное все знают то чувство, когда проект, над которым ты работаешь вдруг становится не интересен клиенту. Но даже это можно решить.
Сложнее было разбираться с некомпетентностью стейкхолдеров. Один из них был отличным руководителем, который хорошо разбирался в своем продукте. Но он не понимал даже базовых принципов построения процессов продаж. Мы потратили несколько встреч, чтобы переубедить его убрать из воронки продаж этап со статусом «Как дела?».
Представьте себе воронку продажи, как на рисунке выше. В одном из этапов менеджерам нужно узнать «как дела у клиента». Как думаете, что произойдет с аналитикой конверсий такой воронки?
Менеджеры будут узнавать «как дела» у клиента вместо продвижения его по воронке, статус не тривиален. Не очевидно когда его ставить: после первого контакта или после квалификации. В итоге сделки «прыгают» туда-сюда по воронке или просто стоят, вместо последовательного движения.
Мы не учли пропускную способность системы. На одно событие платформы в пике мы передавали до 10 запросов к amoCRM, чтобы выполнить логику бизнес-процессов.
100 000 ивентов в сутки * 10 запросов к amoCRM = 1 000 000 запросов в сутки
1 000 000 запросов в сутки / 10 запросов в секунду (ограничение амо) = 100 000 секунд = ±27 часов
Итог: синхронизация никогда не закончится
Изначально выбрали amoCRM, так как «проходи» по лимиту запросов к системе. Но с течением развития проекта требования и функции увеличились и мы «уперлись» в лимит.
Этот кейс — еще один пример проекта, который закопали в согласованиях и куче неоправданного менеджмента.
Нам не хватило экспертности в техническом плане. Клиенту — устойчивости в управлении и желания довести проект до конца.
Но это опыт. Благодаря ему теперь подобные задачи выглядят максимально тривиально и мы уже воспроизвели подобное решение в рамках другого проекта.
Чтобы не повторять таких кейсов в будущем, мы выделили аспекты, которые нужно соблюдать в работе с enterprise клиентами.
Автор статьи — Фёдор Анисимов, маркетолог LAND PRO.
О проекте
Продукт клиента — SaaS в сфере B2B, который работает по формату абонентской платы. Пользователь регистрируется, проходит авторизацию, пополняет свой счет и использует сервис.
Наша задача — помочь клиенту «собрать» аналитику. Для этого нужно было выстроить процессы колл-центра, внедрить CRM и «свести» сквозную аналитику по ключевым показателям.
Структура процессов
Перед тем, как заниматься аналитикой, нужно подготовить ландшафт для ее сбора: структурировать процессы продаж и настроить интеграции с сервисами. В процессах мы обнаружили несколько проблем:
- Менеджеры отвлекались на ненужные этапы воронки продаж, и их работа никак не контролировалась;
- Отчеты по продажам ежедневно выгружались из админки вручную;
- Было мало конверсионных событий для сбора аналитики.
Далее сделали карту со структурой взаимодействия всех систем.
В ней показано, по какой логике должны идти события, и на каких этапах собирается аналитика. Основные данные берем из CRM и соотносим их с данными по рекламе и конверсиям. Собираем в myBI, визуализируем в Power BI.Воронки продаж
Продажи у клиента велись в Enybox CRM, их мы перенесли в amoCRM для удобства интеграции. Логику продаж получилось собрать в три воронки.
Три последовательные воронки
Первая воронка — консультации. Нужна была, чтобы довести клиента до регистрации на платформе. Вторая воронка — фиксация первых оплат. Далее пользователь подтверждал свою регистрацию. А мы, в свою очередь, отмечали момент оплаты и каждое новое пополнение.
Как должна была работать аналитика
| Изначальные «события» | Итоговые «события» |
|---|---|
| Форма обратной связи | Форма обратной связи |
| Регистрация в сервисе | Регистрация в сервисе |
| Первое пополнение | |
| Тестирование (опционально при небольшом пополнении) | |
| Повторные пополнения | |
| Отказ от использования (прогрев через ОП) |
Для нормальной работы системы аналитики нужно собирать все события = отмечать конверсионные действия. События уже попадали в систему аналитики, но изначально их было только два типа, что недостаточно для отчетов.
Отображение данных
Пример дашбордаПосле того, как собирались данные по конверсиям, нужно было сделать из них отчет. Основной инструмент визуализации данных — Microsoft Power BI.
В момент конверсии на сайте генерировался отдельный ID для синхронизации рекламных систем и CRM. По этому ID мы связывали данные расходов и доходов. Так мы соотносили данные и могли строить по ним отчеты.
Юнит экономика. Retention
График rolling-retention'а сервиса с 1 по 12 месяц
Retention показывает, насколько пользователи вовлечены в приложение, и как часто они в него возвращаются. Но из-за того, что сервис работает в формате пополнений, пришлось поменять этот показатель на rolling-retention. Он показывает то же самое что и ретеншн, но подразумевает что все время, которое пользователь не пополнял кабинет, он тоже использовал сервис.
Конверсия в первое пополнение
Конверсия сильно зависела от количества новых клиентов и начала их оплат. Первые 9 месяцев мы получали примерно по 430 новых регистраций и по 90 оплат от новых пользователей ежемесячно. Конверсия в покупку в месяц регистрации составила 20%, по данным за 12 месяцев.
Помимо стандартных показателей
Была возможность видеть аналитику по касаниям клиента как в моменте простого перехода на сайт, так и в момент регистрации и дальнейших оплат. Накапливали данные, чтобы найти самые конверсионные цепочки:
Пользователь увидел рекламу → пошел на сайт → спустя время зашел и поискал в контексте → зарегистрировался, но не оплатил → погрели письмом → предложили тест драйв → потестил → ОП «дожал» на первую оплату → 3 года стабильных оплат.
Что пошло не так
В самом начале инициаторы проекта отложили старт до осени (обратились весной). Такие «пробелы» в работе происходили не раз. Но мы не задумывались об этом и принимали как должное. Главными проблемами были коммуникация и бюрократия в процессах нашего клиента. Так можно изобразить весь временной отрезок работы над проектом:
Медленная разработка
Причиной пробелов в разработке была структура работы клиента. Мы работали совместно с командой клиента и часть задач можно было выполнить только на его стороне по причине высокой секьюрности процессов.
Два спринта пропустили — месяц потеряли
Все менеджеры и разработчики на их стороне работали по двухнедельным итерациям. Но они постоянно ставили наш проект последним по приоритету и часто наши задачи не попадали в «спринт».
Плохая коммуникация и отсутствие экспертизы
За время проекта менеджер со стороны клиента (стейкхолдер) поменялся пять раз. Наверное все знают то чувство, когда проект, над которым ты работаешь вдруг становится не интересен клиенту. Но даже это можно решить.
Сложнее было разбираться с некомпетентностью стейкхолдеров. Один из них был отличным руководителем, который хорошо разбирался в своем продукте. Но он не понимал даже базовых принципов построения процессов продаж. Мы потратили несколько встреч, чтобы переубедить его убрать из воронки продаж этап со статусом «Как дела?».
Представьте себе воронку продажи, как на рисунке выше. В одном из этапов менеджерам нужно узнать «как дела у клиента». Как думаете, что произойдет с аналитикой конверсий такой воронки?
Менеджеры будут узнавать «как дела» у клиента вместо продвижения его по воронке, статус не тривиален. Не очевидно когда его ставить: после первого контакта или после квалификации. В итоге сделки «прыгают» туда-сюда по воронке или просто стоят, вместо последовательного движения.
В процессе продажи невозможно ставить промежуточные этапы, в которых будут накапливаться сделки. Иначе вся аналитика превратится в «кашу», а менеджеры потеряют кучу контактов.
Факапы с нашей стороны
Мы не учли пропускную способность системы. На одно событие платформы в пике мы передавали до 10 запросов к amoCRM, чтобы выполнить логику бизнес-процессов.
100 000 ивентов в сутки * 10 запросов к amoCRM = 1 000 000 запросов в сутки
1 000 000 запросов в сутки / 10 запросов в секунду (ограничение амо) = 100 000 секунд = ±27 часов
Итог: синхронизация никогда не закончится
Изначально выбрали amoCRM, так как «проходи» по лимиту запросов к системе. Но с течением развития проекта требования и функции увеличились и мы «уперлись» в лимит.
Мы выбрали неподходящий инструмент. AmoCRM физически не подходит для обработки большого количества запросов.Также ошибка была в том, что мы разрабатывали все на GO, и за это отвечал один специалист. Когда он ушел, осталась гора legacy кода, который никто не смог бы разобрать. Но, к сожалению, или к счастью это не было нужно.
Опять все сломали
Этот кейс — еще один пример проекта, который закопали в согласованиях и куче неоправданного менеджмента.
Нам не хватило экспертности в техническом плане. Клиенту — устойчивости в управлении и желания довести проект до конца.
Но это опыт. Благодаря ему теперь подобные задачи выглядят максимально тривиально и мы уже воспроизвели подобное решение в рамках другого проекта.
Как можно было избежать неудачи
Чтобы не повторять таких кейсов в будущем, мы выделили аспекты, которые нужно соблюдать в работе с enterprise клиентами.
- Держать контакт с менеджером проекта: понимать его мотивацию; помогать ему защищать презентации перед руководителями. Делать все, чтобы стейкхолдер не потерял интерес к проекту.
- Соблюдать структуру коммуникации. Все важные чекпоинты проекта — фиксировать по почте. Все обсуждения на встречах — собирать в краткое резюме. Так специалистам со стороны клиента будет проще находиться в контексте действий. Не нужно будет каждый раз восстанавливать цепочку событий.
- Определять мотивацию специалистов со стороны клиента при старте работ. Если проект не стоит в их KPI и он изначально в низком приоритете — завершить его будет практически невозможно.
- Думать наперед. Даже при разработке MVP нужно смотреть, на «узкие места», которые могут возникнуть в будущем. Проект всегда расширяется и важно предусмотреть структуру, чтобы не переписывать весь код с нуля.
Автор статьи — Фёдор Анисимов, маркетолог LAND PRO.
