На складе нет, на сайте есть: синхронизация остатков в реальном времени
Покупатель находит товар на сайте, кладёт в корзину, подтверждает заказ, деньги списываются с карты. Через несколько часов раздаётся звонок: «К сожалению, этого товара на складе не оказалось, оформляем возврат». Это не просто отменённый заказ — это момент, после которого клиент вам больше не доверяет.
Чаще всего дело не в технологиях, а в том, что склад и сайт говорят на разных языках: один знает одну цифру, другой показывает совсем другую, и никто не построил между ними мост. Починить это — не столько написать код, сколько ответить на три вопроса: чья цифра верна, как быстро она обновляется и кто кого должен ждать.
Во что обходится один звонок с извинениями
Когда подтверждённый заказ отменяется, потеря — не просто одна продажа. Рекламные деньги, которые привели этого покупателя на сайт, уже потрачены. Время, которое он потратил на заполнение карты, адреса и способа доставки, ушло впустую. С вашей стороны кто-то должен позвонить, извиниться, вручную оформить возврат, возможно предложить замену — и это время, которое можно было потратить на другие заказы.
Самая дорогая часть при этом незаметна: в следующий раз, когда покупатель будет искать этот же товар, он, скорее всего, пойдёт не к вам, а туда, где его не разочаровали. Эта потеря нигде не отражается в отчёте, но обходится дороже, чем привлечение нового клиента через рекламу.
Дело никогда не в том, что товар иногда заканчивается — это нормально, так происходит в любом бизнесе. Дело в том, чтобы эта информация появлялась на сайте до заказа, а не после. Покупатель, увидевший «нет в наличии» заранее, не обижается — он просто выбирает другой вариант или ждёт.
Почему ручное обновление всегда отстаёт
В большинстве небольших и средних магазинов остаток товара живёт в двух, а то и трёх местах: в собственной программе склада (иногда просто в таблице), в бухгалтерской системе и в админ-панели сайта. Кто-то раз или два в неделю вручную переносит первую цифру в последнюю.
Проблема этого метода не в скорости — даже если цифра верна в момент переноса, каждая продажа, возврат и товар, унесённый из физического магазина после этого момента, делают её устаревшей. В бизнесе, который продаёт сразу через три канала — офлайн-магазин, маркетплейс и собственный сайт, — цифра на сайте оказывается неверной уже к середине дня: касса и сайт друг с другом просто не разговаривают.
Решение — не обновлять чаще вручную, а полностью убрать человека из этой цепочки. Когда остаток меняется в складской программе или бухгалтерии, он должен автоматически попадать в каталог сайта, а не когда кто-то вспомнит это сделать. Это разовая техническая настройка, после которой никто больше не спрашивает «а обновили ли остатки».
Частота синхронизации: не всем товарам нужна одна скорость
Синхронизация в реальном времени звучит привлекательно, но не одинаково важна для каждого товара. Выбирать частоту разумнее по скорости продаж конкретной позиции.
Товары с ограниченным количеством, которые быстро уходят
У товара из ограниченной серии или с последними единицами задержка обходится дорого — за несколько минут два разных покупателя могут заказать одну и ту же последнюю единицу. Для этой группы синхронизация должна быть событийной: как только остаток меняется на складе — продажа, возврат, физическая покупка, — сайт узнаёт об этом сразу, не дожидаясь очередного часа.
Широкий ассортимент товаров, которые расходятся медленно
В магазине с сотнями позиций запчастей или мелких товаров синхронизация каждую минуту не нужна и не оправдывает затрат. Обновления раз в час или в несколько часов вполне достаточно, потому что вероятность того, что один покупатель за это время попадёт точно в последнюю единицу, невелика. Подключать эту группу к событийной системе — тратить технический ресурс там, где в этом нет смысла.
Правильный вопрос — не «насколько быстро», а «во что обходится задержка именно для этого товара».
Кому принадлежит товар в корзине — логика резервирования
Последнюю единицу товара два покупателя могут положить в корзину одновременно. На странице оплаты оба вводят данные карты, но и на складе, и на сайте есть только одна единица. Вопрос не в том, кто победит, а в том, когда второй об этом узнает: до того, как он заполнит карту, или уже после списания денег.
В правильно настроенной системе товар при переходе к оплате резервируется на короткое время — никто другой не может забрать эту единицу, но если покупатель не завершит оплату, по истечении времени она возвращается в свободный остаток. Это окно должно быть достаточно длинным, чтобы покупатель спокойно успел оплатить, и достаточно коротким, чтобы не заставлять другого клиента долго ждать — речь о минутах, а не о часах.
Фактическое списание со склада должно происходить только при подтверждённой оплате, а не в момент добавления в корзину. Иначе товары, забытые в чужих корзинах на часы, будут числиться «проданными», хотя их никто не купил, — и тогда теряете продажу уже вы сами, показывая реальному покупателю, что товара нет.
Правило единственного источника: чья цифра верна
Когда несколько систем — складская программа, бухгалтерия, сайт, возможно аккаунт на маркетплейсе — каждая хранит собственную цифру остатка, рано или поздно они разойдутся. Обычно это выясняется в худший момент: заказ уже оформлен, а товара нет.
Практичное решение — назначить одну систему «источником истины», обычно это складская или бухгалтерская программа, потому что она ближе всего к физическому товару. Сайт, страница на маркетплейсе и любой другой канал только читают эту цифру и никогда не пишут обратно. Передача должна идти в одну сторону через API или webhook — сигнал в момент изменения, а не файл, который переносят раз в день. При такой схеме две системы никогда не перезаписывают друг друга, и вопрос «чья цифра верна» просто не возникает.
Продать товар, которого нет на складе, обходится дороже, чем заранее сказать, что его нет.
С чего начать синхронизацию
Последовательность перед стартом проекта короткая:
- Составьте карту текущей ситуации — в скольких местах живёт остаток: складская программа, бухгалтерия, сайт, аккаунт маркетплейса.
- Выберите источник истины — какая система ближе всего к физическому товару, та и будет называть «верную цифру».
- Настройте способ передачи — API или webhook, поток в одну сторону, а не файл, который переносят вручную.
- Разделите частоту по группам товаров — ограниченные позиции синхронизируются по событию, широкий ассортимент — почасово.
- Проверьте окно резервирования — попробуйте заказать один и тот же товар с двух разных браузеров одновременно и посмотрите, корректно ли система отклонит второй заказ.
Это не разовая настройка, а постоянно работающий мост между системами. Наша услуга интеграции систем как раз строит такой мост: определяет, какая система станет источником истины, настраивает частоту синхронизации под тип товара и выстраивает логику резервирования так, чтобы ни один клиент больше не услышал, что оплаченного товара не существует.
