Синхронизация остатков на маркетплейсах: 3 точки потерь
Каждое утро Игорь открывал три вкладки с остатками — и все три показывали разные цифры. Ozon считал, что синих кроссовок 47-го размера на складе 12 пар. Wildberries — 8. Реальность — 5. К обеду прилетало 30-40 отмен, к вечеру — звонки от покупателей, которым отправили не то.
Если у вас три склада, 2800 заказов в день и четыре канала продаж — вы, скорее всего, знаете это ощущение. Расхождение остатков на 9-11% выглядит как маленькая погрешность, пока не считаешь, что это 150 отмен ежедневно и почти полмиллиона рублей в месяц, которые просто утекают.
Хорошая новость: деньги теряются в трёх конкретных точках. И все три можно закрыть.
Контекст клиента
К нам обратился Игорь - директор по логистике e-commerce компании из Екатеринбурга. Оборот 45 млн ₽ в месяц, три склада, 2 800 заказов в день на четырёх каналах: Ozon, Wildberries, Яндекс.Маркет и собственный сайт. Серьёзный бизнес, не стартап.
До нашего знакомства остатки в каждом канале обновлялись вручную: операционист выгружал данные из учётной системы, открывал личные кабинеты маркетплейсов по очереди и вносил цифры руками. Цикл - раз в 4-5 часов. При таком объёме заказов это примерно как тушить пожар стаканом воды.
---Что у них болело - в цифрах
Проблема была не в людях - операционист работал добросовестно. Проблема была в самой схеме: за 4-5 часов между обновлениями остатки успевали разойтись на 9-11%. При 2 800 заказах в день это давало 120-150 отмен ежедневно.
Вот как выглядела картина до внедрения:
- Cancel-rate: 5,2% - покупатель оформлял заказ, а товара уже не было
- Ошибки синхронизации остатков: 10,5% позиций в любой момент времени расходились между каналами
- Ошибки комплектации: 3,8% заказов уходили с неправильным товаром - путаница между складами
- Оборачиваемость склада: 18 дней вместо нормальных 12-14 для этой ниши
- Возвраты: 4,1% - часть из-за пересорта, часть из-за отправки «чем богаты»
- Ручная синхронизация: 4,5 часа в день одного сотрудника
В деньгах это выглядело так: 280-320 тыс ₽ в месяц теряли на отменённых заказах, ещё 150 тыс ₽ - на возвратах из-за ошибок комплектации. Плюс 1,2 млн ₽ в год - зарплата операциониста, который занимался только синхронизацией вместо аналитики и работы с ассортиментом.
По словам Игоря: «Главное было не потерять рейтинг на Wildberries - там за cancel-rate режут карточки моментально. Мы уже видели просадку по нескольким позициям».
---Что мы предложили - наш стек и почему именно он
Когда разбирали задачу, у нас было несколько критериев выбора. Расскажу по каждому - почему пришли именно к такому решению для этого клиента.
Критерий 1: единый источник правды для остатков
Нам нужна была одна система, которой доверяют все каналы. Выбрали МойСклад - облачный сервис управления складом и торговлей, который умеет работать с несколькими складами одновременно и поддерживает маркетплейсы из коробки. Для бизнеса с тремя складами и четырьмя каналами продаж это принципиально: остатки хранятся в одном месте, а не размазаны по четырём личным кабинетам.
МойСклад - коротко о сервисе: облачный склад + торговля, работает с маркетплейсами, подходит для малого и среднего бизнеса с несколькими точками хранения. Тарифы - от 1 000 до 6 900 ₽/мес в зависимости от числа пользователей и функций. Из минусов: интерфейс требует привыкания, а при очень большом каталоге (от 50 000 SKU) могут быть вопросы к скорости отчётов.
Критерий 2: скорость обновления
При 2 800 заказах в день товар может уйти в ноль за 10-15 минут в пиковые часы. Обновление раз в час - уже поздно. Нужна была схема, при которой изменение остатка в МойСклад моментально уходит во все четыре канала. Настроили webhook-триггеры: как только в МойСклад фиксируется продажа или перемещение товара, система сама отправляет обновление на Ozon, Wildberries, Яндекс.Маркет и сайт. Без участия человека, без расписания.
Критерий 3: защита от oversell
Это отдельная логика, которую мы прописали специально. Если синхронизация по какой-то причине задерживается - технический сбой, перегрузка API маркетплейса - система автоматически выставляет остаток «0» в проблемном канале. Лучше временно не продавать, чем получить 50 отмен и штраф от площадки.
Критерий 4: разбивка по складам
У клиента три склада в разных частях города. Ozon и Wildberries умеют работать с несколькими точками отгрузки - но только если правильно настроить привязку. Прописали логику: какой склад «отвечает» за какой канал и как перераспределяются остатки, если на одном из них что-то заканчивается.
Критерий 5: оповещения без лишнего шума
Добавили Telegram-бота для алертов. Операционист получает сообщение, если расхождение между МойСклад и любым каналом превышает заданный порог или если синхронизация не прошла вовремя. Не раз в 4-5 часов при ручной проверке - а за секунды. Telegram выбрали потому, что он уже стоял у всей команды и не нужно было учить новый инструмент.
---Как мы это внедряли - шаги по неделям
Дни 1-3: аудит и картографирование
Начали с того, что выгрузили полный каталог из всех четырёх каналов и сравнили с МойСклад. Нашли 340 позиций с расхождениями в артикулах - это первый источник ошибок, о котором клиент не подозревал. Без этого шага любая автоматизация просто автоматизировала бы хаос.
Зафиксировали схему складов: какой товар где хранится, как настроена адресация, кто отвечает за приёмку. Игорь подключил кладовщиков с каждого склада - они объяснили реальную логику, которая расходилась с тем, что было записано в системе.
Дни 4-7: настройка МойСклад и базовой интеграции
Настроили структуру складов в МойСклад, прописали привязку каждого склада к каналам продаж. Подключили Ozon и Wildberries через официальные интеграции - у обеих площадок есть документированные методы обновления остатков пакетами (до 100 позиций за раз), что снижает нагрузку на систему.
Яндекс.Маркет подключили отдельно: там своя схема авторизации и обновления по кампаниям. Собственный сайт клиента работал на кастомной CMS, поэтому для него написали отдельный обработчик.
Дни 8-12: логика oversell и тестирование
Прописали правила блокировки: при каком остатке система автоматически закрывает продажи в канале, как ведёт себя при сбое связи. Прогнали нагрузочный тест - симулировали пиковые часы с 400+ заказами в час. Нашли одно узкое место в очереди обновлений и расширили её.
Параллельно настроили Telegram-бота: прописали пороги для алертов, добавили операционистов и Игоря в группу уведомлений.
Дни 13-16: запуск и наблюдение
Запустили в боевом режиме, первые три дня мониторили вручную - сравнивали то, что видит система, с реальными остатками. Расхождений выше 1,5% не было. На четвёртый день перевели в полностью автономный режим.
---Что получили в цифрах
| Показатель | До | После | Изменение |
|---|---|---|---|
| Ошибки синхронизации остатков | 10,5% | 1,2% | −88% |
| Cancel-rate | 5,2% | 2,1% | −60% |
| Ошибки комплектации | 3,8% | 0,9% | −76% |
| Оборачиваемость склада | 18 дней | 14 дней | −22% |
| Возвраты | 4,1% | 1,8% | −56% |
| Время на синхронизацию | 4,5 ч/день | 0,4 ч/день | −91% |
В деньгах: экономия на отменённых заказах - 310 тыс ₽ в месяц. Операционист, который раньше только и делал, что синхронизировал остатки вручную, теперь ведёт аналитику по оборачиваемости и помогает с закупками - его рабочее время стало приносить реальную пользу.
ROI внедрения - около 6 месяцев. Стоимость нашей работы по этому проекту составила 185 тыс ₽.
---Что мы бы сделали иначе
Раньше начали бы с аудита артикулов. Мы потратили на это три дня в середине проекта, хотя это должен быть нулевой шаг. 340 позиций с расхождениями - не редкость, а норма для компаний, которые росли быстро и добавляли каналы по одному. В следующих проектах делаем этот аудит до старта, а не параллельно с остальным.
Настроили бы более гранулярные алерты с первого дня. На первой неделе Telegram-бот слал уведомления слишком часто - порог был занижен. Команда начала игнорировать сообщения. Пришлось перенастраивать на второй неделе. Теперь мы сначала обсуждаем с клиентом, какие отклонения действительно требуют реакции, и только потом выставляем пороги.
Заранее бы согласовали схему резервного склада. В середине проекта выяснилось, что у клиента есть неформальная практика: если на основном складе нет товара, кладовщик берёт его с «резервного» буфера, которого вообще не было в системе. Вскрылось случайно. Пришлось добавлять ещё одну точку хранения в МойСклад и перестраивать часть логики. Теперь в чек-лист первой встречи добавили вопрос: «Есть ли места хранения, которых нет в вашей учётной системе?»
---Можем повторить у вас
Этот проект подойдёт вам, если:
- Продаёте на двух и более маркетплейсах одновременно
- Cancel-rate выше 2-3% и вы понимаете, что дело в остатках
- Есть несколько складов или точек хранения
- Кто-то из команды тратит больше часа в день на ручное обновление остатков
Срок внедрения - 14-21 день в зависимости от количества каналов и сложности каталога. Стоимость - от 120 до 250 тыс ₽. Что нужно от вас: доступ к личным кабинетам маркетплейсов, доступ к учётной системе и два часа на первичный разбор схемы работы.
Напишите нам - разберём вашу ситуацию и скажем, где именно у вас теряются заказы.
---Для технического подрядчика
Стек: МойСклад (webhook на изменение остатка) → очередь сообщений → обработчики для каждого канала → Telegram-бот для алертов.
МойСклад отдаёт остатки через GET /api/remap/1.2/report/stock/bystore с разбивкой по складам и триггерит webhook при изменении stock. Лимит - 45 запросов в минуту на аккаунт, поэтому все обновления идут через очередь с батчингом.
Ozon принимает обновления пакетами до 100 SKU через POST /v2/product/import/stocks, лимит 1 req/sec - очередь обязательна. Wildberries обновляется по складу через PUT /api/v3/stocks/{warehouse
Что делать прямо сейчас
Если после прочтения статьи хочется сделать хоть что-то сегодня — вот конкретный список:
- Выгрузите cancel-rate за последние 30 дней по каждому маркетплейсу отдельно. Если где-то выше 3% — это уже сигнал, и он почти всегда про остатки.
- Пройдитесь по физическим местам хранения и сверьте их со списком складов в учётной системе. Пересортица, зона возвратов, «временная» полка у ворот — всё это невидимые остатки.
- Замерьте задержку обновления: возьмите любой товар, сделайте тестовое списание в учётке и засеките, через сколько минут изменится наличие на каждом маркетплейсе. Если больше 15 минут — у вас есть проблема.
- Посчитайте стоимость ручного труда: сколько человеко-часов в день уходит на обновление остатков и во что это обходится в деньгах.
Когда зовут нас
FlowFrame занимается именно такими интеграциями — когда каналов несколько, склады разные, а заказы всё равно теряются в промежутках между системами. Мы не продаём коробочное решение, разбираем конкретную схему под конкретный бизнес.
Если хотите понять, где у вас узкое место — просто напишите нашему AI-боту на сайте. Он задаст пару вопросов и скажет, есть ли смысл идти дальше.