директор и машина · продажи · запись № 010 · 8 августа 2026 · Давид Герштейн

CRM врёт. Как я поймал Битрикс24 на сдвиге дат — и что делать, если отчёты не сходятся

Если две выгрузки из CRM за один и тот же период дают разные числа — это не вы что-то не так фильтруете. Возможно, ваши данные меняются под вами. У меня это выглядело так: 12,9% лидов за месяц изменили дату создания задним числом. Отчёты, планёрки, мотивация менеджеров — всё считалось на цифрах, которые тихо ползли.

Эта статья — как обнаружить такое у себя, как доказать (себе и коллегам, которые скажут «ты просто неправильно выгрузил») и как построить сторожа, чтобы это не повторялось.

Как это проявляется

Симптомы, каждый из которых по отдельности легко списать на случайность:

• отчёт за прошлый месяц, снятый сегодня, отличается от того же отчёта, снятого неделю назад;
• сумма лидов по дням не сходится с итогом за месяц;
• менеджер уверяет, что лид пришёл в пятницу, а в CRM он «создан» в среду;
• конверсия периода меняется без единой новой сделки.

Обычная реакция — перепроверить фильтры и успокоиться. Я перепроверял фильтры три раза, прежде чем допустить мысль, что проблема в данных. Это нормально: гипотеза «система врёт» психологически дороже гипотезы «я ошибся». Но проверяется она за вечер.

Как доказать: сверка с соседями по ID

В большинстве CRM (в Битрикс24 точно) идентификаторы записей растут монотонно: лид, созданный позже, имеет больший номер. Это и есть независимый свидетель. Если у лида с ID 10500 дата создания раньше, чем у лида с ID 10450, — одна из дат изменена. Сами номера подделать при обычной работе нельзя.

Методика:

1. Выгрузите лиды за период с полями ID и «дата создания».
2. Отсортируйте по ID. Дата создания обязана расти вместе с ним (с точностью до секунд одномоментных загрузок).
3. Каждое место, где дата «проваливается назад» относительно соседей, — кандидат в сдвинутые.
4. Снимите ту же выгрузку через сутки и сравните: записи, у которых дата изменилась между двумя снимками, — доказанные.

У меня в один месяц таких оказалось 12,9%. Сдвиги были кратны восемнадцати часам и накапливались — то есть это был системный процесс, а не разовая правка руками. Источник в итоге нашёлся на стороне интеграций, но статья не о нём: в вашей CRM источник будет свой. Статья о том, что без ежедневного снимка данных вы этого не увидите никогда — сегодняшняя выгрузка всегда выглядит цельной, враньё видно только в сравнении со вчерашней.

Сторож: ежедневный снимок и сверка

Решение скучное и работает: раз в сутки автоматически снимается срез (ID, дата создания, стадия, ответственный) и сравнивается с предыдущим. Любое изменение задним числом попадает в отчёт: какая запись, что было, что стало. Хранить снимки — копейки; писать сверку — один вечер.

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

Что это меняет в отчётности

Практические следствия:

• Метрики периода считать по снимку на дату закрытия периода, а не по живой базе — иначе прошлое продолжит меняться.
• В отчёте показывать расхождения как расхождения, а не выбирать «правильную» цифру молча.
• Любую интеграцию, у которой есть право писать в CRM, считать подозреваемой по умолчанию и логировать её правки.

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