Один кабинет вместо пяти: продажи на WB, Ozon, Я.Маркет, Lamoda и СберМегаМаркете

О клиенте

Бренд декоративной косметики, выручка 600 млн ₽/год. Продают на пяти площадках: Wildberries, Ozon, Яндекс.Маркет, Lamoda, СберМегаМаркет. 8 человек в отделе e-com, ответственных за весь цикл — от карточек до закупок.

Проблема

Пять разрозненных личных кабинетов превратили операционку в постоянное тушение пожаров:

• Ручное обновление цен и остатков трижды в неделю по каждой площадке (4–5 часов работы одного сотрудника).
• Овер-сейлы: остатки на разных площадках расходились, продавали то, чего нет. Штрафы — 200–400 тыс ₽/мес.
• Маржинальность считали по кварталам в Excel — нельзя было быстро отреагировать на падение по конкретной SKU.
• Маркетинг и закупки не имели единой картины — оперативные решения принимали интуитивно.

Что сделали

Двусторонняя синхронизация

Каждые 15 минут — синхронизация остатков и цен через API всех пяти маркетплейсов. Очереди на Celery + Redis с retry-логикой. Если одна площадка лежит, остальные продолжают работать.

Postgres хранит «канонический» остаток, маркетплейсы — это слои поверх. Любое движение (продажа, возврат, поступление) обновляет канонический остаток и публикуется на все площадки.

Авто-управление ценами

Правила маржинальности задаёт менеджер в админке: «не ниже X% маржи на категорию», «реакция на конкурента в пределах ±Y%», «минимальная цена не ниже Z». Раз в час система пересчитывает оптимальные цены по правилам и публикует.

Парсер цен конкурентов через прокси (без блокировок) — данные за сутки в ClickHouse, сравнение по SKU.

Аналитика юнит-экономики в реальном времени

Каждая продажа разлагается на: цена → комиссия маркетплейса → логистика → возвраты → стоимость SKU = чистая прибыль. Это пишется в ClickHouse, дашборды в Grafana / собственный кабинет на Recharts.

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

Telegram-бот для алертов

• Аномалии продаж (резкий рост или падение по SKU).
• Низкие остатки (с прогнозом, на сколько хватит при текущей скорости продаж).
• Изменения цен у конкурентов.
• Проблемы с API маркетплейсов.

Алерты идут в групповой чат отдела, не в почту, — реакция в течение часа, не дня.

Архитектурный нюанс

Самое сложное — разные семантики «остатка» на разных площадках. Где-то остаток включает резерв, где-то нет. Где-то возвраты автоматически возвращаются в остаток, где-то требуют ручной проверки. Решили через адаптеры на каждую площадку с явной типизацией: RawStock, ReservedStock, AvailableStock — и канонический остаток вычисляется по строгим правилам, не «как пришло».

Результаты

• −85% времени на операционку. С 35 часов в неделю на отдел до 5 часов — освободило 4 человеко-недель в месяц.
• −94% штрафов за овер-сейлы (с 320 тыс ₽/мес до 18 тыс ₽/мес).
• +12 п.п. маржинальность благодаря авто-переоценкам и выявлению убыточных SKU.
• Окупаемость — 4 месяца при бюджете 3.8 млн ₽.

Когда подходит

• Среднего размера бренд с продажами на 3+ маркетплейсах.
• Каталог 200+ SKU.
• Отдел e-com, который тонет в операционке.
• Готовность работать с числами, а не «делать как привыкли».