Как автоматизировать ежедневный отчёт по продажам и остаткам

Коротко

Автоматизированный отчёт по продажам и остаткам — это не “красивая dashboard-страница ради dashboard-страницы”. Это регулярный сценарий, который сам забирает данные из CRM, маркетплейсов, склада, таблиц или 1С, приводит их к единому виду и отправляет понятный итог в Telegram, почту, Google Sheets, Notion или BI.

Минимальный полезный отчёт должен отвечать на четыре вопроса:

1. Сколько продали за вчера / неделю / месяц?
2. Что изменилось относительно предыдущего периода?
3. Какие товары скоро закончатся или уже закончились?
4. Что нужно сделать сегодня: пополнить, отключить рекламу, проверить карточку, связаться с поставщиком, разобрать аномалию?

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

Почему ручной отчёт быстро становится слабым местом

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

> Вчера 74 заказа, выручка 183 000 ₽, остатки по трём SKU меньше 5 шт.

Пока источников мало, это работает. Но дальше появляются типовые сбои.

Данные лежат в разных местах

Продажи на сайте — в CRM. Заказы с WB и Ozon — в кабинетах маркетплейсов. Остатки — частично на складе, частично в таблице, частично в FBO. Реклама — в отдельном кабинете. Возвраты и комиссии — ещё в одном отчёте.

Каждая система считает немного по-своему. В CRM “продажа” может означать оплаченный заказ. На маркетплейсе — заказ, доставку или выкуп. В таблице менеджер может вести “отгружено”. Если не договориться о терминах, отчёт будет спором о цифрах, а не инструментом управления.

Отчёт опаздывает

Ручной отчёт обычно появляется тогда, когда у ответственного есть время. Иногда в 9:30, иногда в 12:00, иногда “сегодня не успел”.

Для продаж и остатков это критично. Если товар закончился, его нужно увидеть утром. Если рекламная кампания потратила бюджет без заказов, её надо заметить до того, как она сожжёт ещё день.

Ошибки выглядят как нормальные цифры

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

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

Как должен выглядеть нормальный ежедневный отчёт

Не стоит начинать с вопроса “какой BI выбрать”. Начинать нужно с управленческого решения: кто читает отчёт и что он делает после прочтения.

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

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

Для маркетолога — продажи по каналам, рекламные расходы, CTR, ДРР/ACOS, товары с расходом без заказов.

Для селлера WB/Ozon — остатки по складам, продажи по артикулам, дни до out-of-stock, возвраты, товары с высоким спросом и низким запасом.

Пример Telegram-дайджеста

Такой отчёт можно отправлять каждое утро в рабочий Telegram-чат:

```text Ежедневный отчёт: 08.07.2026

Продажи за вчера:

• Заказы: 126 (+14% к предыдущему дню)
• Выручка: 348 900 ₽ (+9%)
• Средний чек: 2 769 ₽ (-4%)

Маркетплейсы:

• WB: 81 заказ, 214 300 ₽
• Ozon: 37 заказов, 98 600 ₽
• Сайт/CRM: 8 заказов, 36 000 ₽

Остатки:

• Критично: 4 SKU меньше 3 дней продаж
• Ноль на складе: 2 SKU
• Излишек без продаж 30+ дней: 6 SKU

Что проверить сегодня:

1. Пополнить SKU-1842: осталось 7 шт., средние продажи 5 шт./день.
2. Разобрать Ozon SKU-2201: расход рекламы есть, заказов 0 за 3 дня.
3. Проверить WB SKU-1170: резкое падение заказов -42%, остаток нормальный.

```

Это не “большая аналитика”. Но такой дайджест уже помогает принимать решения каждый день.

Из каких источников собирать данные

Список источников зависит от бизнеса, но чаще всего встречается один из пяти наборов.

CRM и заявки

AmoCRM, Bitrix24, RetailCRM, самописная CRM, заявки с сайта, формы, Telegram-боты. Отсюда берут количество лидов, сделки, статусы, оплату, менеджера, канал привлечения.

Важно заранее определить, какие статусы попадут в отчёт. Например, “новая заявка” — это ещё не продажа. “Счёт выставлен” — тоже не продажа. Для ежедневного отчёта лучше разделять лиды, оплаченные заказы и отгрузки.

Маркетплейсы WB и Ozon

Для WB/Ozon полезны три группы данных:

• заказы и продажи;
• остатки по складам;
• цены, скидки, комиссии, возвраты, реклама.

На старте не обязательно тащить всё. Часто достаточно продаж и остатков, а финансы и рекламу подключить вторым этапом.

Для селлера важный показатель — не просто “остаток 20 штук”, а “остаток на сколько дней продаж”. Если товар продаётся 1 штуку в неделю, 20 штук — это много. Если 10 штук в день — это проблема на послезавтра.

Склад, 1С, МойСклад, таблицы

Остатки часто живут не там, где продажи. Особенно если есть собственный склад, FBS, оптовые отгрузки или офлайн-точки.

Если складской учёт пока в Google Sheets, это не повод откладывать автоматизацию. Таблицу тоже можно подключить как источник. Главное — зафиксировать структуру: артикул, название, остаток, резерв, дата обновления.

Реклама и расходы

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

Минимум: расход по каналам и кампаниям. Лучше: расход по товару или группе товаров, если источник позволяет.

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

• выручка;
• рекламный расход;
• приблизительная маржинальность;
• полноценный P&L после подключения финансовых данных.

Ручные корректировки

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

Это нормально. Хорошая система автоматизации не требует “или всё идеально, или ничего”. Можно автоматизировать 80% сбора, а 20% оставить в контролируемой таблице с понятным владельцем.

Рабочий процесс: как строится автоматизация

Практически такой проект лучше делать не как “давайте внедрим BI”, а как короткий производственный контур.

Шаг 1. Описать текущий ручной отчёт

Сначала нужно разобрать, как отчёт делается сейчас:

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

Хороший вопрос на этом этапе: “Если завтра этот отчёт исчезнет, что сломается?” Ответ сразу показывает, какие блоки важны, а какие добавлены “потому что когда-то попросили”.

Шаг 2. Зафиксировать словарь метрик

До интеграций нужно договориться о терминах.

Например:

• “заказы” — созданные заказы или оплаченные?
• “продажи” — доставка, выкуп или оплата?
• “выручка” — до скидок или после?
• “остаток” — доступный к продаже или вместе с резервом?
• “нулевой остаток” — по всем складам или по конкретному каналу?
• “день продаж” — среднее за 7, 14 или 30 дней?

Без такого словаря автоматизация просто ускорит хаос.

Шаг 3. Подключить источники

Дальше подключаются API, выгрузки или таблицы.

Варианты бывают разные:

• API CRM;
• API WB/Ozon;
• Google Sheets;
• выгрузки CSV/XLSX;
• база данных;
• вебхуки из сайта или Telegram-бота;
• складская система;
• самописная админка.

Если у источника есть нормальный API, лучше использовать API. Если API нет или он нестабилый, можно начать с регулярной выгрузки файла. Главное — не делать “робота, который кликает личный кабинет” первым вариантом, если можно забрать данные нормальным способом.

Шаг 4. Привести данные к единой модели

Типовая ошибка — пытаться сразу рисовать отчёт из сырых данных.

Лучше сделать промежуточный слой:

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

Так проще добавлять новые источники и проверять ошибки.

Шаг 5. Настроить проверки качества данных

Автоматический отчёт должен сам проверять, можно ли ему доверять.

Минимальные проверки:

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

Если проверка не прошла, отчёт не должен молча отправлять красивую неправду. Он должен написать: “Данные Ozon не обновились, блок Ozon пропущен” или “Остатки WB старше 24 часов”.

Шаг 6. Собрать дайджест и алерты

Отчёт должен быть не просто таблицей, а текстом с выводами.

Например:

• “3 товара закончатся меньше чем за 5 дней”;
• “2 кампании тратят бюджет без заказов”;
• “по категории X продажи выросли на 28%”;
• “по SKU Y остаток нормальный, но продажи упали — проверить карточку/цену/выдачу”.

Для Telegram удобно делать два уровня:

1. короткий утренний дайджест;
2. ссылка на подробную таблицу или dashboard.

Так руководитель читает главное за минуту, а менеджер может провалиться в детали.

Шаг 7. Логировать выполнение

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

Минимум в логах:

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

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

Где здесь AI, а где обычная автоматизация

Не нужно вставлять AI туда, где достаточно SQL-запроса и нормальной формулы.

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

AI полезен в другом:

• сформулировать понятный текстовый вывод;
• объяснить аномалии простым языком;
• сгруппировать проблемы по важности;
• подготовить комментарий для руководителя;
• предложить гипотезы: “похоже на out-of-stock”, “возможно, изменилась цена”, “проверьте рекламу”;
• ответить на вопрос в чате: “почему вчера упали продажи по Ozon?”

Но AI не должен без подтверждения менять цены, запускать поставки, отключать рекламу или писать клиентам, если это не согласовано отдельным правилом.

Нормальная архитектура: расчёты делает код, AI помогает читать и объяснять, человек подтверждает действия.

Сколько времени можно сэкономить

Экономия зависит от количества источников и текущей дисциплины.

Типичная картина для малого бизнеса:

• ручной сбор отчёта: 30–90 минут в день;
• проверка остатков: ещё 15–40 минут;
• уточнения в чатах: 10–30 минут;
• исправление ошибок в конце недели: непредсказуемо.

Если отчёт собирается каждый рабочий день, даже 45 минут ручной работы — это около 15 часов в месяц. При двух сотрудниках и нескольких каналах продаж легко получается 25–40 часов.

Но время — не единственный эффект.

Более важные результаты:

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

Для WB/Ozon это особенно заметно. Один вовремя замеченный out-of-stock по ходовому SKU может быть важнее, чем вся экономия на ручном сборе отчёта.

ROI: как посчитать без фантазий

Не нужно обещать, что автоматизация отчёта “увеличит прибыль на 30%”. Лучше считать аккуратно.

Простая формула:

``text Экономия времени = часы ручной работы в месяц × стоимость часа Снижение потерь = предотвращённые out-of-stock + остановленные неэффективные расходы + меньше ошибок Стоимость владения = разработка/настройка + поддержка + API/серверы + доработки ``

Пример:

• менеджер тратит 1 час в день на отчёт;
• 22 рабочих дня;
• внутренняя стоимость часа 800 ₽;
• ручной труд стоит 17 600 ₽ в месяц.

Если автоматизация стоит 80 000 ₽ и поддержка 10 000 ₽ в месяц, только по времени она окупается не мгновенно. Но если система дополнительно помогает избежать одного провала остатков на 50 000–100 000 ₽ в месяц, экономика становится другой.

Поэтому перед внедрением нужно смотреть не только на “сколько часов сэкономим”, а на решения, которые отчёт улучшит: закупки, реклама, ассортимент, работа менеджеров.

Риски и контроль

Автоматизация отчётов кажется безопасной: она же только читает данные. Но риски всё равно есть.

Неверные данные

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

Что делать:

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

Разные права доступа

Не всем сотрудникам нужно видеть выручку, маржу, себестоимость и комиссии.

Для Telegram-отчётов это особенно важно. Один чат может быть для руководителя, другой — для операционного менеджера. В первом есть деньги и маржа, во втором — список SKU к пополнению без финансовых деталей.

Слепая вера в AI-комментарии

AI может хорошо сформулировать вывод, но ошибиться в причине. Например, написать, что продажи упали из-за остатка, хотя на самом деле изменилась цена или карточка выпала из выдачи.

Поэтому AI-комментарий должен быть помечен как гипотеза, если причина не подтверждена данными.

Правильная формулировка:

> Продажи SKU-1170 упали на 42%. Остаток достаточный. Возможные причины: цена, реклама, позиция в выдаче, изменение карточки. Нужно проверить.

Плохая формулировка:

> Продажи упали из-за плохой рекламы.

Если данных по рекламе нет, это выдумка.

Автоматические действия без подтверждения

Отчёт может рекомендовать действие, но не должен сам делать чувствительные операции без правил:

• менять цены;
• отключать рекламу;
• создавать поставку;
• списывать товар;
• отправлять сообщения клиентам;
• менять статусы сделок.

Для таких действий нужен human-in-the-loop: кнопка подтверждения, права доступа, журнал действий и возможность отката.

Минимальная архитектура без лишней сложности

Для первого рабочего варианта не нужен тяжёлый BI-стек.

Можно начать так:

``text Источники данных CRM / WB / Ozon / склад / Google Sheets ↓ Сценарий загрузки API, CSV, webhooks, scheduled jobs ↓ Хранилище таблица, база данных, Google Sheets, PostgreSQL ↓ Расчёты и проверки продажи, остатки, дни запаса, аномалии ↓ Дайджест Telegram / email / dashboard / Google Sheets ↓ Логи и контроль история запусков, ошибки, права доступа ``

Для совсем малого бизнеса можно начать с Google Sheets как хранилища. Для более устойчивого варианта — PostgreSQL или другая база. Для визуализации — Metabase, Looker Studio, Superset, кастомная админка или простая HTML-страница.

Главное — не путать инструмент и процесс. Если в бизнесе нет понятных метрик и владельцев данных, даже дорогой BI будет показывать красивые, но спорные графики.

Что внедрять первым

Если делать всё сразу, проект растянется. Лучше собрать MVP отчёта за короткий цикл.

MVP ежедневного отчёта

Минимальная версия:

• продажи за вчера по каналам;
• остатки по ключевым SKU;
• товары с остатком ниже порога;
• товары с нулевым остатком;
• сравнение с предыдущим днём или средним за 7 дней;
• Telegram-дайджест утром;
• лог успешной отправки;
• предупреждение, если источник не обновился.

Этого уже достаточно, чтобы убрать ручной сбор и начать видеть проблемы.

Второй этап

После MVP можно добавить:

• дни до окончания товара;
• продажи за 7/30 дней;
• возвраты;
• рекламные расходы;
• ДРР/ACOS;
• себестоимость;
• приблизительную маржу;
• рекомендации по пополнению;
• отдельные отчёты для руководителя и менеджеров.

Третий этап

Когда данные стабильны, можно подключать AI-слой:

• текстовые объяснения;
• ответы на вопросы по отчёту;
• поиск аномалий;
• подготовку задач в CRM;
• черновики сообщений поставщикам или менеджерам;
• сценарии подтверждения действий через Telegram-кнопки.

Чек-лист перед запуском

Перед автоматизацией ежедневного отчёта проверьте:

• Есть ли список источников данных?
• Понятно ли, какие метрики нужны каждый день?
• Определены ли термины: заказ, продажа, выручка, остаток?
• Есть ли единый идентификатор товара: SKU, артикул, nmID, offer_id?
• Кто владелец отчёта?
• Кто получает короткий дайджест?
• Кто имеет доступ к финансовым данным?
• Какие пороги считаются критичными?
• Что делать, если источник не обновился?
• Где хранится история отчётов?
• Нужно ли человеку подтверждать действия?
• Кто поддерживает сценарий после запуска?

Если на половину вопросов нет ответа, начинать всё равно можно. Но лучше начать с фиксации текущего процесса, а не с выбора инструмента.

Пример для селлера WB/Ozon

Допустим, селлер продаёт 120 SKU на WB и Ozon. Утром менеджер проверяет продажи, остатки и рекламу. На это уходит около часа.

Автоматизация может выглядеть так:

1. Каждый день в 07:30 сценарий забирает продажи за вчера.
2. Отдельно получает текущие остатки по складам.
3. Считает средние продажи за 7 и 30 дней.
4. Определяет товары, которые закончатся меньше чем за 5 дней.
5. Находит товары с остатком, но без продаж за 30 дней.
6. Проверяет рекламные кампании с расходом и нулевыми заказами.
7. Отправляет в Telegram короткий дайджест.
8. Сохраняет подробную таблицу для менеджера.

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

Когда автоматизация отчёта не нужна

Есть ситуации, где автоматизация будет лишней.

Например:

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

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

Автоматизировать стоит не “потому что можно”, а когда есть регулярный процесс, понятные данные и управленческое действие после отчёта.

Как внедрить без большого проекта

Практичный план на 2–4 недели:

Неделя 1. Разбор процесса

Собрать текущий отчёт, источники, ответственных, метрики и ошибки. Зафиксировать словарь показателей. Выбрать 5–10 ключевых блоков для первой версии.

Неделя 2. Подключение данных

Подключить один-два главных источника: CRM и маркетплейс, или маркетплейс и склад. Настроить ежедневную загрузку, сохранить сырые данные, проверить совпадение с ручным отчётом.

Неделя 3. Расчёты и Telegram-дайджест

Собрать расчёты, пороги, алерты и текстовый отчёт. Отправлять его в тестовый чат. Несколько дней сравнивать с ручным отчётом.

Неделя 4. Контроль и улучшения

Добавить логи, предупреждения, права доступа, обработку ошибок. Убрать лишние показатели. Оставить только то, что помогает принимать решения.

После этого можно решать, нужен ли BI, AI-комментарии, финансовый блок, прогнозирование закупок или автоматические задачи в CRM.

FAQ

Можно ли сделать отчёт только в Google Sheets?

Да, если источников немного и объёмы данных небольшие. Google Sheets подходит для MVP: туда можно загружать данные, считать остатки и отправлять Telegram-дайджест. Но если данных много, нужны права доступа, история загрузок и стабильные интеграции, лучше переходить на базу данных и отдельный сценарий обработки.

Что лучше: BI-дашборд или Telegram-отчёт?

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

Можно ли подключить Wildberries и Ozon?

Да, у WB и Ozon есть API и отчёты, которые можно использовать для продаж, остатков, цен, финансов и рекламы. Но набор доступных данных зависит от кабинета, прав доступа, типа поставок и конкретных API. Начинать лучше с продаж и остатков, а финансовую аналитику добавлять отдельным этапом.

Нужен ли AI для такого отчёта?

Не обязательно. Базовый отчёт лучше строить на обычной автоматизации: API, база, расчёты, проверки. AI полезен поверх данных: объяснить аномалии, сформулировать выводы, ответить на вопросы, подготовить рекомендации. Но расчёты и контроль качества данных должны быть детерминированными.

Как защититься от неправильных выводов?

Нужно разделять факт и гипотезу. Факт: “остаток 4 штуки, средние продажи 2 штуки в день”. Гипотеза: “товар закончится через 2 дня”. Ещё нужны проверки источников, лог загрузок, дата обновления данных и предупреждения, если часть отчёта собрана не полностью.

Можно ли сразу автоматизировать действия: закупки, цены, рекламу?

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

Сколько стоит внедрение?

Зависит от источников, качества данных и требований к отчёту. Простая связка “таблица + один API + Telegram-дайджест” может быть небольшой задачей. Система с WB/Ozon, CRM, складом, финансами, правами доступа, логами и BI — уже полноценный проект. Правильнее сначала описать процесс и собрать MVP, а не оценивать абстрактную “автоматизацию отчётов”.

Вывод

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

Начинать лучше не с большого BI и не с “AI всё проанализирует”, а с простого контура: источники → единая модель данных → проверки → короткий Telegram-дайджест → подробная таблица → логи.

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

Если хочешь понять, что автоматизировать у себя — напиши Дмитрию в Telegram @dmkosik или опиши процесс для диагностики Paramiko: откуда сейчас берёте продажи и остатки, кто собирает отчёт, сколько времени уходит и какие решения принимаете по этим цифрам.

QA-чеклист

• [x] Есть служебный блок: статус, slug, meta title, meta description, запросы, internal links, schema notes.
• [x] H1 соответствует главному запросу.
• [x] После вступления есть обязательный блок “Коротко”.
• [x] Логика статьи выдержана: problem → workflow → ROI/time saved → risks → implementation.
• [x] Есть примеры из SMB, продаж, WB/Ozon, CRM, Telegram-дайджеста.
• [x] Нет обещаний, что AI заменит людей.
• [x] Объяснены human-in-the-loop, логи, права доступа и проверки данных.
• [x] Есть практический чек-лист перед запуском.
• [x] FAQ содержит 7 вопросов.
• [x] Финальный CTA мягкий: Telegram @dmkosik / диагностика Paramiko.
• [x] Убраны общие фразы, канцелярит и хайп.
• [x] Текст можно читать в браузере: короткие абзацы, H2/H3, списки только там, где они помогают.