Подхват проекта — маркетплейсы
Разберём существующие обмены с маркетплейсами, восстановим контроль над заказами, остатками, ценами, карточками товаров и интеграциями с 1С, CRM или сайтом. Сначала аудит и карта рисков, затем стабилизация без хаотичных правок в продакшене.
Что мы понимаем под подхватом
Часто такое возникает, когда интеграция долго дорабатывалась кусками: первая выгрузка цен на одной площадке, потом обработчик заказов на второй, потом ручной cron для остатков, потом скрипт для карточек. Через год это работающее, но непрозрачное хозяйство, в котором нет одного владельца. Подхват — это собрать карту, найти источник правды и вернуть управляемость без переписывания всего сразу.
Разбор обменов с каждой площадкой: заказы, статусы, отмены, возвраты, остатки, цены, скидки, карточки товаров. Связки с 1С, CRM, сайтом и PIM. API, webhooks, очереди, регламентные задания и ручные выгрузки. Источники правды по товарам, ценам и остаткам. Письменный отчёт с приоритезированными рисками и план стабилизации. Дальше — поддержка или развитие по согласованной модели.
Новая интеграция с маркетплейсом с нуля без разбора текущих обменов. Разовая правка одной выгрузки без аудита и без ответственности за продажи. Работа без подтверждённых прав на кабинеты маркетплейсов, токены и обмены. Юридический спор с прошлым подрядчиком или с площадкой по конкретным заказам, штрафам или модерации — сначала профильные специалисты, потом технический аудит.
Когда нужен подхват
Если совпали два-три пункта — пора смотреть, что на самом деле происходит с обменами.
Команда, которая делала интеграцию, ушла или отвечает «через раз». Доработки откладываются, ошибки разбираются вручную.
Заказ с маркетплейса не доезжает до учётной системы или доезжает с задержкой. Операторы сверяют каналы вручную и переносят заказы из кабинета.
На сайте — одно, в 1С — другое, на Ozon — третье, на Wildberries — четвёртое. Покупатель оформляет заказ, которого по факту нет в наличии.
Цена в карточке не та, что в учётной системе. Промо-механики площадок применяются поверх неконсистентной выгрузки. Маржа считается уже постфактум.
Описание, фото и характеристики устарели. Изменения в учётной системе или PIM не доезжают до площадки. Часть карточек заблокирована модерацией без понятной причины.
Заказ собран и отгружен, в кабинете площадки или в CRM статус остался прежним. Уведомления покупателю и отчётность отдела продаж расходятся.
API-токены выпущены на личный аккаунт сотрудника подрядчика, регистрации приложений — тоже. Любая ротация ломает обмены, и непонятно, у кого восстанавливать доступ.
Часть обменов держится на регулярных выгрузках в Excel, локальных скриптах и cron-задачах на чьей-то машине. Если человек заболел, цепочка останавливается.
Что проверяем в первые дни
Сразу не лезем чинить. Сначала проходим по списку и фиксируем состояние, чтобы дальше работать с фактами, а не с предположениями.
С какими маркетплейсами есть интеграция, что и в какую сторону передаётся, какие сценарии живые, какие настроены, но не используются.
Как заказ из кабинета попадает в магазин и учётную систему, где меняются статусы, как обрабатываются отмены, возвраты и спорные ситуации.
Откуда берутся остатки, кто их пишет, как считается резерв, где расхождения с 1С, CRM и сайтом, кто имеет право править вручную.
Источник цен, правила выгрузки, разные тарифные планы и промо-механики площадок, обработка ошибок выгрузки.
Источник контента (PIM, 1С, сайт), правила публикации, история ошибок модерации, какие поля площадка считает обязательными.
Какие методы API используются, кто владелец токенов, как обрабатываются лимиты и ошибки, идемпотентны ли обработчики webhook.
Какие выгрузки запускаются по расписанию, где живут очереди задач, какие операции выполняются вручную в Excel и кем.
Какие сущности и в какую сторону ходят, где источник правды по товарам, ценам, остаткам и заказам, какие места рассинхронизируются первыми.
Первый месяц
Цель первого месяца — снять риски, которые влияют на активные продажи на площадках, и собрать понятную карту обменов, чтобы дальше работать предсказуемо.
Заказы, статусы, остатки, цены, карточки — кто источник правды, кто потребитель, какие обработчики и расписания участвуют. Это база для любых дальнейших решений.
Идемпотентность, ретраи, расхождение статусов между кабинетом площадки, магазином и CRM. На тестовом сегменте и копии данных проходим основные сценарии до выкатки на прод.
Передаём владение кабинетами на ваши учётные записи там, где это возможно. Описываем, какие токены и приложения куда подключены и кто их владелец по документам.
Один источник правды по остаткам, один по ценам, явные правила приоритета. Без этого любая правка в одной из систем продолжит ломать обмены.
Что запускается по cron, что лежит в очереди, что делается руками в Excel или в кабинете площадки. Цель — убрать «знание в голове одного человека».
Журналирование критичных операций (создание заказа, изменение статуса, выгрузка цен), алёрты на ошибки API и webhooks, мониторинг расхождений в ключевых отчётах.
Кто инициирует изменения в обменах, кто согласует, как тестируем на копии данных, как откатываемся. Простой и работающий регламент, а не стостраничный документ.
Чего не ломаем при переходе
Эти ограничения мы соблюдаем сами, чтобы переход был предсказуемым, а заказы и остатки не пострадали.
Любое изменение в обработке заказов и статусов сначала проходит на тестовом сегменте с проверенными сценариями оплаты, отмены и возврата. На прод выкатываем отдельным окном.
Массовая синхронизация по каталогу идёт по сценарию с бэкапом, репетицией на ограниченном сегменте и подготовленным rollback. Без этого восстановление становится отдельным инцидентом.
Перевыпуск токенов обрывает обработчики, которые от них зависят. Делаем это с заранее согласованным окном и обновлением всех потребителей.
Перевод источника правды между 1С, сайтом и кабинетом маркетплейса — это отдельное решение владельца процесса. В рамках срочной стабилизации мы такие переезды не делаем.
Часть ручных выгрузок и cron-задач прикрывает реальные дыры в обменах. Выключать их без понимания, что они на самом деле делают, — способ получить инцидент через сутки.
Стек и системы
Заходим в проекты с обменами, которые делают наши команды. Если вашей связки нет в списке — спросите, честно скажем, готовы ли подхватить или лучше начать с узкого аудита по конкретной площадке.
Ozon, Wildberries, Яндекс Маркет и другие маркетплейсы — без заявлений о партнёрстве.
1С: УТ, ERP, КА, Бухгалтерия, ЗУП — в части обмена товарами и заказами.
Bitrix24, amoCRM, кастомные CRM — лиды, сделки, статусы по заказам с площадок.
Bitrix, OpenCart, custom ecommerce, headless и каталоги в PIM.
Python, Node.js, PHP, Go; cron, Redis, RabbitMQ, Celery, BullMQ, RQ.
PostgreSQL, MySQL, XML, CSV, JSON, CommerceML-подобные обмены, REST API и webhooks.
Не выступаем как партнёр площадок и не обещаем привилегий со стороны Ozon, Wildberries или Яндекс Маркета. Работаем как технический подрядчик заказчика с теми API и кабинетами, которые есть на вашей стороне.
Частые проблемы
Это не «страшилки». Это набор паттернов, которые регулярно встречаются в обменах с маркетплейсами и которые становятся рисками при передаче.
Повторная доставка события создаёт второй заказ в учётной системе. Менеджеры обнаруживают дубль позже и объединяют вручную.
Заказ собран и отгружен, статус в кабинете площадки остался прежним. Покупатель и отдел продаж получают неполную картину.
Один обмен пишет остатки из 1С, второй — из сайта, третий — из ручной выгрузки в Excel. Победителем становится тот, кто записал последним.
Изменение в одном правиле приводит к выгрузке неверной цены на тысячи карточек. Откатиться можно только обратной выгрузкой, которая идёт часы.
Часть карточек попала под модерацию площадки и не публикуется. История ошибок и причин отказа разбросана между чатами поддержки и нигде не задокументирована.
API-токены и регистрации приложений выпущены на личную почту сотрудника прошлой команды. Ротация ломает обмены, восстановление — отдельный сюжет.
Обмены вызывают одни и те же эндпоинты по кругу, лимиты площадки заканчиваются, часть операций обрывается с 429.
Часть сценариев работает только потому, что оператор каждый день правит Excel и подгружает его в кабинет. Это держится на конкретном человеке.
Что запускается по cron, на каких серверах, в какое время и с какими аргументами — знает один разработчик. Если он недоступен, цепочка останавливается.
При инциденте по конкретному заказу понять, что с ним произошло, нельзя: события не связаны по order_id, часть действий вообще не логируется.
Чек-лист передачи доступов
Часть пунктов выглядит банально, но именно они задают скорость и точность аудита по площадкам.
Типы marketplace-сценариев
Если ваш случай — в списке ниже, опишите его в заявке. Обсуждаем по существу: что досталось, какие риски, с чего начнём.
API заказов, остатков, цен, карточек, FBO и FBS-сценарии.
Поставки, остатки, цены, акции, обработка заказов и возвратов.
Каталог, цены, заказы, доставка и связка с учётной системой.
Единые источники правды и согласованные правила выгрузки.
Двусторонний обмен по товарам, ценам, остаткам и заказам.
Лиды, сделки, статусы, претензии и возвраты в CRM.
Согласование цен, остатков и заказов между магазином и площадками.
Источник контента, ошибки модерации, обновление характеристик.
Перевод ручных Excel-выгрузок и cron в управляемый процесс.
Идемпотентные обработчики webhook, ретраи и контроль ошибок.
FAQ
С короткой стартовой сессии и заявки на аудит. Обсуждаем, с какими площадками работает интеграция, какие сценарии критичны (заказы, остатки, цены, карточки), какие связки с 1С, CRM и сайтом подключены, что произошло с прошлой командой, какие доступы и кабинеты уже на вашей стороне. По запросу подписываем NDA. Дальше — аудит API, webhooks, регламентных заданий, источников правды по остаткам и ценам, обработчиков статусов. Условия подхвата обсуждаем после отчёта.
Да, базовый аудит можно сделать на read-only-доступах к кабинетам площадок и журналам API: история запросов и ошибок, статусы заказов, выгрузки цен и остатков, события webhooks. Этого достаточно, чтобы построить карту потоков и список недостающих доступов. К коду обработчиков подключаемся, когда есть подтверждённые права на репозиторий. Если каких-то частей не видно даже на чтение, в отчёте отдельно фиксируем, какие выводы возможны без них, а какие — нет.
В первый месяц не меняем обработчики заказов и выгрузку цен без тестового сценария, не запускаем массовую пересинхронизацию остатков без бэкапа и плана отката, не перевыпускаем токены API без согласованного окна. Webhooks делаем идемпотентными — повторные события не должны создавать дубли заказов или второе списание остатков. Гарантию «ноль потерянных заказов» не даём — это нечестно, но всё, что зависит от подрядчика, делаем именно с этим приоритетом.
Действуем в рамках вашего права на аккаунты маркетплейсов и согласованного доступа. Сначала фиксируем, что и на чей аккаунт оформлено: кабинеты площадок, токены API, регистрации приложений, обработчики webhook. Параллельно вы как владелец компании восстанавливаете владение кабинетами через личные кабинеты площадок, где аккаунты оформлены на вас. Перевыпуск токенов идёт по согласованному плану с переключением обработчиков без потери данных. Кабинеты, оформленные не на вас, мы не «забираем» — это решается на стороне площадки и в рамках процедур владельца.
Заходим в проекты с интеграциями на эти и другие площадки. Не заявляем о статусе партнёра ни одной из них — работаем как технический подрядчик заказчика. На аудите смотрим то, что есть: API-обработчики, выгрузки, регламентные задания, обработку webhooks и связки с учётной системой. На стартовой сессии уточняем, с какими площадками работает интеграция и какой объём доработок сделан поверх типовых SDK или прямых вызовов API.
На аудите смотрим обе стороны обмена. Часто «маркетплейс теряет заказы» — это сломанный webhook, расхождение остатков на стороне 1С, неконсистентный контракт с CRM или потерянные ретраи во внешней очереди. В отчёте отделяем часть, которая живёт на стороне маркетплейса, от смежных систем и предлагаем план по каждой. По 1С и CRM есть отдельные страницы кластера — подхват 1С-проекта и подхват CRM-системы. При необходимости подхватим и смежные части отдельным форматом.
Да, если у выбранной площадки есть чёткие границы ответственности и понятный владелец процесса. Аудит в этом случае фокусируется на одной интеграции — Ozon, Wildberries или другой — но обязательно описывает контракт с общими сущностями (товары, цены, остатки, заказы) и риски на стыках с остальными площадками. Без понимания этих стыков подхват одной площадки быстро ломает соседнюю.
На аудите фиксируем масштаб расхождения и причины: повторные выгрузки, отсутствие правил приоритета, параллельные источники правды, ручные правки в кабинете в обход обмена. Дальше — план дедупликации и приведения к одному источнику правды: правила синхронизации, очерёдность по сущностям, тест на ограниченном сегменте каталога. Массовую пересинхронизацию без бэкапа и плана отката не запускаем — это типично делает хуже.
По итогам подхвата готовим чек-лист для внутреннего менеджера: репозитории обработчиков и регламентных заданий, схема потоков по каждой площадке, токены и кабинеты с владельцами по документам, источники правды по остаткам и ценам, регламент изменений, журнал ошибок и ретраев. Документируем ручные Excel-выгрузки и cron-задания, чтобы они перестали быть «знанием в голове одного человека». Можем сопровождать первые недели его работы.
Новая интеграция — это сборка обменов с нуля под текущие задачи бизнеса. Подхват — это работа с существующей интеграцией, у которой уже есть заказы, остатки, история выгрузок и связки с 1С и CRM, и которую нельзя «остановить и переделать». Решения в подхвате принимаются с учётом текущего состояния и рисков для активных продаж. Полный rewrite интеграции по умолчанию не предлагаем — почти всегда дешевле стабилизировать и точечно переписать проблемные модули.
Шире маркетплейсов
Если нужно забрать не только обмены с маркетплейсами, но и сам магазин, 1С, CRM, backend или срочно стабилизировать продажи — начните с общей страницы подхвата проекта.
Если уже понятно, в какой смежной части горит, у нас есть отдельные страницы про подхват интернет-магазина, подхват интеграций и API, подхват 1С-проекта, подхват CRM-системы, подхват Python-проекта, срочный подхват проекта и аудит перед подхватом.
Заказать аудит интеграций
Опишите площадки, объём обменов, связки с 1С и CRM, доступы и что произошло с предыдущей командой. Вернёмся с конкретикой и предложим стартовую сессию.
Подхват интеграций с маркетплейсами
Поля помечены под подхват marketplace-интеграций: какие площадки, какие ключевые сценарии и связки, какие доступы уже на вашей стороне.
Заявка придёт на hi@khaiam.ru. Можно написать сразу в Telegram .
Заявка отправлена
Если задача срочная, можно сразу написать в Telegram .