Как автоматизировать отчёт из CRM и проверять его цифры

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

Главный принцип: программа считает показатели по заданным правилам, а ИИ при необходимости объясняет уже рассчитанные значения. Модель не должна угадывать сумму, восстанавливать пропуски или придумывать причину изменения показателя.

Начните с вопроса, а не со всех полей CRM

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

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

Для первого отчёта выберите один вопрос и запишите решение, которое руководитель примет по ответу. Например:

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

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

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

Составьте паспорт каждого показателя

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

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

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

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

Разделите подготовку, расчёт и объяснение

Проверяемый маршрут отчёта состоит из шести этапов:

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

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

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

ИИ можно подключить после расчёта. Он способен подготовить краткое пояснение: какой показатель изменился, с чем его следует сравнить и какие данные требуют проверки. Текст должен ссылаться на готовые значения. Фраза «падение вызвано слабой работой менеджеров» недопустима без отдельного подтверждения. Корректная формулировка: «Число успешных закрытий ниже, чем в выбранном периоде сравнения; проверьте полноту выгрузки, изменение статусов и работу по открытым сделкам».

Учебный пример: одна успешная строка и один пропуск

Условная таблица для объяснения, не реальные продажи.

Вопрос: сколько строк имеют подтверждённый статус «Закрыта успешно»?

Ответ — одна. Строка B соответствует правилу. Строка A открыта. Строку C нельзя считать ни успешной, ни проигранной: статус неизвестен и требует проверки.

Рядом с основным показателем полезно вывести контроль качества данных:

Это собственный расчёт по трём учебным строкам, а не показатель Switch On AI или результат продаж клиента. Из таблицы также нельзя получить выручку: в ней нет поля оплаты и источника, который подтверждает поступление денег.

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

Почему отчёты за один период расходятся

Сначала сравните условия расчёта, а не итоговые числа. Расхождение часто появляется в одном из следующих мест:

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

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

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

Настройте доставку как отдельную операцию

Рассчитанный отчёт ещё нужно передать правильному человеку. До автоматизации определите:

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

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

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

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

Как принять автоматизированный отчёт

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

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

В опубликованном проекте дашборда продаж Switch On AI показывает близкий подход: первая версия принимает файл CRM, рассчитывает показатели отдельным модулем и использует языковую модель для пояснений. Это MVP, привязанный к определённому формату выгрузки, а не готовое подключение к любой CRM и не сквозная аналитика.

Что подготовить для обсуждения автоматизации

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

Задача отчёта из CRM связана с процессом продаж, поэтому её можно обсудить в рамках услуги ИИ-помощника для продаж. На разборе Switch On AI сначала определит, достаточно ли фиксированного расчёта и обычной интеграции. Если текстовое пояснение действительно помогает руководителю, его можно спроектировать как отдельный слой, не передавая модели право придумывать числа.

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