ИИ для анализа продаж помогает сверить план и факт по товарам, каналам и периодам, выделить аномалии и подготовить вопросы к первичным данным. Вывод о причине отклонения принимает владелец продаж после проверки заказов, возвратов и изменений условий.
Единая база сравнения
Для анализа продаж сначала одинаково определите выручку, возвраты, период и канал. ИИ покажет расхождения плана и факта, а суммы сверяют с учётом.
У двух отчётов с одинаковым названием «продажи» могут различаться даты и состав сумм. Один берёт дату заказа, другой дату оплаты; один учитывает возврат в месяц покупки, другой в месяц возврата. Сначала зафиксируйте определение выручки, валюту, НДС, статусы заказов и правило отнесения к каналу. Затем соберите фактические данные из 1С или CRM и план из утверждённой таблицы. Только после этого поручайте модели искать отклонения.
Для первого анализа хватит строк с периодом, товарной группой, каналом, планом, фактом, числом заказов и возвратами. Персональные данные клиентов здесь обычно лишние. Подготовьте словарь полей, чтобы «онлайн» в одном файле и «сайт» в другом означали один канал. Общую карту сценариев отдела показывает материал об ИИ в продажах; текущая задача уже — разбирать числовой результат, отдельно от клиентских диалогов.
- Назовите дату, по которой строится период.
- Разделите валовую выручку и возвраты.
- Сохраните источник каждой суммы и версию плана.
Перед началом сравнения согласуйте иерархию планов: годовой бюджет, месячный план и оперативная корректировка могут давать разные базы. Руководитель должен видеть, с каким именно утверждённым вариантом сравнивается факт. Корректировки храните отдельными версиями с датой решения. Тогда объяснение отклонения сохраняет смысл даже после изменения коммерческих целей.
Товары и каналы
Разрезы нужны ровно те, по которым руководитель способен действовать. Таблица по товару, каналу и неделе покажет, где отклонение возникло; чрезмерная детализация по каждому клиенту создаст шум. Группируйте редкие позиции в согласованные категории и фиксируйте правило группировки. Если одна продажа отражена одновременно в CRM и учётной системе, удалите дубль по идентификатору заказа, без сравнения по похожей сумме. Убедитесь, что итог по всем каналам сходится с контрольной суммой учёта.
| Разрез | Что спросить | Проверка |
|---|---|---|
| Товар | Какие позиции дали вклад в отклонение | Сверить коды и возвраты |
| Канал | Где изменился поток заказов | Проверить источник заказа |
| Период | Когда началось изменение | Сверить календарь акций |
| Статус | Какая доля ещё без оплаты | Проверить закрытие заказов |
Запрос к модели можно дать так: «Используй приложенную таблицу как единственный источник чисел. Покажи отклонение факта от плана по товару и каналу. Отдельно перечисли строки с пустыми полями, подозрительными возвратами и неоднозначными названиями. Для каждого вывода укажи строки источника. Причины обозначай гипотезами до проверки». GigaChat или YandexGPT удобны для текстовой интерпретации небольшой обезличенной выгрузки, а сами суммы лучше считать формулами в таблице или запросом к базе.
Если нужна именно оценка работы менеджеров, воспользуйтесь отдельным промптом для отчёта менеджеров. Смешение персональной оценки с динамикой товарных групп приводит к неверным решениям.
Аномалии и причины
Аномалия — сигнал для проверки, без готового объяснения причины. Скачок выручки может возникнуть из-за крупного заказа, изменения цены, исправления данных или переноса даты признания. Просите модель построить список гипотез с указанием того, какой документ подтвердит каждую. Если фактических данных мало, правильный результат анализа — перечень недостающих сведений. Нарратив про «упавший спрос» без проверки заказов и остатков опасен для закупок.
- Найдите самые большие абсолютные отклонения и отдельно процентные.
- Проверьте исходные заказы, возвраты и смену статусов.
- Сопоставьте календарь акций, цены и остатки на даты отклонений.
- Запишите подтверждённую причину или статус открытой гипотезы.
Для условного примера возьмём группу, где выручка ниже плана при стабильном числе заказов. Причиной может быть изменение среднего чека, скидка, иной состав корзины или ошибка классификации. Сначала разложите выручку на заказы и средний чек, затем откройте конкретные документы. Модель ускоряет поиск проверочных вопросов, но связь события и результата устанавливает аналитик вместе с владельцем канала.
Если команда хочет повторять такой разбор еженедельно, проект внедрения ИИ в отчётный процесс начинается с согласования определений метрик и источников. Автоматизация грязной таблицы закрепляет ошибки, поэтому первую проверку проводят на закрытом периоде с доступными первичными документами.
Где в ваших продажах расходятся план и учётный факт?
Решение владельца
Покажите руководителю короткий лист решений: факт, отклонение, подтверждённая причина, действие, ответственный и дата проверки результата. Модель может предложить варианты действий, но владелец продаж выбирает их с учётом маржи, запасов и договорённостей с клиентами. Например, снижение выручки при дефиците товара требует работы с запасом, а падение количества заказов при наличии товара — проверки воронки и каналов привлечения. Одинаковое отклонение ведёт к разным действиям.
Отдельно отметьте, что уже известно, а что ещё проверяется. Указывайте документ или строку отчёта рядом с выводом. Если причина осталась открытой, назначьте её проверку конкретному человеку. Полезно сохранять предыдущие версии плана: иначе изменение цели задним числом искажает динамику. Для руководительского экрана существует разбор дашборда продаж, но сам экран редко решает проблему расхождения определений.
Возьмите один завершённый период с заметным отклонением. Восстановите путь от итоговой цифры до заказов и возвратов; лишь затем добавляйте объяснение модели.
Критерий качества вывода — возможность другого сотрудника повторить расчёт по тем же источникам и получить ту же сумму. При расхождении сначала ищите проблему в фильтрах, а потом обсуждайте рынок.
На планёрке показывайте вклад отдельных факторов в отклонение, вместе с итоговой суммой. Например, объём заказов, средний чек и возвраты могут двигаться в разные стороны. Такой разбор помогает выбрать одно действие для проверки и избежать случайных мер сразу по всем каналам. После решения назначьте дату повторного просмотра той же метрики.
Повторяемый разбор
После первого цикла закрепите календарь обновления данных и список контрольных проверок. Перед каждой публикацией отчёта сравнивайте сумму строк с учётом, проверяйте пустые коды товаров и наличие возвратов за период. Модель получает уже сверенный набор данных и возвращает список отклонений вместе со ссылками на строки. Аналитик помечает гипотезы, а руководитель подписывает действия. Такой порядок сохраняет ответственность за финансовый вывод.
Для сравнения между периодами храните версии справочников и правила перерасчёта. Если компания переименовала канал или объединила категории, зафиксируйте дату изменения и покажите сопоставление старого и нового разреза. Иначе модель увидит искусственный рост одной категории и падение другой. Уточняйте, за какой период доступна первичка и когда данные считаются закрытыми.
Проверяйте пользу по конкретному управленческому результату: быстрее ли найдено расхождение и появилась ли подтверждённая причина до планёрки. Число красивых диаграмм здесь вторично. Если каждую неделю аналитик исправляет одну и ту же выгрузку вручную, исправьте источник или преобразование данных, прежде чем добавлять новые промпты.
- Контрольная сумма сходится с учётом.
- У каждой гипотезы есть источник проверки.
- Действия привязаны к ответственному и сроку.
Если данные закрываются с задержкой, отмечайте предварительный статус отчёта. Сравнение незакрытого месяца с полным планом даёт ложную тревогу, особенно при крупных оплатах в конце периода. Руководителю полезно видеть дату обновления и ожидаемые поздние документы рядом с каждой итоговой цифрой.