Связать магазин с Wildberries, Ozon, Яндекс Маркетом и Мегамаркетом можно тремя способами: вести кабинеты руками, поставить модуль вроде 1С:Маркетплейс, подключить сервис-агрегатор или заказать собственную интеграцию по API площадок. Первый способ бесплатен по счёту и стоит 82 часа работы менеджера в месяц при трёх кабинетах и 600 позициях. Второй и третий стоят 60 000–150 000 ₽ на подключение и 8 000–25 000 ₽ в месяц. Четвёртый — 350 000–550 000 ₽ и оправдан далеко не всем.
Но выбор способа — не главное решение. Главное решается раньше и почти всегда молча: чей остаток считать правдой. У магазина один физический склад, а витрин четыре, и каждая из них после публикации карточки ведёт себя так, будто товар зарезервирован именно за ней. Пока позиций много и остатки глубокие, это незаметно. Как только ходовая позиция уходит в единицы, три площадки продают одну и ту же коробку, две покупателя получают отмену, а продавец — снижение рейтинга и ограничения в акциях.
Дальше по порядку: три схемы работы с ценой, сроком и потолком каждой; что именно синхронизируется и чем площадки различаются между собой; механика единого остатка с резервами и порогом; лимиты на обновление цен и остатков; один источник карточки вместо четырёх; расчёт ручного контура на 600 позициях и смета связки. В конце — честный раздел о том, когда интеграция с площадками не нужна вовсе, и карта раздела журнала.
Три схемы работы и потолок каждой
Схемы различаются не «продвинутостью», а тем, где живёт логика распределения остатка и кто чинит поломку в субботу. В первой логика живёт в голове менеджера, во второй — в модуле вендора, в третьей — в сервисе, в четвёртой — у вашего подрядчика. От этого зависит и цена владения, и то, насколько быстро вы упрётесь в потолок.
| Схема | Что это на практике | Цена | Срок запуска | Где потолок |
|---|---|---|---|---|
| Руками в кабинетах | Менеджер открывает три-четыре личных кабинета, грузит файлы остатков, правит цены, переносит заказы в учёт вручную | 0 ₽ по счёту, 82 часа менеджера в месяц | Уже работает | Две площадки и 300–400 позиций. Дальше растёт не работа, а число ошибок |
| Модуль 1С:Маркетплейс | Отдельная конфигурация или модуль рядом с учётной системой: справочник площадок, обмен номенклатурой, остатками, заказами | Лицензия плюс 60 000–150 000 ₽ на настройку и сопоставление | 2–4 недели | Нетиповые схемы резервирования, несколько юрлиц, редкие площадки |
| Сервис-агрегатор | Внешний сервис забирает данные из учёта и раскладывает по кабинетам; поддержка форматов площадок — на стороне сервиса | 60 000–120 000 ₽ подключение, 8 000–25 000 ₽/мес | 2–3 недели | Своя логика распределения остатка, обмен чаще, чем позволяет тариф, нетиповые поля карточки |
| Заказная интеграция по API | Собственный слой между учётом и площадками: своя логика остатка, свои правила, свой мониторинг | 350 000–550 000 ₽ плюс 25 000–45 000 ₽/мес поддержки | 6–8 недель | Потолка нет, но есть цена владения — каждое изменение API площадки чинится за ваш счёт |
Практическое правило выбора звучит непопулярно для подрядчика, но экономит заказчику сотни тысяч рублей. Заказную интеграцию имеет смысл заказывать не потому, что «у нас много товара», а потому, что готовые решения физически не умеют делать то, что вам нужно. Признаков четыре: несколько юрлиц или складов с разными приоритетами отгрузки, доработанная конфигурация 1С, в которой доступный остаток считается по своей формуле, собственные схемы резервирования под опт и розницу одновременно, ассортимент от нескольких тысяч позиций с ежедневной переоценкой. Если ни один признак не выполняется — вы платите за то, что уже продаётся как подписка.
Второй вопрос, который решается до выбора схемы, — где физически живёт источник истины. Вариантов на российском рынке три. Первый: учётная система семейства 1С — УНФ, УТ или Розница; тогда остаток, цены и заказы принадлежат ей, а всё остальное — надстройка. Второй: МойСклад, который изначально сделан под торговый контур и часто оказывается достаточным для магазина без сложного производственного учёта. Третий: отдельный слой обработки заказов — например, RetailCRM, — который принимает заказы из всех каналов, ведёт их до отгрузки и отдаёт в бухгалтерию уже готовые документы. Третий вариант привлекателен тем, что снимает нагрузку с 1С и даёт менеджеру одно окно, но добавляет в цепочку ещё одну систему и ещё один стык, а значит, и ещё одно место, где заказ может застрять. Выбирать надо не по популярности, а по тому, где у вас уже ведётся складской остаток: источник истины по остатку и место обработки заказов должны совпадать либо быть связаны обменом, который вы готовы обслуживать.
Сравнительная таблица-схема из четырёх колонок: «Руками в кабинетах» (0 ₽, 82 ч менеджера в месяц), «Модуль 1С:Маркетплейс» (60 000–150 000 ₽, 2–4 недели), «Сервис-агрегатор» (60 000–120 000 ₽ плюс 8 000–25 000 ₽/мес, 2–3 недели), «Заказная интеграция» (350 000–550 000 ₽, 6–8 недель). В каждой колонке три строки: цена, срок, потолок. Нижняя строка выделена рамкой и подписана «где вы упрётесь». Чертёжная манера, подписи по-русски.
Что синхронизируется и чем площадки различаются
Слово «интеграция» скрывает пять независимых контуров, у каждого своя частота, своя цена и свои условия приёмки. Заказывать «подключение к Ozon» без перечисления контуров — верный способ получить один из пяти и счёт на доплату за остальные четыре.
- Карточки: номенклатура, категория площадки, характеристики, фотографии, штрихкоды. Направление одно — из вашего источника на площадку.
- Остатки: доступное к продаже количество по каждому складу и каждой схеме работы. Из учёта на площадку, чаще всего каждые 10–30 минут.
- Цены: базовая цена и цена со скидкой продавца. Из учёта на площадку, обычно 1–4 раза в сутки.
- Заказы и сборочные задания: новые заказы с площадки в учёт, обратно — подтверждение сборки, отгрузка, номера отправлений и ярлыки.
- Возвраты и отчёты: возвраты покупателей, отчёты о реализации и удержаниях площадки — в учёт, для сверки и себестоимости.
Различия между площадками начинаются не в API, а в моделях работы. Один и тот же товар может лежать на складе площадки, на вашем складе с доставкой площадки или на вашем складе с вашей же доставкой — и это три разных остатка, которые нельзя складывать. Ниже — сводка по четырём площадкам, актуальная по состоянию на сентябрь 2026 года; названия схем и состав отчётов площадки меняют регулярно, поэтому таблицу нужно перепроверять перед стартом работ, а не наследовать из статьи.
| Площадка | Схемы работы | Что приезжает обратно в учёт | Что осложняет обмен |
|---|---|---|---|
| Wildberries | Со склада площадки, со своего склада с доставкой площадки, со своего склада со своей доставкой | Заказы и сборочные задания, отгрузки, возвраты, отчёт о реализации | Остаток на складах площадки ведётся отдельно от вашего и не управляется выгрузкой — им управляют поставки |
| Ozon | FBO, FBS, realFBS, экспресс-доставка | Отправления по каждой схеме, статусы, возвраты, начисления и удержания | Одна и та же позиция может продаваться сразу по двум схемам — остаток надо разделять, а не дублировать |
| Яндекс Маркет | FBY, FBS, DBS, экспресс | Заказы по кампаниям, статусы, возвраты, отчёты | Кампания — отдельная сущность: у одного продавца их несколько, и остаток задаётся в разрезе кампании и склада |
| Мегамаркет | Фулфилмент площадки, доставка площадки со склада продавца, доставка продавца, самовывоз из точки продавца | Заказы, статусы сборки и отгрузки, возвраты | Меньше готовых коннекторов, чем у первых трёх, — чаще требуется своя прослойка или фид |
Позиции, отгруженные на склад маркетплейса, физически у вас отсутствуют, и выгружать их в остаток нельзя ни на эту площадку, ни тем более на другие. Управлять этим количеством можно только поставками, а видеть — в отчётах площадки. В учётной системе такой остаток обычно ведут отдельным складом «товары на площадке», и это первое, что стоит завести до начала любой интеграции: без него сводный остаток врёт с первого дня.
Карта связей. Слева узел «Учёт: 1С УНФ или УТ, МойСклад». В центре широкий блок «Слой обмена: единый остаток, единый источник карточек, очередь заказов». Справа четыре узла: Wildberries, Ozon, Яндекс Маркет, Мегамаркет. Стрелки от центра вправо подписаны: «карточки», «остатки — каждые 10–30 минут», «цены — 1–4 раза в сутки». Стрелки справа налево: «заказы и сборочные задания», «возвраты и отчёты». Внизу отдельным узлом «Склад товаров на площадке — ведётся поставками, не выгрузкой». Чертёжная манера, подписи по-русски.
Единый остаток: три модели распределения
Это ядро всей интеграции. Пока источник остатка один и он честно уменьшается на всё, что уже обещано покупателям, остальное — техника. Как только источников становится два, начинаются отмены, и никакая частота обмена их не лечит.
Количество, которое можно обещать покупателю прямо сейчас. Считается как физический остаток на складе минус резерв под неотгруженные заказы всех каналов сразу — сайта, площадок, розницы и опта, — минус страховой буфер под пересортицу и брак. Товар, лежащий на складе маркетплейса, в эту формулу не входит вообще: он учитывается отдельным складом и продаётся только через ту площадку, где физически лежит.
Дальше единый остаток надо разделить между площадками, и здесь выбор из трёх моделей. Разница между ними видна только на позициях с малым остатком — но именно эти позиции обычно и есть ходовые.
| Модель | Как работает | Что получаете | Чем платите |
|---|---|---|---|
| Общий пул | Всем площадкам показывается один и тот же доступный остаток | Максимум продаж: ни одна витрина не занижает наличие | Отмены на позициях с остатком 1–3 штуки, когда две площадки продают одну коробку |
| Жёсткие квоты | Каждой площадке выделена своя доля остатка, пересечений нет | Отмен почти нет, план поставок предсказуем | Ходовая позиция не продаётся: на одной витрине очередь, на другой лежит невостребованная квота |
| Пул с порогом | Выше порога — общий пул, ниже — позиция остаётся только на приоритетной площадке | Рабочий компромисс: глубокий остаток продаётся везде, дефицитный не обещается дважды | Нужно задать приоритет площадок и пересматривать порог раз в квартал |
Разберём на позиции с остатком 12 штук и порогом 6. Пока доступный остаток 12, все четыре витрины показывают 12 — товара хватит на любую комбинацию заказов ближайшего часа. Как только заказы съедают его до 5, срабатывает порог: позиция остаётся в продаже только на приоритетной площадке, на остальных остаток выставляется в ноль. Покупатель не видит ничего необычного, а вы не получаете четыре обещания на пять коробок. Порог подбирается не из головы, а по фактическому темпу продаж позиции за час пиковой нагрузки: если ходовая позиция уходит по три штуки в час, порог ниже 6 бессмыслен.
Прямая потеря от отмены — маржа одного заказа. Косвенная гораздо дороже: площадки учитывают отмены по вине продавца в рейтинге, а рейтинг влияет на позицию в выдаче, доступ к акциям и условия работы. Конкретные меры и их размер у каждой площадки свои, прописаны в оферте и меняются несколько раз в год. Практический вывод один: считать модель распределения остатка надо до запуска продаж, а не после первого письма от площадки.
Схема в две зоны. Сверху формула блоками: «Физический остаток» минус «Резерв под неотгруженные заказы всех каналов» минус «Страховой буфер» равно «Доступный к продаже». Сбоку отдельный блок «Товар на складе площадки — в формулу не входит». Снизу три ветки распределения от блока «Доступный к продаже = 12 шт»: «Общий пул — 12/12/12/12, риск отмен», «Квоты — 3/3/3/3, товар не продаётся», «Пул с порогом 6 — выше порога всем, ниже только приоритетной». Третья ветка выделена как рабочая. Чертёжная манера, подписи по-русски.
Лимиты и частота: чем чаще, тем не всегда лучше
Первое желание после запуска обмена — обновлять остатки как можно чаще. Площадки этого не позволяют: у каждого метода API есть ограничение на число запросов и на размер пакета, и превышение наказывается не ошибкой на экране, а тихой деградацией. Запросы начинают отклоняться, пакет уходит в отложенную обработку, часть позиций приезжает через полчаса. Внешне обмен идёт, счётчик успешных сессий растёт, а витрина показывает вчерашнее.
Точные значения лимитов у площадок разные, различаются по методам и меняются несколько раз в год, поэтому брать их из статьи нельзя — только из документации на момент работ. Что действительно стоит зафиксировать в проекте, так это инженерные правила, которые от конкретных цифр не зависят.
- 1Обновлять пакетами, а не по одной позиции. Один запрос на 100–1000 позиций вместо тысячи запросов по одной — это не оптимизация, а единственный способ уложиться в лимит на сколько-нибудь заметном каталоге.
- 2Возить только изменившееся. За 15 минут в каталоге из 600 позиций меняется 20–40, и гнать остальные 560 бессмысленно: они съедают лимит, который понадобится в час пик.
- 3Разделить темп остатков и темп цен. Остаток критичен по минутам, цена — по часам. Смешивать их в одном задании нельзя: переоценка каталога один раз выест дневной лимит и остановит обновление остатков на полдня.
- 4Обрабатывать ответ об ограничении как штатную ситуацию. Пакет, отклонённый по лимиту, встаёт в очередь и повторяется с нарастающей паузой, а не теряется. Отсутствие такой очереди — самая частая причина, по которой обмен «вроде работает», а данные расходятся.
- 5Считать не сессии, а строки. В журнале должно быть видно, сколько позиций реально принято площадкой за сессию. Успешная сессия, доставившая 40 позиций из 600, — это провал, который без такого счётчика выглядит как успех.
Разумный ориентир для магазина среднего размера: остатки — раз в 10–30 минут по изменившимся позициям, цены — 1–4 раза в сутки, заказы — по расписанию раз в 2–5 минут или по уведомлению площадки, если она его присылает. Опрашивать площадку в цикле без пауз не нужно никогда: это гарантированный способ упереться в лимит и потерять именно тот обмен, который был важен. Механика самих обменов со стороны учётной системы — регламентные задания, HTTP-сервисы, планы обмена — разобрана в разделе об интеграциях 1С; здесь важно только то, что расписание площадок диктуется их лимитами, а не вашими желаниями.
Карточка товара: один источник, четыре формата
Самая незаметная утечка времени — ведение карточек отдельно в каждом кабинете. Она не выглядит проблемой: менеджер просто заполняет поля, площадка за площадкой. Но у каждой площадки своя категория, свой набор обязательных характеристик и свои требования к фотографиям, поэтому одна и та же вещь описывается четыре раза и четырьмя разными людьми в разное время. Через полгода состав ткани на одной витрине не совпадает с составом на другой, а на третьей потерялся размерный ряд.
Рабочая схема одна: характеристики живут в одном месте — в учётной системе или в отдельном справочнике товарных данных, — а в кабинеты уезжают выгрузкой с пересчётом в формат площадки. Правка делается один раз в источнике и разъезжается по всем витринам сразу. При 600 позициях, трёх площадках и 25 новых или изменённых карточках в месяц это снимает около 11 часов ручной работы ежемесячно и, что важнее, убирает саму возможность расхождения между витринами.
- 1Шаг 1. Собрать поля в одном справочнике
Все характеристики, которые вообще участвуют в карточках: габариты, состав, цвет, размерный ряд, комплектация, штрихкоды, фотографии. Не «те, что нужны Ozon», а объединение требований всех площадок плюс собственного сайта.
- 2Шаг 2. Сопоставить категории
Каждая ваша товарная группа привязывается к категории на каждой площадке, а каждое поле — к атрибуту этой категории. Это ручная работа один раз и самая скучная часть проекта: на 600 позициях она занимает 8–14 часов.
- 3Шаг 3. Настроить выгрузку в форматы площадок
Из одного источника собираются четыре разных представления. Обязательные поля, которых у вас нет, всплывают именно здесь — и это хорошая новость: лучше узнать о них на этапе настройки, чем при модерации карточки.
- 4Шаг 4. Закрыть ручное редактирование в кабинетах
Пока карточку можно поправить прямо на площадке, схема не работает: правка живёт до первой выгрузки, а потом исчезает, и менеджер перестаёт доверять системе. Либо поле ведётся в источнике, либо оно исключено из выгрузки — третьего состояния быть не должно.
Отдельный вопрос — тексты описаний. Их можно готовить конвейером с подстановкой характеристик из базы, и это заметно дешевле ручного написания, но у конвейера есть жёсткое правило: модель пишет текст вокруг фактов из учёта, а не придумывает факты. Хронометраж работы редактора и расчёт экономии на большом каталоге мы разбирали в отдельной статье, а состав и цену такого конвейера — на странице решения по генерации карточек товаров.
Схема-веер. Слева один блок «Источник характеристик: 600 позиций, габариты, состав, размерный ряд, штрихкоды, фото». От него четыре стрелки вправо к блокам «Формат Wildberries», «Формат Ozon», «Формат Яндекс Маркета», «Формат Мегамаркета», на каждой стрелке подпись «сопоставление категорий и атрибутов». Справа от блоков — общая скобка с подписью «правка одна, выгрузок четыре; 11 часов в месяц при трёх площадках». Внизу перечёркнутая ветка «редактирование прямо в кабинете» с подписью «живёт до первой выгрузки». Чертёжная манера, подписи по-русски.
Сколько стоит ручное ведение трёх кабинетов
Модельный магазин: 600 активных позиций, три площадки, 900 заказов в месяц, средний чек 2 900 ₽, валовая маржа после комиссии площадки и логистики — 26 %, то есть 754 ₽ с заказа. Работает один менеджер маркетплейсов; полная стоимость его часа с учётом взносов — 700 ₽. Считаем по операциям, чтобы цифру можно было пересчитать на своих объёмах.
Обратите внимание на структуру: почти треть времени уходит на одно только обновление остатков, и это самая механическая операция из всех. Заказы и карточки вместе дают ещё 29 часов. То есть три четверти нагрузки — ровно то, что автоматизируется без всякого искусственного интеллекта, обычным обменом данными.
Горизонтальная столбиковая диаграмма, шесть столбцов с подписями в часах за месяц: «Обновление остатков — 26,4», «Перенос заказов в учёт — 18», «Ведение карточек — 11,25», «Переоценка — 10», «Сборочные задания и отгрузки — 8,8», «Возвраты и сверка — 7,5». Итоговая подпись справа «82 часа = 57 400 ₽ при ставке 700 ₽/час». Отдельной плашкой ниже: «плюс 24 128 ₽ потерянной маржи от 32 отмен». Ось подписана в часах, все значения проставлены. Чертёжная манера, подписи по-русски.
Что даёт автоматизация и когда она не окупается
Для магазина такого размера правильный ответ — не заказная разработка. Сервис-агрегатор или модуль закрывают все пять контуров, стоят подписки и подключаются за две-три недели. Считаем тот же месяц после подключения.
Теперь то же самое, но заказной интеграцией. Смета честная, по 3 000 ₽ за час работы инженера, и она нужна не для того, чтобы её продать, а для того, чтобы сравнить.
Сравнение простое. Заказная интеграция снимает ту же ручную работу, но платить за неё приходится не подпиской, а поддержкой. При среднем значении поддержки 35 000 ₽ в месяц ежемесячные расходы после запуска получаются 14 000 ₽ остаточной ручной работы плюс 35 000 ₽ поддержки плюс 8 294 ₽ маржи, потерянной на оставшихся отменах, — 57 294 ₽ против 81 528 ₽ до автоматизации. Экономия 24 234 ₽ в месяц, и 432 000 ₽ вложений возвращаются почти полтора года: 432 000 ÷ 24 234 = 17,8 месяца. Для магазина на 600 позициях это неверное решение, и мы говорим об этом на первом созвоне. Заказная связка становится оправданной, когда готовые решения не справляются по существу: несколько юрлиц с разными договорами на площадках, три и более склада с приоритетом отгрузки, доработанная конфигурация 1С со своей формулой доступного остатка, ассортимент от нескольких тысяч позиций. Тогда сравнивать надо уже не с агрегатором, а с невозможностью работать вообще.
Заказы, отгрузки и возвраты: три отдельных контура
Заказы с площадок ведут себя не так, как заказы с собственного сайта, и это регулярно ломает проекты, где контур площадок делали по образцу сайта. Три отличия существенны.
- Заказ уже оплачен или гарантирован площадкой. Вы не подтверждаете оплату, вы подтверждаете сборку — и часы на это ограничены правилами площадки. Опоздание превращается в отмену и штраф по оферте.
- Отгрузка идёт партиями и по расписанию площадки. В учёте это не «отгрузка заказа», а поставка со списком отправлений, ярлыками и коробами. Схема документооборота отличается от розничной отгрузки, и её надо описать до начала работ.
- Возврат приходит не от покупателя, а от площадки, часто через недели после продажи и отдельным потоком. Сверять его надо с отчётом площадки, а не с исходным заказом: покупатель мог вернуть одну позицию из трёх, а площадка — удержать комиссию по своей логике.
Из этого следует практическое правило порядка работ. Сначала запускают карточки и остатки — они безопасны и дают эффект сразу. Затем цены. Заказы подключают третьими, и обязательно с защитой от повторной обработки и очередью повторов: заказ создаёт в боевой базе документ, который пойдёт в отгрузку и в отчётность, и цена ошибки здесь на порядок выше, чем в остатках. Механику защиты от задвоений — ключ операции, отличие дубля от законного повторного заказа и процедуру разбора уже возникших дублей — мы разбирали отдельно; в контуре площадок она работает так же, только внешним номером служит идентификатор отправления, а не номер заказа сайта. Возвраты и сверку отчётов включают последними, когда остальное уже стабильно работает месяц.
Отчёты площадок стоит подключить даже тем, кто пока обходится ручным вводом заказов. Без них себестоимость продажи считается по прайсу, а не по факту, и магазин месяцами не видит, что комиссия, логистика и удержания съели маржу конкретной товарной группы. Как собрать девять отчётов, которые действительно нужны магазину, и почему без себестоимости и комиссий отчёт по выручке вводит в заблуждение — тема отдельной статьи раздела; в готовом виде это направление закрывает решение по BI-дашбордам.
Мониторинг: четыре датчика для контура площадок
Обмен с площадками ломается тише, чем обмен с сайтом, потому что витрину вы каждый день не смотрите. Типичная история: ключ доступа к одному из кабинетов перевыпустили при смене сотрудника, обмен по этой площадке встал, а заметили это через девять дней по провалу продаж. Четыре датчика ниже закрывают большинство таких сценариев и настраиваются за два-три дня.
| Датчик | Что именно проверяет | Какую поломку ловит |
|---|---|---|
| Отметка времени последнего успешного обмена по каждой площадке отдельно | Свежесть отметки: старше двух периодов обмена — алерт | Протухший ключ, отключённое задание, упавший сервис — по одной площадке из четырёх |
| Счётчик принятых строк | Сколько позиций площадка реально приняла за сессию против отправленных | Тихий отказ по лимиту: сессия успешна, доехало 40 позиций из 600 |
| Суточная сверка остатков | Список «артикул — доступный остаток» из учёта против выгруженного в каждый кабинет, порог расхождений 1 % | Обмен идёт, но возит неправду: не учтены резервы, выпал склад, потерялась часть номенклатуры |
| Счётчик отмен по причине «нет в наличии» | Доля таких отмен за сутки против обычной; превышение вдвое — алерт | Встал канал остатков или сломалась модель распределения — раньше, чем это увидит площадка |
Два требования к мониторингу, без которых он превращается в декорацию. Первое: сторож должен жить снаружи обмена, иначе он падает вместе с ним и молчит. Второе: получателей алерта минимум двое, и один из них — со стороны магазина, тот, кто может остановить продажи по проблемной группе. Проверяется это на приёмке ровно одним действием: искусственно останавливаем обмен по одной площадке на сорок минут и убеждаемся, что письмо пришло обоим.
Схема: горизонтальная линия «обмен с площадками» и четыре датчика-отвода над ней с подписями: «Отметка времени по каждой площадке — старше двух периодов», «Счётчик принятых строк — 40 из 600», «Суточная сверка остатков — порог 1 %», «Счётчик отмен «нет в наличии» — рост вдвое». Под каждым датчиком мелкая подпись, какую поломку он ловит. Справа блок «Алерт: инженер + ответственный со стороны магазина». Отдельная пометка «сторож снаружи обмена». Чертёжная манера, подписи по-русски.
Когда интеграция с площадками не нужна
Есть четыре ситуации, в которых мы сами советуем не начинать проект, и лучше узнать о них до подписания договора.
- Одна площадка и меньше 150 заказов в месяц. Ручное ведение одного кабинета — это 12–18 часов в месяц, то есть 8 400–12 600 ₽. Подключение и подписка съедят экономию целиком. Возвращаться к вопросу стоит на второй площадке или при выходе за 300 заказов.
- Товар только на складе площадки. Если весь ассортимент отгружается на фулфилмент маркетплейса, выгружать остатки некуда: ими управляют поставки, а не обмен. Автоматизировать здесь имеет смысл планирование поставок и сверку отчётов, а не синхронизацию остатка.
- Ассортимент из 30–50 позиций с глубоким остатком. Модель распределения не нужна: товара хватает всем витринам одновременно, а обновление раз в сутки файлом не создаёт отмен. Ставить сюда интеграцию — решать проблему, которой нет.
- В учёте нет порядка. Если номенклатура задвоена, артикулы записаны в свободной форме, а часть товара живёт в таблице, интеграция не поможет: она аккуратно разнесёт беспорядок по четырём площадкам. Сначала — единый справочник и артикул как ключ, потом обмен. Обычно это две-три недели работы и самая окупаемая её часть.
И отдельная оговорка про сроки жизни решений. Правила площадок, состав отчётов и лимиты API меняются несколько раз в год — это нормальный режим работы, а не форс-мажор. Поэтому в договоре на интеграцию должна быть строка про реакцию на изменения со стороны площадок с понятным сроком, а в бюджете — ежемесячная сумма на поддержку. Связка без поддержки не «работает вечно», она работает до ближайшего изменения на стороне площадки и потом молча останавливается.
Карта раздела: где искать продолжение
Эта статья — вторая опорная в разделе о сайтах и электронной торговле. Первая разбирает связь магазина с учётной системой: четыре способа обмена, частоту и мониторинг. Остальные материалы раздела закрывают отдельные контуры; полный список тем собран на странице кластера /zhurnal/temy/sayty-i-ecom.
- Обмен интернет-магазина с 1С — опорная статья про связь витрины и учёта, четыре способа и цена каждого.
- Обмен остатками и ценами с сайтом — полный и разностный обмен, резервы, виды цен и отчёт расхождений.
- Заказы и статусы между сайтом и учётом — маршрут заказа, очередь повторов, сопоставление артикулов и суточная сверка.
- Автоматизация цен в магазине — правила переоценки, ограничители по марже и сторож базовой цены.
- Отзывы и вопросы покупателей — что можно отдать автомату, а что нельзя ни при каких условиях.
- Автоматизация возвратов — маршрут возврата и отдельный поток возвратов с площадок.
- Аналитика интернет-магазина — девять отчётов, включая выручку по площадкам с учётом комиссий.
Если сводить всё к трём решениям, они такие. Первое: определить доступный к продаже остаток письменно и выбрать модель распределения между площадками — это половина будущих отмен. Второе: посчитать ручной контур по операциям и сравнить с подпиской на сервис, прежде чем заказывать разработку; в большинстве магазинов до тысячи позиций разработка проигрывает. Третье: заложить мониторинг по каждой площадке отдельно, потому что четыре кабинета ломаются по одному, а замечают это по общему провалу продаж через неделю.
Карта связей: в центре узел «Интеграция магазина с маркетплейсами (эта статья)». Слева связанный узел «Обмен интернет-магазина с 1С — основание контура». Вокруг шесть узлов: «Остатки и цены с сайтом», «Заказы и статусы между сайтом и учётом», «Автоматизация цен», «Отзывы и вопросы покупателей», «Автоматизация возвратов», «Аналитика магазина: выручка по площадкам». На связях подписи, что именно каждая тема закрывает. Чертёжная манера, подписи по-русски.
Площадка продаёт не ваш товар, а ваше обещание. Интеграция нужна для того, чтобы обещание было одно на все четыре витрины.
