Автоматизация остатков на маркетплейсах: как избежать out-of-stock и лишних поставок

Коротко

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

В нормальной схеме AI или скрипт не “сам заказывает товар на миллион”. Он готовит расчёт, показывает причины рекомендации и отдаёт решение человеку. Особенно если речь про крупную закупку, новую партию, сезонный товар или дорогую логистику.

Минимальный полезный результат: селлер видит список SKU с риском out-of-stock, товары с избыточным запасом, прогноз дней до нуля и рекомендуемое количество к поставке.

Почему остатки превращаются в проблему

На маркетплейсах остатки живут быстрее, чем управленческая таблица.

Сегодня карточку подняла реклама. Завтра конкурент ушёл из наличия, и ваши продажи выросли в два раза. Через неделю WB поменял распределение по складам, и часть остатков лежит не там, где есть спрос. На Ozon акция дала всплеск заказов, но менеджер смотрел средние продажи за месяц и не заметил ускорение.

Если планировать поставки “по ощущениям”, появляются две крайности.

Первая — out-of-stock. Товар закончился, карточка просела, реклама откручивает хуже, покупатель ушёл к конкуренту. Даже если новая партия приехала через неделю, прежний темп продаж может не вернуться сразу.

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

Для малого и среднего бизнеса это особенно болезненно. Нет отдельного аналитического отдела, закупщик совмещает поставки, рекламу и операционку, а данные разбросаны между личным кабинетом WB, Ozon, CRM, таблицами, Telegram и бухгалтерией.

Что именно нужно автоматизировать

Не стоит начинать с “AI спрогнозирует всё”. Начинать лучше с контура данных и простых правил.

1. Ежедневный сбор фактов

Система должна регулярно забирать:

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

Без этого прогноз будет гаданием. Даже хороший AI не исправит ситуацию, если ему дали остаток “примерно 300 штук”, но не сказали, что 180 уже зарезервированы, 70 лежат на слабом складе, а новая партия приедет только через 18 дней.

2. Расчёт скорости продаж

Самый простой показатель — средние продажи в день. Но брать “среднее за 30 дней” опасно.

Для стабильного товара можно смотреть 14–30 дней. Для товара с рекламой, акцией или сезонностью полезнее сравнивать несколько окон:

• 3 дня — что происходит прямо сейчас;
• 7 дней — короткий тренд;
• 14 или 30 дней — базовая скорость;
• прошлый аналогичный период — если есть сезонность.

Например, товар продавался по 8 штук в день, но последние 5 дней идёт по 22 штуки. Если система считает только месячное среднее, она поздно увидит риск. Если смотрит только последние 3 дня, может принять случайный всплеск за новый стабильный спрос. Поэтому лучше показывать не одну цифру, а диапазон и причину.

3. Прогноз “дней до нуля”

Это базовый сигнал для селлера.

Формула простая:

остаток, доступный к продаже / средняя скорость продаж = сколько дней осталось

Но в реальности нужно учитывать:

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

Если остатка 300 штук, продажи 20 в день, кажется, что есть 15 дней. Но если поставка занимает 12 дней, а страховой запас нужен на 5 дней, то проблема уже началась. Формально товар ещё есть, но управленчески он уже в красной зоне.

4. Рекомендации по поставке

Хорошая автоматизация не просто пишет “мало остатков”. Она предлагает действие:

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

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

Пример: как это выглядит у селлера WB/Ozon

Допустим, у продавца 180 SKU. Часть продаётся на WB, часть на Ozon, остатки ведутся в Google Sheets, закупки обсуждаются в Telegram, а поставки планирует менеджер два раза в неделю.

До автоматизации процесс выглядит так:

менеджер выгружает отчёты → сводит таблицу → смотрит остатки → вручную считает средние продажи → отмечает красным товары “меньше 20 штук” → пишет закупщику → через несколько дней часть данных уже устарела.

После автоматизации схема может быть такой:

каждое утро система забирает данные WB/Ozon → пересчитывает скорость продаж и дни до нуля → учитывает поставки в пути → формирует список рисков → отправляет в Telegram короткий отчёт → спорные позиции уходят на ручную проверку.

Пример сообщения:

“SKU 12345, крем для рук 50 мл: остаток 84, продажи 18 шт/день за 7 дней, прогноз до нуля 4,6 дня. Поставка в пути: нет. Рекомендация: поставить 250–300 шт или снизить рекламу до подтверждения поставки.”

И рядом причина:

“Рост продаж начался 3 дня назад после акции. Средняя за 30 дней — 7 шт/день, средняя за 7 дней — 18 шт/день. Рекомендация требует подтверждения.”

Такой формат лучше, чем абстрактный “AI советует поставить 300 штук”. Человек видит логику и может принять решение.

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

Не всё нужно отдавать нейросети.

Сбор остатков, расчёт средних продаж, дни до нуля, сортировка по рискам — это обычная автоматизация. Скрипты, API, таблицы, база данных, планировщик задач. Здесь важна точность, а не “интеллект”.

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

• продажи выросли, но только на одном маркетплейсе;
• остаток есть, но карточка просела из-за отсутствия нужного размера;
• товар продаётся, но маржинальность ухудшилась из-за скидки и логистики;
• закупка выглядит нормальной по штукам, но слишком рискованной по деньгам;
• менеджер хочет задать вопрос в Telegram: “почему система советует не пополнять этот SKU?”

В production-системе лучше разделять роли.

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

Как посчитать эффект: деньги, время и управляемость

Автоматизация остатков редко окупается только за счёт “сэкономили 2 часа на таблице”. Хотя это тоже важно.

Основной эффект в другом.

Меньше потерянных продаж

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

Даже простое предупреждение “через 6 дней уйдём в ноль, а поставка едет 10 дней” уже снижает риск.

Меньше замороженных денег

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

Если система показывает товары с оборачиваемостью 120+ дней, это повод не закупать “по привычке” и не радоваться большому остатку.

Меньше ручной рутины

Ручная проверка остатков обычно занимает 30–90 минут в день, если SKU много и есть два маркетплейса. Плюс ошибки: не тот период, забыли учесть поставку, не заметили акцию, скопировали старую формулу.

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

Быстрее решения

Самый дорогой участок — не расчёт, а задержка решения.

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

Поэтому полезны не только отчёты, но и алерты: красная зона, срок реакции, ответственный, статус решения.

Какие метрики нужны в дашборде

Не нужно начинать с 40 показателей. Для первого рабочего контура достаточно 8–12.

Обязательные:

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

Полезно добавить статус:

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

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

Риски автоматизации остатков

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

Риск 1. Система не знает реальный контекст

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

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

Риск 2. Прогноз реагирует на случайный всплеск

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

Решение: показывать разные окна продаж и помечать аномалии. Не “продажи 30 в день”, а “3 дня: 30, 14 дней: 11, 30 дней: 8, рост связан с акцией”.

Риск 3. Не учтена экономика

Можно идеально пополнить товар, который продаётся в минус. Остатки будут красивые, а прибыль — нет.

Решение: связывать остатки с маржинальностью хотя бы на базовом уровне. Если товар уходит быстро, но комиссия, скидка, логистика и возвраты съедают прибыль, рекомендация должна быть не “закупать больше”, а “проверить экономику”.

Риск 4. Слишком широкие права доступа

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

Решение: минимальные права, отдельные токены, логи, журнал действий, подтверждение человеком для опасных операций. На первом этапе достаточно read-only доступа и рекомендаций.

Human-in-the-loop: где человек обязателен

В остатках есть действия с разным уровнем риска.

Низкий риск:

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

Средний риск:

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

Высокий риск:

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

Для высокого риска нужен человек. Не потому что AI “плохой”, а потому что решение зависит от денег, отношений с поставщиками, стратегии ассортимента и планов бизнеса, которых может не быть в данных.

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

Как внедрить автоматизацию остатков по шагам

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

Не начинайте с выбора сервиса. Сначала запишите, как сейчас принимается решение.

Кто смотрит остатки? Где лежат данные? Как часто проверяют? Кто решает, сколько закупать? Где фиксируются поставки в пути? Какие ошибки уже случались: out-of-stock, лишний склад, просроченные поставки?

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

Шаг 2. Собрать минимальную модель данных

Для первой версии не нужен “идеальный data warehouse”. Нужна таблица или база, где по каждому SKU есть:

• артикул продавца;
• артикул WB/Ozon;
• название;
• маркетплейс;
• текущий остаток;
• продажи за 7/14/30 дней;
• товары в пути;
• срок поставки;
• минимальный запас;
• статус SKU;
• комментарий менеджера.

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

Шаг 3. Настроить ежедневный расчёт

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

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

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

Шаг 4. Добавить Telegram или CRM-задачи

Если отчёт живёт только в дашборде, его легко забыть. Для SMB часто лучше работает связка:

утренний дайджест в Telegram → кнопка/ссылка “посмотреть детали” → задача ответственному → статус решения.

Например:

“5 SKU в красной зоне. 2 требуют закупки до пятницы. 1 товар продаётся быстрее из-за акции. 2 товара лежат больше 90 дней без продаж.”

Такой формат встраивается в рабочий день, а не требует отдельной дисциплины.

Шаг 5. Ввести правила согласования

Сразу определите пороги.

До какой суммы система может создавать черновик без отдельного согласования? Какие товары нельзя пополнять автоматически? Кто подтверждает закупку? Где хранится лог решения? Что делать, если данных недостаточно?

Эти правила важнее, чем выбор модели AI. Без них даже хороший прогноз будет спорным.

Шаг 6. Постепенно добавлять прогноз и AI-пояснения

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

• учитывать сезонность;
• сравнивать склады;
• связывать остатки с рекламой;
• учитывать маржинальность;
• задавать вопросы к данным в Telegram;
• формировать пояснения для менеджера;
• искать аномалии: продажи упали, остаток есть, цена изменилась, возвраты выросли.

AI здесь полезен как помощник аналитика: не вместо расчёта, а поверх расчёта.

Когда автоматизация остатков пока не нужна

Если у вас 5 SKU, поставки раз в месяц, продажи стабильные, а out-of-stock случается редко, можно обойтись аккуратной таблицей.

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

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

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

Минимальная версия для малого бизнеса

Практичный MVP можно собрать без большой разработки.

1. Источник данных: API WB/Ozon или регулярные выгрузки.
2. Хранилище: Google Sheets, Airtable, простая база или внутренний дашборд.
3. Расчёт: продажи в день, дни до нуля, оборачиваемость, товары без продаж.
4. Отчёт: Telegram-дайджест или страница с приоритетами.
5. Контроль: ручное подтверждение поставок.
6. Логи: кто принял решение и почему.

Такой контур уже даёт пользу. Потом его можно развивать в полноценный AI-агент для селлера: с вопросами на естественном языке, сценариями проверки, интеграцией с CRM, задачами закупщику и отчётами для владельца.

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

Чек-лист: готов ли процесс к автоматизации

Проверьте себя:

• У каждого SKU есть единый идентификатор между WB, Ozon, таблицами и закупкой.
• Понятно, где лежит текущий остаток и как часто он обновляется.
• Видно, какие товары уже в пути.
• Известен средний срок поставки от закупки до доступности на складе.
• Есть минимальный страховой запас или правило его расчёта.
• Продажи считаются минимум за 7, 14 и 30 дней.
• Отдельно видны товары без продаж при наличии остатка.
• Есть список товаров, которые нельзя пополнять автоматически.
• Понятно, кто подтверждает закупку.
• Есть журнал решений или хотя бы история комментариев.

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

FAQ

Можно ли полностью автоматически создавать поставки на WB и Ozon?

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

Как часто нужно обновлять остатки?

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

Достаточно ли Google Sheets?

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

AI действительно нужен для прогноза остатков?

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

Что важнее: избежать out-of-stock или лишних поставок?

Зависит от экономики. Для хитов с хорошей маржой out-of-stock обычно больнее. Для медленных товаров и дорогой закупки опаснее лишний склад. Поэтому система должна разделять товары по ролям: хиты, стабильные позиции, тестовые SKU, залежи, сезонные товары.

Как понять, что рекомендациям можно доверять?

У рекомендации должна быть расшифровка: какие данные использованы, за какой период, какая скорость продаж, какой остаток, какой срок поставки, есть ли аномалии. Если система просто пишет “поставить 500 штук” без причин, это не управленческий инструмент, а риск.

С чего начать, если сейчас всё в разных таблицах?

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

Вывод

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

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

Если у вас WB/Ozon, несколько десятков SKU, ручные таблицы и регулярные вопросы “что закупать дальше”, начинать можно с простого контура: данные → расчёт → Telegram-дайджест → подтверждение → лог решения.

Если хочешь понять, что автоматизировать у себя, напиши Дмитрию в 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] Есть примеры из WB/Ozon, SMB, Telegram-дайджеста и управленческого процесса.
• [x] Нет обещания, что AI заменит людей.
• [x] Отдельно объяснены human-in-the-loop, логи, права доступа и риск автоматических действий.
• [x] Есть практический чек-лист готовности процесса.
• [x] FAQ содержит 7 вопросов.
• [x] Финальный CTA мягкий: Telegram @dmkosik / диагностика Paramiko.
• [x] Текст написан без канцелярита, хайпа и пустых списков ради списков.