bitrixИнтеграция Битрикс24 с Wildberries и Ozon: кейс селлера
Задача
К нам обратился продавец маркетплейсов с оборотом около 60 млн ₽ в месяц, которому потребовалась интеграция Битрикс24 с Wildberries — этот кейс типичен для селлеров, выросших быстрее своих процессов. Компания продавала товары домашнего текстиля на трёх площадках: Wildberries, Ozon и Яндекс Маркет, по моделям FBO и FBS одновременно. Штат — 14 человек: руководитель, 4 менеджера по заказам, 2 контент-менеджера, закупщик, логист и бухгалтерия на аутсорсе. Главная боль — заказы велись в Excel. Каждое утро менеджер вручную выгружал заказы из трёх личных кабинетов, сводил в общую таблицу, разносил по складам и передавал логисту. На это уходило 3–4 часа в день, а к вечеру данные уже устаревали: на WB появлялись новые сборочные задания, на Ozon — отмены. Из-за рассинхрона случались отгрузки несуществующих остатков, штрафы за срыв сборки FBS и потеря позиций в выдаче. Вторая проблема — отзывы и вопросы покупателей. На трёх площадках копилось по 30–50 отзывов в день, на негативные отвечали с задержкой в 2–3 дня или не отвечали вообще. Рейтинг карточек проседал, а руководитель узнавал о жалобах на брак постфактум. Третья боль — экономика. Комиссии, логистика, хранение и штрафы площадок считались «на глаз» раз в месяц. Руководитель не мог ответить на вопрос, какие из 300 SKU реально зарабатывают, а какие торгуют в минус после вычета всех комиссий. Отдельно страдала закупка: без актуальных остатков и скорости продаж по каждой площадке закупщик пополнял товар по интуиции — одни позиции замораживали деньги на складе, по другим регулярно случался out-of-stock в пик спроса. Клиент уже пробовал готовые коннекторы из Маркетплейса Битрикс24, но они покрывали только выгрузку заказов одной площадки и не умели ни статусы, ни остатки, ни юнит-экономику. Требовалось решение, которое соберёт все три площадки в единый контур: заказы и сборочные задания — в сделки, статусы и остатки — двусторонне, отзывы и вопросы — в CRM с автоназначением ответственного, а финансовая аналитика по каждой площадке и SKU — в дашборды. Сроки были критичны: до начала высокого сезона оставалось 4 месяца.
Решение
Мы развернули коробочную версию Битрикс24 на сервере клиента и построили интеграционный слой на собственном микросервисе (PHP 8.2, Laravel) между площадками и порталом. Архитектура — событийная: все API маркетплейсов опрашиваются по расписанию и через вебхуки, события попадают в очередь RabbitMQ и обрабатываются воркерами. Первый поток — заказы. Сервис каждые 3 минуты забирает новые заказы и сборочные задания через официальные API: WB Statistics/Orders API, Ozon Seller API (postings FBO/FBS), Яндекс Маркет Partner API. Для каждого заказа через REST API Битрикс24 создаётся сделка в воронке «Маркетплейсы» с привязкой к товару каталога CRM. В сделку пишутся артикул, SKU, цена до и после СПП, комиссия площадки, склад отгрузки, дедлайн сборки и тип — FBO или FBS. Стадии сделки зеркалят статусы заказа на площадке: новый → на сборке → в доставке → завершён / отменён / возврат. Смена статуса на площадке через API автоматически двигает сделку роботами, а движение сделки менеджером по FBS-заказам, наоборот, подтверждает сборку через API Ozon и WB — двусторонняя синхронизация. Второй поток — остатки. Каталог товаров ведётся в Битрикс24 как мастер-система: раз в 15 минут сервис сверяет остатки в CRM с остатками на площадках и корректирует их через API Stocks. При продаже на одной площадке остаток уменьшается на всех трёх — расхождений и отгрузок «в ноль» больше нет. Третий поток — отзывы и вопросы. API отзывов WB, Ozon и Маркета опрашиваются каждые 10 минут. Каждый отзыв создаёт задачу в Битрикс24 с текстом, оценкой, ссылкой на товар и сделку. Роботы назначают ответственного: оценка 4–5 — контент-менеджеру для благодарности, 1–3 — старшему менеджеру с крайним сроком 4 часа. Ответ менеджер пишет прямо в задаче, сервис публикует его через API от имени продавца. Жалобы на брак автоматически создают элемент смарт-процесса «Претензии» для закупщика. Четвёртый блок — юнит-экономика. Сервис ночью выгружает детализированные финансовые отчёты площадок (реализации, комиссии, логистика, хранение, штрафы, реклама) и раскладывает их по сделкам и SKU. На базе смарт-процесса «Аналитика площадок» собраны дашборды Битрикс24: маржа по каждому SKU и площадке, доля выкупа, стоимость возвратов, ABC-анализ. Руководитель видит прибыль по каждой карточке за вчерашний день, а не раз в месяц. Внедрение шло поэтапно: месяц — заказы WB, затем Ozon и Маркет, далее остатки, отзывы и аналитика. Обучили 14 сотрудников за три двухчасовые сессии, написали регламенты. Полный переход с Excel занял 6 недель без остановки продаж.
Архитектура
Архитектура решения — трёхслойная, с интеграционным слоем между маркетплейсами и коробочным Битрикс24. Слой источников: официальные API Wildberries, Ozon и Яндекс Маркета. Получение данных — гибридное: вебхуки площадок (где доступны) плюс опрос по расписанию через cron-воркеры с интервалами 3–15 минут в зависимости от лимитов API. Для каждой площадки — отдельный коннектор с адаптером под её модель данных: заказы WB, postings Ozon и заказы Маркета приводятся к единому внутреннему формату события. Интеграционный слой — микросервис на PHP 8.2 (Laravel) в Docker. Все входящие события складываются в очередь RabbitMQ с подтверждением доставки; воркеры-консьюмеры обрабатывают их идемпотентно, поэтому повторная доставка события не создаёт дублей. Лимиты API площадок контролируются токен-бакетом в Redis: при приближении к лимиту запросы притормаживаются, а не отклоняются. Необработанные события уходят в dead-letter queue с алертом дежурному. Связь с Битрикс24 — через REST API коробки: создание и движение сделок, элементы смарт-процессов, задачи, товары каталога. Обратный поток (подтверждение сборки, ответы на отзывы, корректировка остатков) инициируется исходящими вебхуками Битрикс24 и событиями портала, которые тот же сервис транслирует в API площадок. Исходящие вызовы также проходят через очередь — при недоступности площадки операции не теряются, а ретраятся с экспоненциальной задержкой. Отказоустойчивость: сервис и очередь развёрнуты в двух контейнерах на отдельном сервере клиента, БД MySQL с репликой, Redis для кэша токенов и блокировок. Ежедневные бэкапы конфигурации и базы. Мониторинг — Grafana + Prometheus: лаг очередей, число необработанных событий, ошибки API площадок, расхождение остатков сверяется контрольным джобом каждый час; при превышении порогов алерты уходят в Telegram администратору и нашей команде поддержки.
Стек
Битрикс24 Коробка, WB API, Ozon Seller API, Яндекс Маркет Partner API, PHP 8.2, Laravel, RabbitMQ, MySQL 8, Redis, Docker, Grafana + Prometheus
Результат
Проект занял 4 месяца и окупился за первые два сезонных месяца. Главный эффект — освобождение менеджеров: 3–4 часа ручной сводки заказов в день ушли полностью, четыре менеджера переведены с операционной рутины на развитие карточек и работу с ассортиментом. Это эквивалентно экономии примерно 1,5 ставки, или около 1 млн ₽ в год фонда оплаты труда. Штрафы площадок за срыв сроков сборки FBS и отмены по вине продавца сократились на 90%: с 180–220 тыс. ₽ до 15–25 тыс. ₽ в месяц. Двусторонняя синхронизация остатков убрала отгрузки несуществующего товара — процент отмен по причине «нет на складе» упал с 4,1% до 0,3%, что напрямую подняло позиции карточек в поисковой выдаче. Работа с отзывами изменилась качественно: среднее время ответа сократилось с 2–3 дней до 3 часов, доля отзывов с ответом выросла с 35% до 98%. За сезон средний рейтинг карточек поднялся с 4,4 до 4,7, а конверсия в заказ по топ-20 SKU выросла на 12%. Юнит-экономика дала самый дорогой инсайт: 47 из 300 SKU торговали в минус после всех комиссий и логистики. Их вывели из ассортимента или переписали условия — месячная маржинальная прибыль выросла на 1,9 млн ₽ без роста оборота. Закупщик получил план пополнения по скорости продаж: замороженный в неликвиде остаток сократился на 8 млн ₽, а потери продаж из-за out-of-stock в пик — на треть. За 8 месяцев после запуска оборот вырос с 60 до 74 млн ₽ в месяц при том же штате. Клиент продлил с нами SLA-поддержку и готовит следующий этап — автоматическое ценообразование по правилам через API площадок.
«Раньше утро начиналось с трёх личных кабинетов и Excel на два часа. Сейчас все заказы трёх площадок — в одной воронке, а штрафы мы почти перестали платить. Отдельная победа — юнит-экономика: выяснилось, что 47 позиций торговали в минус, и мы этого просто не видели.»
Расскажите о задаче — предложим архитектурное решение
Бесплатный предварительный аудит за 3 рабочих дня: анализ задачи, вариант архитектуры, оценка сроков и бюджета. NDA при необходимости.
- Общение — с техническим архитектором, не с менеджером
- Фиксированная цена после технического аудита
- Гарантия на разработку по договору