В Битрикс24 отдел продаж может выполнить план без единой ошибки. Менеджеры закрыли нужную сумму, статусы выставлены по принятому регламенту, отчёт сходится. И всё же у руководителя остаются вопросы: какие заказы удастся исполнить в срок, сколько денег уже поступило, что осталось после прямых расходов и во сколько в итоге обойдутся проданные проекты.
Причина обычно находится за пределами воронки. CRM хранит сведения о клиентах и сделках, а отгрузки и оплаты могут учитываться в 1С, остатки — в складской системе, трудозатраты — в сервисе управления проектами. Повторные покупки проходят через личный кабинет, обращения клиентов остаются в HelpDesk. Каждая система описывает свой участок работы и обновляется в свой момент.
Проблема возникает, когда один показатель начинают читать как итог всей цепочки. Успешная сделка означает ровно то событие, которое компания закрепила за этим статусом: например, подписанный договор или принятый заказ. Из него самого нельзя узнать, был ли товар свободен на складе, наступил ли срок платежа, сколько часов потребовал проект и с какими обращениями клиент подошёл к продлению.
Чтобы ответить на эти вопросы, данные приходится связывать по заказам, клиентам, товарам и датам. Здесь легко получить убедительный отчёт с неполным выводом: физический остаток не учитывает резервы, сумма сделки — себестоимость, доставку и другие прямые расходы, первая покупка — последующие заказы, текущее состояние — историю изменений.
В статье разберём несколько условных сценариев с условными цифрами. Они не относятся к одной компании и не описывают наши внедрения. Их задача — показать, каких данных не хватает в разных управленческих ситуациях: при исполнении заказа, контроле оплаты, расчёте прямых и проектных затрат, оценке повторных продаж, подготовке к продлению сервиса и разборе событий задним числом.
BI-система, в том числе DataLens, может показать подготовленные сведения на одном экране и помочь сравнить связанные события. Она не определяет правила учёта, не исправляет расхождения в исходных данных и не восстанавливает историю, которую никто не сохранял. Поэтому в каждом сценарии сначала уточним решение руководителя, затем нужные источники и только после этого — содержание отчёта.
Коротко
- Закрытая сделка в Битрикс24 фиксирует только один статус, а не весь путь заказа: исполнение, оплату, себестоимость и повторные продажи система не увидит сама.
- Данные об остатках, оплатах, трудозатратах и повторных покупках чаще лежат в других системах — 1С, HelpDesk, складских и проектных сервисах.
- BI-система, включая DataLens, объединяет эти данные на одном экране, но не подменяет учёт и не восстанавливает историю, которую никто не сохранял.
- Дальше разбираем шесть условных сценариев: дефицит на складе при полном плане продаж, разную экономику одинаковых по сумме сделок, кассовый разрыв между продажей и оплатой, перерасход в процессе проекта, реальную ценность рекламных каналов и риск потерять клиента перед продлением контракта.
Где заканчиваются возможности стандартного отчёта в Битрикс24?
Писать, что облачный Битрикс24 вообще не умеет работать с внешними системами, было бы некорректно — у него есть API и даже довольно большой магазин приложений и готовых интеграций. Но всё это работает лишь до того момента, пока компания не начинает дорабатывать инструменты под себя: перепиливать 1С, создавать кастомные поля в Битрикс24, а иногда и вовсе использовать самописные учётные системы. И проблема появляется, когда мы задаём вопрос, на который в стандартном отчёте нет прямого ответа.
Например, простая задача: если себестоимость хранится в 1С, она не появится в отчёте по сделкам сама — но её действительно можно решить через стандартный коннектор. А теперь представим чуть сложнее: ремонт оборудования учитывают в отдельной программе, запчасти числятся на складе, расходы на логистику — в третьей системе, а фактический расход времени сотрудник вообще ведёт в Excel. В этом случае уже сложно быстро понять, сколько денег принёс клиент и сколько мы на него потратили.
Отчёт на данных одной CRM видит только ту часть бизнеса, которая в ней отражена.
DataLens позволяет анализировать её вместе с данными других систем. При условии, что эти данные собраны, сопоставлены и подготовлены. Сам по себе красивый дашборд эту работу не делает.
Продали сто штук, отгрузить можем сорок — почему так происходит?
Продолжим на реальных примерах и начнём с оптовой компании. Сделки ведут в Битрикс24, остатки и резервы — в полностью перепиленной под себя 1С. Менеджер продаёт 100 единиц товара: он видит в Битрикс24 остаток на конец прошлого рабочего дня — 120, звонит на склад, и ему подтверждают, что товар есть в наличии. Вроде бы можно обещать поставку. Но фактически с утра 80 единиц уже зарезервированы под заказы другого менеджера. Свободно только 40, а ближайшее поступление — через две недели, и менеджер, который продал 100, этого не видит.
А РОП вообще живёт в постоянном напряжении, прокручивая в голове одни и те же вопросы: сколько заказов теперь под угрозой? Кому товар обещали раньше? Можно ли отгрузить часть? Какие закупки нужно ускорить?
По одной воронке продаж этого не понять. Отдельный отчёт об остатках тоже не поможет, если в нём нет обещанных клиентам сроков и заказов, которые ещё не передали на склад. Остаток и доступный остаток — разные показатели. Если забыть про резервы, получится вполне убедительный отчёт с неверным ответом.
Если мы видим правильный дашборд, то легко можем сопоставить позиции сделок, даты поставки, остатки, резервы и ожидаемые поступления. Тогда руководитель увидит конкретные заказы с дефицитом и сумму продаж, которая зависит от его устранения.
Два менеджера продали одинаково — почему заработали для компании по-разному?
Допустим, два менеджера закрыли по 5 млн рублей. По объёму продаж — ничья.
Первый давал большие скидки, обещал бесплатную доставку и продавал товар из дорогой закупочной партии. Второй удерживал цену, а его клиенты забирали заказы самостоятельно.
В Битрикс24 есть суммы сделок. Закупочная стоимость лежит в 1С, транспортные расходы — в логистической системе, возвраты — на складе. Чтобы сравнить результат менеджеров, нужно связать эти сведения с заказами, и одна мысль о куче Excel-файлов вгоняет в ужас.
Возьмём одну продажу на 1 млн рублей. Себестоимость — 600 тыс., скидка — 100 тыс., доставка — 80 тыс., дополнительные прямые расходы — 40 тыс. Остаётся 180 тыс. Назвать это чистой прибылью было бы слишком оптимистично, но уже можно обсуждать экономику сделки, условия доставки и допустимую скидку. И правильно все эти данные видеть до того, как сделка заключена.
BI помогает оценить, сколько остаётся от продажи после согласованных затрат. И дальше сравнивать по этому показателю товары, клиентов и менеджеров.
План закрыли, оплату ещё ждём: почему сделка и платёж — не одно и то же?
У поставщика есть отсрочки платежа. Продажи ведут в Битрикс24, отгрузки и взаиморасчёты — в 1С. Менеджер быстро закрыл сделку: клиент получил товар и внёс аванс. Остаток он должен был перечислить на прошлой неделе, но пока не сделал этого.
Успешная сделка, отгрузка и поступление денег — три разных события. Если в CRM отражено только первое, отчёт по продажам не объяснит ситуацию с оплатой.
На дашборде можно сопоставить сделки с документами реализации, графиком платежей и фактически распределёнными оплатами. Руководитель увидит, сколько продали, сколько отгрузили, сколько поступило денег и сколько счетов просрочено.
Причём по конкретному клиенту, сделке, договору и менеджеру — всего в пару кликов.
Но помимо упрощения жизни руководителя или собственника из такого отчёта получается очередь действий для всей команды: кому позвонить сегодня, с кем пересмотреть отсрочку, какие ожидаемые поступления нужно перепроверить. А если добавить график расходов, можно оценивать риск кассового разрыва. Без него обещать полноценную картину будущего остатка денег я бы не стал.
Проект продали выгодно, потом начали выполнять — почему выгода тает по ходу работы?
Компания продаёт внедрение ПО. Договор на 800 тыс. рублей находится в Битрикс24. Плановые затраты — 450 тыс., и, кажется, всё выглядит нормально. В процессе работы заказчик просит несколько доработок. Команда тратит дополнительные часы, подключает субподрядчика, возвращается к уже согласованному этапу.
Часы учитывают в отдельной системе, расходов на субподрядчика вообще не было в планах, а в Битрикс24 по-прежнему числится выигранная сделка на 800 тыс. Если связать сделку с трудозатратами, стоимостью часов и внешними расходами, можно увидеть, как меняется экономика проекта в процессе выполнения. На каком этапе уже превышен бюджет? Какие работы постоянно недооценивают? Сколько стоят дополнительные пожелания клиента? Нужно ли согласовывать изменения договора?
Здесь легко обмануть себя, если смотреть только на уже понесённые расходы. Проект может пока выглядеть прибыльным просто потому, что половина работы впереди. Поэтому для незавершённых проектов нужна ещё и оценка затрат до завершения.
Результат — возможность заметить перерасход, пока на него ещё можно повлиять, а затем скорректировать оценку и цены следующих проектов.
Дешёвые заявки могут оказаться дорогим удовольствием
Компания получает заявки в Битрикс24. Первую покупку оформляет менеджер, повторные клиент делает через личный кабинет. История этих покупок хранится отдельно, себестоимость и возвраты — в 1С.
Яндекс.Директ приводит дешёвые заявки, но его клиенты чаще покупают один раз. Таргет во ВКонтакте, предположим, дороже на входе, зато покупатели возвращаются несколько раз.
Если сравнивать только стоимость заявки и первую сделку, легко выбрать Директ и сократить бюджет на ВКонтакте.
У Битрикс24 есть собственный модуль аналитики, но в нашем сценарии задача шире: учесть повторные покупки и расходы, сведения о которых находятся за пределами CRM.
Для этого связываем источник привлечения, рекламные расходы, последующие заказы, возвраты и себестоимость. Затем сравниваем группы клиентов за одинаковое время после привлечения. У тех, кто покупал в январе, было больше времени на повторные заказы, чем у тех, кто покупал в августе. Сравнение накопленных сумм без этой поправки может ввести в заблуждение.
BI позволяет оценивать рекламный канал по экономике привлечённых клиентов за выбранный период. На этой основе уже можно обсуждать бюджет и срок окупаемости привлечения.
До продления два месяца. Клиент уже устал
Компания продаёт оборудование и сервисные контракты. Продления ведутся в Битрикс24, обращения — в отдельном клиентском HelpDesk.
Клиентский менеджер видит действующий договор и планирует связаться с клиентом ближе к окончанию срока, а в HelpDesk за это время накопились повторные поломки и просроченные ремонты, которые никто не обработал. Сам по себе календарь продлений об этом не расскажет, а сервисная система, в свою очередь, может не учитывать дату переговоров и сумму будущего контракта.
Объединённый отчёт покажет клиентов, у которых скоро продление и одновременно есть проблемы с обслуживанием. Это не доказательство будущего ухода, но вполне конкретный повод подключить руководителя сервиса и разобраться до звонка с предложением нового договора.
Если добавить расходы на обслуживание, появится ещё один вопрос: насколько выгодны компании текущие условия контракта?
Практическая польза — заранее выделить клиентов, которым нужно внимание продаж и сервиса одновременно. Иногда нужен ответ на вопрос «что мы знали тогда?»
Есть ещё одна задача, которую легко упустить: накопление истории. Сегодня товара нет, но был ли он доступен, когда менеджер обещал поставку? Когда перенесли срок? На каком этапе выросла оценка проекта? Отчёт здесь похож на фотографию склада: видно, что лежит сейчас, но нет понимания, что происходило неделю назад.
Если в BI-решении объединить изменения стадий, снимки остатков, сроки и версии планов, можно восстановить последовательность событий. Тогда разговор о причинах срыва опирается на данные, а найти причину и локализовать её становится намного проще. Но подключение DataLens не восстанавливает прошлое: историю нужно получать из источников или начинать сохранять отдельно.
С какого вопроса стоит начать?
Я бы начинал с конкретного решения, которое руководителю приходится принимать вслепую или каждый раз делать руками одно и то же.
Например: «Не понимаем, какие заказы сорвутся из-за дефицита», «Не можем сравнить менеджеров с учётом прямых расходов», «Видим первые продажи с рекламы, но теряем повторные покупки».
Дальше становится понятнее, какие сведения нужны из Битрикс24, какие — из других систем и по каким правилам их связывать.
DataLens в этой связке помогает анализировать и показывать подготовленные данные. Их сбор, сопоставление и накопление — отдельная часть работы. Но и у DataLens есть ограничения на объединение разных источников внутри одного датасета, которые нужно учитывать при проектировании решения.