Продажи в минус убирают не скоростью синхронизации, а буфером

Вторник, начало одиннадцатого. Менеджер по маркетплейсам заходит с телефоном в руке и произносит фразу, после которой день можно считать испорченным: отменяем четырнадцать заказов на Wildberries. Позиция ушла в ноль ещё в пятницу — её забрали оптом с того же склада. В кабинете площадки остаток всё это время стоял прежний, потому что выгружают его по утрам руками, а в пятницу было не до того. Дальше по списку: отмены, падение рейтинга, падение показов.

Дальше обычно говорят: нужна интеграция, чтобы остатки обновлялись мгновенно. Мгновенно не бывает, и начинать стоит не с этого.

Первое решение: кто хозяин остатка

До всякой техники надо ответить на один вопрос — чья цифра главная. И ответ разный в зависимости от того, где физически лежит товар.

Если товар у вас — это схемы FBS и DBS, плюс, разумеется, ваш собственный сайт, — хозяин остатка ваша учётная система. Она считает и отдаёт цифру на площадки.

Если товар вы отвезли на склад маркетплейса — это FBO, — хозяин остатка сам маркетплейс. Ваша система здесь ничем не командует: она принимает его отчёты и сводит их со своим учётом.

У большинства продавцов работают обе схемы одновременно, и вот здесь ломается чаще всего. Систему заставляют переписывать то, что ей не принадлежит: она бодро отдаёт на FBO-склад цифру из своей 1С, площадка её игнорирует, остатки расходятся — а в отчётах всё зелёное. «Интеграция настроена», а остатки врут.

Путаница в границе между «мой остаток» и «его остаток» — самая частая причина, по которой настроенная интеграция всё равно не работает.

Почему «тут же» не бывает

Остатки уходят на площадки не по одному, а пачками, и площадка ограничивает, как часто и какими порциями их можно присылать. Прислали слишком часто — получили отказ и ждите. Поэтому обновление устроено как цикл, а не как мгновенная реакция: быстрый круг по ходовым позициям идёт часто, полный прогон по всей номенклатуре — заметно реже.

И даже это ещё не всё. Приняли обновление и применили его в карточке — два разных события: запрос возвращает не «готово», а идентификатор задачи, результат нужно спрашивать отдельно.

Между продажей на одной площадке и новой цифрой на другой всегда есть окно, и величина у него разная. По ходовым позициям — минуты: круг по ним идёт часто. По «хвосту» окно равно частоте полного прогона, то есть час-два. Поэтому и резерв по ходовым и по хвосту считают по-разному. А саму частоту задаёт не желание, а лимит площадки: он считается на аккаунт, в разных методах разный и меняется без предупреждения — поэтому цифру держат в настройке, а не в договоре, и следят за ней по логу отказов.

Отсюда вывод, который стоит принять до начала работ: оверселлинг убирают не скоростью, а буфером. Один физический остаток делится между каналами, а не отдаётся каждому целиком — иначе десять штук превратятся в двадцать четыре обещанных на трёх площадках. Сначала из свободного остатка вычитается резерв, это и есть буфер, а то, что осталось, расходится квотами: ходовому каналу больше, медленному меньше.

Размер резерва считается просто: сколько штук этой позиции уходит за время одного цикла обновления. Продаётся по двадцать штук в день, полный прогон идёт раз в час — держим одну-две. Уходит две штуки в неделю — резерв не нужен, он только заморозит склад. Двойная продажа последней единицы после этого перестаёт быть рутиной и становится редким случаем, который вы видите в логе синхронизации, а не узнаёте из отмены в кабинете.

Обещать полный ноль отмен по остаткам нечестно. Между тем, как покупатель нажал «купить», и тем, как об этом узнала ваша система, проходит время, и никакая интеграция это время не отменяет. Вопрос только в том, во сколько отмен в месяц вам это обходится — и эту цифру видно до начала работ, в вашем же кабинете.

Что синхронизируется на самом деле

Остатки. Свободный остаток минус резерв на канал. Считается по вашим правилам: что учитывать, что держать под опт, какой запас оставлять под брак и пересорт.

Цены. Из своей системы вы управляете своей ценой — единой или отдельной по площадкам, с наценками и правилами по группам. Витринная цена вам при этом не принадлежит: сверху лягут акции площадки, её скидки и промокоды, и управляются они по-разному. Полезная задача интеграции здесь другая: система знает вашу себестоимость и не отдаёт цену ниже порога, а если витрина всё-таки ушла под порог — вы получаете оповещение, а не узнаёте об этом из отчёта в конце месяца.

Заказы. Приезжают в вашу систему, статусы и отгрузки возвращаются обратно.

Карточки. Контент вы правите в одном месте, но на каждую площадку он уходит через свой перевод: у Wildberries и Ozon разные деревья категорий и разные наборы обязательных характеристик, где даже совпадающие по смыслу поля имеют свои идентификаторы и свои допустимые значения. Этот перевод пишется один раз на категорию и потом поддерживается. Модерацию площадка оставляет за собой, и отклонённые правки система должна показывать списком, а не проглатывать молча.

Что происходит без интеграции

Самая дорогая ошибка на маркетплейсе — продать то, чего уже нет. Отмена бьёт по рейтингу, рейтинг — по показам, а показы — по выручке, и восстанавливается это медленнее, чем падает.

Рядом три расхода потише. Рассинхрон цен: торгуете себе в убыток или проваливаетесь в выдаче. Потерянные заказы: не заметили в кабинете, сорвали срок. И часы на ручной ввод — менеджер вместо продаж переносит цифры между таблицами.

Готовый коннектор или своя интеграция

Решает не размер бизнеса, а количество нестандартных правил.

Если правила простые — один склад, один прайс, обычные категории, — готовый коннектор за абонентскую плату закроет задачу, и разработка не отобьётся. Так и скажем.

Своя интеграция начинает выигрывать там, где правил много и они ваши: резервы под оптовые заявки, персональные цены контрагентов, нетиповой учёт, своя логика комплектов.

Это мы делали сами. Единый контур «производство → 1С → маркетплейсы» собран у нас в проектах СтатусPRO и B2Motor — там же, где живут резервы под оптовые заявки и персональные цены контрагентов.

Обменов с 1С у нас несколько, и устроены они по-разному. Самый старый, складской — тот, что обслуживает сборку заказов, — работает в обе стороны, и это отдельный класс задач. Односторонний обмен просто переносит цифру: источник сказал, приёмник записал. Двусторонний каждый раз решает, чья версия главная, когда обе стороны успели поменять одно и то же. Это ровно тот вопрос, с которого начинается статья, — только второй стороной там выступает площадка, а не ваш склад.

Когда вам это не нужно

Площадка одна, склад один, до трёхсот–пятисот артикулов, до полусотни заказов в день, а менеджер тратит на кабинеты меньше часа в день — берите коннектор и не тратьте деньги на разработку. Своя интеграция начинает окупаться, когда каналов становится три и появляются правила, которых в коннекторе нет.

С чего начать

С двух цифр, которые можно снять сегодня и без нас. Первая: сколько отмен по остаткам было у вас за последний месяц — она есть в кабинете каждой площадки. Вторая: сколько времени менеджер тратит на кабинеты в день. Первая покажет, сколько стоит окно рассинхрона. Вторая — сколько стоит ручная работа.

Дальше по-хорошему идёт аудит: какие схемы работы на каждой площадке, чем сопоставлена номенклатура, где ведётся учёт, какие правила цен и резервов. Потом настройка на реальных данных, проверка на краевых случаях — возвраты, частичные отгрузки, пересорт, — и запуск с мониторингом.

Смежное: как читаются чужие таблицы — та же задача сопоставления, только со стороны клиентских заявок.