В дашборде план выполнен, в кассе денег нет: почему CRM показывает несколько версий бизнеса

На планёрке всё выглядит отлично: в CRM план закрыт, сделки зелёные. Затем финансист открывает свой отчёт. Там часть счетов ещё ждёт оплаты, по нескольким заказам прошли возвраты, а крупный договор пока существует только на бумаге. Переговоры быстро переключаются с результатов на вопрос: чья цифра настоящая?

CRM не соврала. Финансовый отчёт тоже. Просто два экрана отвечают на разные вопросы, хотя оба подписаны почти одинаково. Обычно в этот момент начинают проверять формулу или интеграцию. Часто проблема появилась раньше: команда не договорилась, какое событие считать продажей, из какой системы брать дату и что делать с изменениями после закрытия сделки.

Ниже — причины, из-за которых CRM показывает несколько версий бизнеса, и короткая проверка для показателя, на который собирается опереться руководитель.

Одна «продажа» скрывает четыре разных события

У отдела продаж, финансов и операционной команды разные моменты истины. Для менеджера результатом может быть подписанный договор или статус «успешно». Для финансиста — поступление денег. Операционный отдел смотрит на отгрузку или оказанную услугу, собственник — на выручку с учётом возвратов и отмен.

Все определения рабочие. Стадии воронки показывают загрузку менеджеров и вероятность закрытия сделок. Платёжные данные отражают движение денег. Сведения об исполнении подтверждают, что обязательства выполнены. Путаница начинается, когда четыре события получают одну подпись «продажи» и оказываются на соседних виджетах.

Технически такой дашборд может быть безупречен. CRM честно суммирует сделки на нужной стадии, учётная система — платежи, сервис доставки — отгруженные заказы. Ошибка сидит в подписи: она делает разные источники и моменты времени похожими.

До обсуждения цветов и графиков разложите путь сделки на события. Затем выберите то, которое отвечает на вопрос руководителя.

Статус «успешно» обещает деньги, которых ещё нет

Менеджер переводит карточку в «успешно», когда клиент согласился, подписал договор или выполнил другое принятое условие. На этом коммерческая работа может быть закончена. Платёжный контур в этот момент ещё молчит: деньги придут позже, частями или не придут вовсе.

Если дашборд принимает зелёный статус за оплату, прогноз незаметно становится фактом. Руководитель видит выполненный план и увеличивает расходы на найм, закупки или рекламу. Несовпадение обнаруживается позже, когда решение уже принято.

Показателям нужны точные названия. «Сумма закрытых сделок» берётся из CRM. «Полученные оплаты» — из платёжной или учётной системы. «Чистая выручка» учитывает возвраты, скидки и частичные платежи. Их можно держать рядом на одном экране, если интерфейс показывает разницу.

Платёж уже пришёл. Дашборд узнает через час

У данных свой распорядок. CRM меняется после действия менеджера, платёжный сервис отправляет событие по API, учётная система проводит документы по расписанию, аналитическая витрина пересобирается через заданный интервал.

Поэтому отметка «обновлено сегодня» помогает примерно как часы без минутной стрелки. Платёж мог прийти пять минут назад, а в отчёте появится через час. При тихом сбое вчерашнее значение останется на экране и будет выглядеть вполне бодро.

У критичного показателя должны быть время последнего успешного обновления, допустимая задержка и сигнал о её превышении. Для утреннего совещания подойдут данные на начало дня. Для контроля оплат или нагрузки поддержки нужен другой ритм. Частоту задаёт решение, которое команда принимает по цифре.

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

Статус успели поменять менеджер, робот и интеграция

Одно поле может обновить менеджер, автоматический сценарий, импорт и внешняя система. Сотрудник считает договор согласованным, автоматизация реагирует на выставленный счёт, интеграция получает оплату. Побеждает тот, кто записал значение последним, хотя его версия может быть менее точной. Обратная синхронизация иногда ещё и возвращает старый статус после правки сотрудника.

Поэтому ключевым полям нужен владелец. Команда заранее фиксирует, какая система создаёт значение, кто может его менять и какое событие считается окончательным. Журнал хранит прежнее и новое значение, время и автора операции. Тогда спор заканчивается проверкой цепочки событий.

В платформе аттестации для Университета Льва Толстого эту логику закрепили в модели заявок. Она учитывает переносы, неявки и пересдачи. Супер-администратор видит видеозаписи, администратор работает с документами и результатами без доступа к видео. Через решение прошли около 460 кандидатов. Роли и переходы между состояниями зафиксированы в самой системе, у каждого статуса есть однозначный смысл.

Возврат прошёл, а выручка осталась зелёной

Сделка может включать аванс, окончательный расчёт и частичный возврат. Если модель увидела только первый платёж, хорошая новость останется на экране дольше, чем в деньгах.

Сумма оформленных сделок показывает объём договорённостей в CRM. Полученные деньги отражают кассовое движение. Чистый денежный результат учитывает возвраты и отмены по согласованному правилу. У каждого показателя своя дата: сделка, платёж и возврат могут попасть в разные месяцы.

Правило пересчёта истории выбирают заранее. Июльский возврат по июньской продаже можно отнести к июню или показать корректировкой в июле. Оба подхода работают. Их смешение ломает сравнение периодов.

Два руководителя открывают один отчёт и видят разные цифры

Одинаковая страница ещё не означает одинаковую выборку. CRM и аналитические системы ограничивают данные по ролям, подразделениям, регионам и владельцам записей. Руководитель отдела видит свою команду, коммерческий директор — весь контур, партнёр — доступные ему сделки. Дополнительные фильтры могут сохраниться в ссылке, профиле или состоянии отчёта.

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

Критичные срезы стоит показывать рядом с показателем: период, подразделение, валюта, тип клиента и используемая дата. Для общих встреч нужен сохранённый эталонный набор фильтров. Экран также должен предупреждать, когда права доступа скрывают часть данных.

Плохая цифра молчит до первого дорогого решения

Ошибочный показатель не выводит предупреждение «по этой цифре пока не нанимайте людей». Он просто остаётся зелёным. Завышенный прогноз позволяет раньше увеличить расходы. Заниженная загрузка откладывает найм и создаёт очередь. Неполные данные по возвратам маскируют проблему продукта.

После нескольких расхождений у CRM появляются соседи. Руководитель просит выгрузку, менеджер ведёт параллельный файл, финансист собирает собственный отчёт. Каждая копия приносит ещё одно правило и ещё одну задержку. Совещание уходит на сверку таблиц.

Качество дашборда лучше измерять временем от отклонения до действия. Если команда сначала выясняет, какая цифра верна, экран пока показывает проблему, а не помогает её решить.

Шесть подписей под цифрой возвращают ей смысл

Возьмите показатель, из-за которого чаще всего спорят отделы, и заполните короткую карточку.

1. Решение. Что изменит руководитель после роста или падения показателя?
2. Определение. Какое событие, формула и период входят в расчёт?
3. Источник. Какая система считается основной при расхождении?
4. Свежесть. Как часто обновляются данные и где виден сбой?
5. Ответственный. Кто отвечает за смысл и качество данных?
6. Действие. Какое отклонение требует реакции и кто её запускает?

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

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

Коробочная CRM держится, пока процесс помещается в настройки

Готовая система подходит, если воронка близка к стандартной, роли укладываются в её модель, а интеграции передают данные с нужной глубиной. Часто достаточно пересобрать стадии, обязательные поля, права, автоматические действия и несколько отчётов. Собственный контур в такой ситуации добавит стоимость и ответственность без заметной пользы.

Кастомная логика нужна, когда CRM управляет основным операционным процессом: связывает сайт, личный кабинет, 1С, ERP, склад или хранилище данных; учитывает несколько типов договоров и оплат; разводит сложные права; рассчитывает показатели по правилам компании; хранит историю изменений и работает под высокой нагрузкой.

В операционном контуре Alps2Alps приложения пассажиров и водителей связали с промежуточным бэкендом и административной панелью для управления заказами, партнёрами, комиссиями и статусами. Среднее время обработки заказа сократилось с 4,5 минуты по телефону до 45 секунд через приложение, обращения в поддержку — с 450 до 140 в месяц, нагрузка на диспетчеров — примерно на 65%. За каждым статусом закреплены ответственный и следующее действие. Эффект подтверждают скорость операций и объём обращений.

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

Подробнее о подходе Qtim к проектам CRM и управленческих дашбордов.