Синхронизация остатков и заказов в e-commerce: когда проданного товара нет в наличии

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

В этой статье мы рассказываем, как возникает проблема, почему она повторяется и на какие вопросы нужно ответить при настройке синхронизации. Примеры берём из связей с ERP и маркетплейсами в инфраструктуре YazSis Smart E-Commerce. Это не только вопрос технической передачи данных; он касается и того, как вместе работают отделы продаж, склада и клиентской поддержки.

Как возникает ошибочная продажа?

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

1. Последние две единицы на складе отгружаются по заказу с маркетплейса, и остаток в ERP падает до нуля.
2. Сайт магазина по-прежнему показывает «в наличии», потому что остатки обновляются с интервалами или вручную.
3. Клиент кладёт тот же товар в корзину и завершает оплату.
4. Когда склад приступает к сборке заказа, он не находит товар в записи о ячейке.
5. Клиентская поддержка запускает процесс отмены и возврата, отправляет клиенту сообщение с извинениями.
6. Клиент не получил товар и потерял доверие; процесс возврата ещё и создал команде дополнительную работу.

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

Почему синхронизация нарушается?

• Остатки не идут из одного источника. Магазин, ERP и маркетплейсы ведут свои числа отдельно; неясно, какое из них «настоящее», и каждый доверяет своему.
• Обновление запаздывает. Если данные передаются с интервалами или вручную, товар, проданный между двумя передачами, может быть продан дважды. Чем короче интервал, тем ниже риск, но полностью он не исчезает.
• Растёт число каналов. По мере добавления к магазину маркетплейсов, дилеров и корпоративных продаж один и тот же остаток уменьшается из большего числа мест, и каждый новый канал — новая точка задержки.
• События описаны не полностью. Если отмена, возврат, перемещение и частичная отгрузка — события, влияющие на остаток, — не отражаются в системе, расхождение тихо растёт и проявляется лишь при инвентаризации.

Даже если число остатка не ошибочно, оно может привести к ошибочной продаже, потому что его увидели в неподходящий момент.

Шесть вопросов при настройке

Синхронизация — это не «открыл связь и забыл». Следующие вопросы нужно записать до настройки и согласовать совместно с продажами, складом и ИТ:

1. Что является источником остатков? ERP, управление складом или магазин? Остальные системы должны питаться из этого источника, а не списывать остатки сами по себе.
2. Какие события влияют на остатки? Заказ, оплата, отмена, возврат, перемещение и корректировка по инвентаризации нужно рассматривать вместе; если забыть одно, расхождение накопится именно там.
3. Удерживает ли заказ, ожидающий оплаты, остаток? Если да, то на какое время? Если нет, принимается вероятность того, что двое одновременно купят последнюю единицу.
4. Будут ли для каналов выделяться доли? Будет ли каждый канал продавать из общего пула или появится лимит по каналам?
5. Какой склад будет виден? При нескольких складах: остаток какого склада и с каким сроком доставки увидит клиент?
6. Кто узнает об ошибке? Должен быть механизм оповещения, чтобы команда заметила неудачную передачу.

На что смотреть в ежедневной работе?

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

Подход в YazSis Smart E-Commerce

YazSis Smart E-Commerce строится так, чтобы магазин не оказывался оторван от остальной компании. Связи с ERP и маркетплейсами нацелены на синхронизацию данных о товарах, остатках, ценах, заказах и доставке. Несколько складов, видимость остатков и сроков, а также уведомления о статусе доставки включены в тот же поток данных. Перед запуском проверяются данные о товарах, клиентах и заказах и тестируются критичные сценарии; ответы на вопросы выше определяют объём этих тестов.

Чтобы собрать данные об остатках и заказах в один поток между магазином, ERP и маркетплейсами, загляните на страницу Smart E-Commerce.