Синхронизация остатков на маркетплейсах: снизили отмены с 18% до 6.5%
Каждое утро логист Игоря открывал таблицу и начинал вручную сверять остатки между четырьмя каналами. Wildberries говорит одно, Ozon — другое, склад — третье. К обеду расхождение снова достигало 15%, и где-то в этой дельте тихо умирали 35-40 заказов в день: покупатель оформлял, система подтверждала, а товара уже не было.
Cancel-rate 18%. Потери около 200 тысяч рублей в месяц. И ощущение, что бизнес работает нормально — просто немного протекает.
Если вы узнали себя — дальше будет полезно. Мы разобрали этот кейс до винтика: какие процессы ломаются первыми при росте каналов, почему стандартные решения не спасают и как выбрать стек, который закроет дыры, а не добавит новых.
Контекст клиента
К нам обратился Игорь - директор по операциям оптового маркетплейса в Москве. Компания работает сразу через четыре канала: Wildberries, Ozon, Яндекс.Маркет и собственный сайт. Оборот - 18 млн ₽ в месяц, 450 заказов в день. Масштаб серьёзный, и при таких объёмах любой сбой в учёте остатков немедленно бил по выручке на всех фронтах. До нас учёт маркетплейсов в 1с бухгалтерия велся частично: часть данных жила в МойСклад, часть - в головах логистов и Excel-таблицах. Синхронизация между каналами была ручной.
Что у них болело (в цифрах)
Расхождение остатков между четырьмя каналами достигало 11-15%. Это значит: в МойСклад товар показывает 0, а на Ozon он всё ещё «в наличии» - и покупатель спокойно оформляет заказ. Или наоборот: реальный остаток есть, но канал его не видит, выставляет «нет в наличии» и просто теряет продажу.
Каждый день из-за таких несовпадений терялось 35-45 продаж: клиент оформлял заказ, а потом получал отмену с формулировкой «товар закончился». Cancel-rate держался на уровне 18% - катастрофа для репутации на маркетплейсах, где алгоритмы ранжирования очень чувствительны к отменам.
Параллельно шла беда с отгрузкой: 7% отправок уходили с ошибкой - неправильный размер, цвет или артикул. Это возвраты, переотправки и деньги на ветер. Возвраты достигали 9,2% от оборота.
Логист тратил 4,5 часа в неделю только на ручную синхронизацию остатков - обновлял данные 2-3 раза в день, сверяя четыре канала вручную. Это не масштабируется: добавь пятый канал или вырасти по SKU - и вся система посыплется.
В деньгах потери выглядели так: недополученная выручка из-за отмен - 120-140 тыс ₽/мес, дополнительные затраты на возвраты и переотправки - 60-80 тыс ₽/мес. Около 200 тыс ₽ каждый месяц компания теряла не из-за плохого товара, а из-за рассинхронизации данных.
Что мы предложили - наш стек и учёт маркетплейсов в 1с бухгалтерия
Мы остановились на связке МойСклад + Zapier + RetailCRM. Вот как пришли к этому решению - четыре критерия, которые примеряли именно к задачам Игоря.
Критерий 1: Надёжность как единого источника правды. При 450 заказах в день нужна система, которая держит мастер-данные по остаткам без дублирования. МойСклад - де-факто стандарт для оптовых операций на российском рынке. Его REST API поддерживает webhook-подписки на события изменения остатков, что позволяет реагировать в реальном времени, а не по расписанию. Именно МойСклад стал единым источником правды: все четыре канала смотрят на него, а не друг на друга. Это закрывает и вопрос учёта продаж через маркетплейсы в 1с бухгалтерия - данные консолидируются в одном месте.
Критерий 2: Скорость внедрения без кастомной разработки. Игорю нужен был результат за 2 недели, а не за 3 месяца. Zapier позволил связать Wildberries, Ozon, Яндекс.Маркет и собственный сайт без написания кода. Мы настроили сценарии через webhook-триггеры: как только МойСклад фиксирует изменение остатка, Zapier мгновенно передаёт обновление в нужный канал. Для клиента с таким объёмом - оптимальный баланс между скоростью запуска и надёжностью.
Критерий 3: Контроль логики отгрузки. 7% ошибок при комплектации - это не проблема склада, это отсутствие автоматической валидации на этапе сборки. RetailCRM умеет управлять логикой отгрузки: проверять соответствие артикула, размера и цвета перед подтверждением отправки, отслеживать статусы и фиксировать ошибки. При таком проценте брака это был критичный компонент.
Критерий 4: Автоматическая блокировка позиций. Когда остаток падает до нуля, позиция должна сама уходить в архив или блокироваться во всех каналах - без участия логиста. МойСклад позволяет выставить флаг блокировки через API, а Zapier транслирует это событие на все четыре площадки одновременно. Именно это убивает cancel-rate: покупатель просто не видит товара, которого нет.
Отдельно про учёт маркетплейсов в 1с бухгалтерия: для Игоря эта задача решалась через МойСклад как промежуточный слой. Данные о продажах, возвратах и остатках из всех каналов агрегировались там, что сильно упростило последующую выгрузку в бухгалтерию. Учёт операций с маркетплейсами в 1с бухгалтерии перестал быть ручным процессом.
Как мы это внедряли (шаги по неделям)
День 1-3: Аудит и архитектура. Начали с полного аудита текущих потоков данных. Вместе с Игорем и логистом прошли весь путь заказа - от поступления на канал до отгрузки. Зафиксировали, где данные расходятся и в какой момент остатки перестают быть актуальными. Выяснилось, что главная точка рассинхронизации - задержка между фактическим изменением остатка в МойСклад и обновлением на каналах. При ручной синхронизации этот лаг достигал 4-6 часов.
День 4-7: Настройка МойСклад как источника правды. Создали сервисный аккаунт с минимально необходимыми правами - только просмотр, создание и обновление по нужным сущностям, без административного доступа. Подключили webhook-подписки на три ключевых события: изменение остатка, создание заказа и отмена заказа. Чтобы работать с четырьмя каналами одновременно и не упираться в лимиты запросов, разделили токены по группам каналов. Параллельно в RetailCRM настроили логику валидации отгрузки: обязательная проверка артикула и характеристик перед подтверждением сборки.
День 8-11: Zapier-сценарии для каждого канала. Построили отдельные Zap-сценарии для Wildberries, Ozon, Яндекс.Маркет и собственного сайта. Каждый сценарий работает по одной схеме: триггер от webhook МойСклад → фильтр по условию (остаток ≤ 0 → блокировка, остаток изменился → обновление) → действие в канале. Дополнительно настроили сценарий автоматической блокировки: при нулевом остатке позиция уходит в архив во всех каналах одновременно. К процессу подключился технический специалист со стороны клиента - помог с доступами к API собственного сайта и подтвердил логику по нескольким нестандартным SKU.
День 12-14: Тестирование и запуск. Провели нагрузочное тестирование на реальных данных: имитировали пиковую нагрузку в 450+ заказов за день и проверяли, что обновления остатков проходят без задержки. Обнаружился один edge-case: при одновременном поступлении заказа из двух каналов на последнюю единицу товара система иногда пропускала оба. Добавили дополнительный фильтр с приоритизацией по времени создания заказа. После финального прогона запустили в продакшн. Игорь потом сказал, что главным для него было «чтобы логист утром открывал МойСклад и видел актуальные данные - а не начинал день с ручной сверки».
Что получили в цифрах
| Метрика | До | После | Изменение |
|---|---|---|---|
| Cancel-rate | 18% | 6,5% | −64% |
| Расхождение остатков между каналами | 11-15% | 2-3% | −80% |
| Ошибки отгрузки | 7% | 1,8% | −74% |
| Процент возвратов | 9,2% | 3,5% | −62% |
| Время на ручную синхронизацию | 4,5 ч/нед | ~18 мин/нед | −93% |
| Спасённые продажи | - | +110 заказов/мес | - |
| Прирост выручки | - | +165 тыс ₽/мес | - |
Всё это - за 14 дней внедрения. Прирост выручки в 165 тыс ₽/мес складывается из двух составляющих: снижение отмен (110 спасённых продаж) и сокращение затрат на возвраты и переотправки. Логист вернул себе 4 часа в неделю и теперь занимается реальной работой, а не сверкой таблиц.
Что бы мы сделали иначе
Раньше выявили edge-case с двойными заказами. Ситуацию с одновременным заказом последней единицы из двух каналов мы поймали только на этапе тестирования. Проведи мы более детальный анализ пиковых сценариев в самом начале - логику приоритизации заложили бы сразу в архитектуру, а не добавляли патч в конце. Сэкономили бы полдня работы.
Подключили бы RetailCRM к мониторингу раньше. Валидацию отгрузки в RetailCRM мы настроили на первой неделе, но полноценный мониторинг ошибок комплектации заработал только к середине второй. Начни мы собирать данные с первого дня - картина по ошибкам была бы чётче, и системные причины брака нашлись бы быстрее.
Документировали бы нестандартные SKU заранее. У клиента было несколько сотен позиций с нестандартной логикой - товары-комплекты, где остаток считается по составным частям. Разобрались с ними в процессе, но это создало небольшой стресс в середине внедрения. Теперь мы всегда запрашиваем полный реестр исключений на старте проекта.
Можем повторить у вас
Этот кейс хорошо масштабируется на любой оптовый или мультиканальный e-commerce с объёмом от 100 заказов в день. Если у вас есть хотя бы два из следующих признаков - скорее всего, мы сможем помочь:
- Продаёте через 2+ канала и остатки расходятся
- Cancel-rate выше 8-10%
- Логист тратит больше 2 часов в неделю на ручную сверку
- Возвраты из-за ошибок комплектации выше 3-4%
- Нужен нормальный учёт продаж на маркетплейсах в 1с бухгалтерия без ручного переноса данных
Срок внедрения: 14-21 день в зависимости от количества каналов и сложности SKU-логики.
Стоимость: от 120 до 280 тыс ₽ - зависит от количества интеграций и объёма нестандартных сценариев. Точную цифру называем после бесплатного аудита текущих процессов (1-2 часа с вашим операционным специалистом).
Что нужно от вас: доступ к МойСклад или вашей учётной системе, список каналов продаж и 1-2 часа на старте для аудита. Остальное - на нас.
Итоги
За 14 дней мы связали МойСклад с четырьмя каналами продаж через Zapier и RetailCRM, настроили синхронизацию остатков в реальном времени и автоматическую блокировку позиций при нулевом стоке. Cancel-rate упал с 18% до 6,5%, ошибки отгрузки снизились
Что делать прямо сейчас
Если вы дочитали до этого места — скорее всего, узнали что-то своё. Вот четыре шага, которые можно сделать сегодня без бюджета и без подрядчиков:
- Посчитайте свой cancel-rate за последние 30 дней по каждому каналу отдельно. Часто оказывается, что проблема сосредоточена в одном-двух источниках.
- Засеките, сколько времени логист тратит на ручную сверку остатков в неделю. Умножьте на 4 — это ваш ежемесячный операционный убыток в человеко-часах.
- Выпишите все нестандартные сценарии в вашей SKU-логике: комплекты, весовые позиции, товары с серийными номерами. Это самое ценное, что вы принесёте на любой аудит.
- Проверьте, есть ли у вас реестр исключений для интеграций — позиции, которые нельзя синхронизировать автоматически. Если его нет, составьте хотя бы черновик.
Когда зовут нас
FlowFrame занимается именно такими задачами — мультиканальная интеграция, автоматизация остатков и операционная логика для e-commerce с реальными объёмами. Без лишних слов и типовых решений под копирку.
Если хотите разобраться, что происходит именно у вас — загляните к нашему AI-боту на сайте. Он задаст несколько вопросов и поможет понять, есть ли смысл идти дальше. Без давления, просто честный разговор.