На планёрках RuDesktop выручка не всегда сходилась. У прямых продаж была одна сумма, у партнёрского отдела — другая. Маркетинг готовил отдельный Excel из «Битрикса», «Метрики», «Директа» и 1С. Когда руководитель просил объяснить расхождение, обсуждение быстро превращалось в сверку таблиц.
RuDesktop тогда быстро росла, продажи шли хорошо, а отчётность оставалась вспомогательной задачей.
Я Андрей Савченко, руковожу Smart Easy BI. Наша команда собирала аналитику для RuDesktop. Исходный материал подготовил Алексей Комашко — тогда директор по маркетингу компании. Его сотрудники готовили отчётность для руководства, и многие описанные трудности он видел изнутри. Сначала мы собрали общие отчёты, а примерно через год вернулись к системе: у RuDesktop изменились продукты и процессы, отделам потребовались новые расчёты.
Иллюстрации взяты из отдельного демо в DataLens. Клиентских данных в нём нет: названия и суммы придуманы, а устройство экранов повторяет задачи из проекта.
Как собирали отчёты
RuDesktop разрабатывает платформу для удалённого управления конфигурациями устройств. Компания начала работать в 2022 году, когда с российского рынка стали уходить зарубежные аналоги. У продукта было два направления: облачная SaaS-версия и серверное on-premise-решение.
Когда Smart Easy BI подключилась к проекту, компании было около двух лет. Команда была занята продуктом и клиентами, отчётность собирали по мере надобности.
Данные уже лежали в облачном «Битрикс24», «Метрике», «Яндекс Директе» и 1С. Для руководства их сводили в Excel. Маркетинг собирал свой файл, продажи — свой, партнёрский отдел — свой.
Форма отчёта тоже менялась. К очередной планёрке собирали таблицу под текущий вопрос. На следующей встрече руководству мог потребоваться другой разрез, и работу повторяли. Старые файлы оставались, но сравнивать периоды по ним было трудно.
Спорная сделка на десять миллионов
Больше всего вопросов возникало на стыке прямых и партнёрских продаж. Цена программы для клиента не зависела от канала, а экономика RuDesktop зависела. При продаже через партнёра компания выплачивала агентское вознаграждение. Та же сделка по-разному учитывалась в планах отделов.
Некоторых клиентов без партнёра закрыть было невозможно. С этим никто не спорил. Руководству требовалось понимать вклад партнёра, особенно в сделках, где он подключался уже перед оплатой.
Алексей объяснял проблему на условной сделке. Менеджер прямых продаж Иван три месяца работает с клиентом, сумма — десять миллионов рублей. Он рассчитывает получить сто тысяч вознаграждения. Клиент готов платить, и в этот момент в карточке появляется партнёрский менеджер: продажу проводят через партнёра.
Вознаграждение Ивана теперь приходится делить с партнёрским менеджером. RuDesktop при этом отдаёт партнёру его долю и получает меньше маржи. Сделка учитывается в планах обоих отделов, хотя до этого её вёл отдел прямых продаж.
Участие двух отделов само по себе ещё не означало ошибку. В отчёте были видны участники сделки и даты. Зачем подключили партнёра, руководство выясняло отдельно у тех, кто вёл сделку.
Маркетинговый отчёт начинался с четырёх выгрузок
Маркетинг брал часть данных из «Битрикса», подтягивал «Метрику» и «Директ», добавлял сведения из 1С. Потом всё это сводили руками. При подготовке следующего отчёта всё начиналось заново.
Особенно тяжело было отвечать на вопросы о прошлом. В той конфигурации «Битрикса», которой пользовалась RuDesktop, нужную историю изменений нельзя было получить целиком. Если на планёрке спрашивали, что происходило год назад, ответ часто получался приблизительным. Не потому, что кто-то пытался приукрасить результат: целостных данных просто не было.
Сначала договорились, что считать выручкой
На первом спринте разобрали источники и согласовали единый способ считать выручку для разных отделов. В первой версии появились общая выручка и рабочие дашборды для продаж. Часть отчётов, которые прежде строили руками в CRM, больше не требовалась.
Для проекта выбрали DataLens: RuDesktop требовалась российская BI-платформа. По функциональности подошёл бы и Power BI, но зависеть от зарубежного вендора компания не хотела.
После запуска сотрудники продолжали открывать старые отчёты
После запуска часть сотрудников по привычке продолжала открывать отчёты в «Битриксе». Документ для руководства по-прежнему собирали в разных формах. За его подготовку назначили отвечать маркетинг.
Сотрудники маркетинга брали цифры из DataLens, проверяли отклонения и готовили документ в согласованной форме. По оценке Алексея, раньше на сбор уходило несколько дней. Теперь отчёт готовили за пять-шесть рабочих часов. Эти часы уходили на разбор цифр и подготовку к планёрке.
Менеджеры начали открывать дашборды сами, потому что так было удобнее. Продавцы проверяли план и стадии своих сделок. Партнёрский отдел следил за своим каналом, маркетинг сопоставлял рекламу с продажами.
Через год появились другие вопросы
Примерно через год прежнего набора отчётов уже не хватало. В RuDesktop появились новые продукты и тарифы, изменились процессы. Свои отчёты понадобились отделу внедрения.
На втором этапе требования приходили уже от самих отделов. Продажи просили связать квартальный план с текущими сделками, маркетингу требовалась история контактов после выставок. Партнёрский отдел развивал свои отчёты. Руководитель внедрения хотел перестать пересчитывать события в календарях сотрудников.
Что оставалось после выставки
Серверную версию RuDesktop продвигали на отраслевых выставках. Участие стоило дорого. После мероприятия в CRM появлялись контакты, а до сделки могли пройти месяцы.
Одни контакты отсеивались быстро, по другим создавали сделки. Некоторые сделки месяцами оставались в воронке. Когда обсуждали участие в следующем году, чаще вспоминали общие впечатления: с прошлой выставки вроде были лиды и какие-то продажи. Назвать конкретные сделки и сложить их сумму было гораздо труднее.
Для выставок собрали отдельный экран. На нём были видны контакты, созданные по ним сделки и их состояние через месяц или квартал. Перед следующим мероприятием можно было открыть этот список и посмотреть, какие сделки связаны с прошлой выставкой и на какую сумму.
Квартальный план между планёрками
Планы продаж по-прежнему составляли вручную в таблицах. Готовый план загружали в аналитическую систему и связывали с текущей воронкой.
Менеджер открывал отчёт в середине квартала и видел выполнение плана рядом со списком сделок. В отдельный список попадали карточки, в которых давно не менялась стадия. На встрече с руководителем открывали конкретного клиента и решали, нужен ли следующий контакт или сделку пока лучше оставить.
Теперь к плану возвращались по ходу квартала. На встречах обсуждали конкретные сделки, из которых должен был сложиться результат.
Руководитель внедрения вручную проверял календари
Во время второго этапа в RuDesktop сменился руководитель отдела внедрения. От предшественника осталось большое техническое задание. Новый руководитель пересмотрел его по мере знакомства с работой отдела и добавил свои вопросы.
Ему требовались данные о презентациях: сколько их проводят специалисты, сколько времени занимает каждая и что потом происходит с клиентом. События хранились в календарях «Битрикса», но готовой выгрузки для такого отчёта не было.
Руководитель буквально сверял календари вручную: открывал записи одного сотрудника, проверял их, затем переходил к следующему. При регулярной отчётности это занимало много времени.
Проектная команда изучила API «Битрикса» и настроила загрузку событий с обновлением раз в час. В отчёте появились количество и продолжительность презентаций по сотрудникам, а рядом — дальнейший статус клиента. Руководителю больше не приходилось пересчитывать записи в календарях.
Что изменилось на планёрках
С новым отчётом часть планёрок проходила иначе. Данные разбирали по ходу разговора. Если руководителю требовался другой срез, его открывали на месте.
Алексей оценивал изменение продолжительности встреч примерно так: раньше они занимали два с половиной часа, после доработки — около часа. Продавцам помогли ссылки из DataLens в карточки «Битрикса»: от показателя на экране можно было сразу перейти к сделке и продолжить разговор о конкретном клиенте.
По условной сделке Ивана дашборд показывал даты, сумму и момент подключения партнёра. Зачем партнёр понадобился и кому засчитать результат, руководство выясняло отдельно.
На месте DataLens могла быть другая BI-система. Для RuDesktop важнее оказался общий способ считать выручку и ответственный за отчёт.
Через год отчёты пришлось серьёзно пересобирать, и это не означало, что первая версия была плохой. Она отвечала на старые вопросы. У RuDesktop появились новые — вместе с продуктами, процессами и новым руководителем внедрения. У аналитики в компании вообще редко бывает финальная версия.
