Резервирование товара на складе помогает малым командам держать точные остатки, различать доступно, зарезервировано, продано и корректно обрабатывать таймауты оплаты.
Оверселл - это когда вы продаете больше, чем реально есть на складе. Кажется, что это беда больших магазинов, но маленькие команды сталкиваются с ней даже чаще: все делается «на ходу», роли смешиваются, а иногда достаточно двух параллельных заказов, чтобы остатки разъехались.
Главная причина - нет одного четкого момента, когда товар перестает быть доступным для других покупателей. Один менеджер увидел «последнюю штуку» и пообещал клиенту, второй в это же время подтвердил другой заказ, а на складе физически лежит один товар. Без понятного правила резервирования такая ситуация почти неизбежна.
Таблицы и ручные правки усиливают проблему. В Excel легко забыть обновить строку, перетереть формулу или «поправить потом». Еще хуже, когда остатки живут сразу в нескольких местах: в таблице, в мессенджере и в голове у кладовщика. В итоге «правда» у каждого своя.
Одна неточная единица быстро превращается в цепочку проблем. Клиент оплачивает, а товара нет. Приходится срочно искать замену, переносить сроки, делать возврат и писать извинения. Команда тратит часы на выяснение, кто и когда «съел» остаток, а негатив в отзывах остается надолго.
Чтобы перестать ловить такие ошибки, сначала нужно договориться о базовых правилах учета. Важно, чтобы у всех было одинаковое понимание:
Когда эти правила ясны, даже небольшая команда работает заметно спокойнее: меньше ручных разборок, меньше сюрпризов, больше доверия к цифрам.
Чтобы не продавать лишнее, в учете полезно держать три простых состояния. Это и есть базовое резервирование товара: вы не «угадываете», что можно продать, а считаете по статусам.
Доступно - то, что можно продать прямо сейчас без риска сорвать уже созданные заказы. Проще говоря, это свободный остаток.
Зарезервировано - товар, который удерживается под конкретный заказ, но сделка еще не завершена. Обычно это промежуток между оформлением заказа и подтверждением оплаты (или подтверждением менеджером). Зарезервированное нельзя предлагать другим покупателям.
Продано - товар, который окончательно вышел из доступного остатка. Обычно он становится проданным после события, которое вы считаете финальным: подтвержденная оплата, отгрузка или выдача. Главное - выбрать одно правило и применять его одинаково.
В цифрах логика простая:
Пример: на складе 10 штук, в резерве 3. Значит доступно 7. Если оформили еще 2 штуки, резерв станет 5, доступно станет 5, даже если оплата еще не пришла.
Чтобы статусы не путались, заранее закрепите события, которые двигают товар между ними:
Если четкой границы между этими тремя состояниями нет, люди начинают «держать в голове», и ошибки появляются даже у внимательных команд.
Нормальный поток строится вокруг простого принципа: товар нельзя считать проданным, пока вы не уверены, что сможете его отгрузить и что он не уйдет другому покупателю. Для маленькой команды это особенно важно, потому что один звонок менеджеру и один заказ на сайте легко сталкиваются лбами.
Понятная схема обычно выглядит так:
Ключевой момент: резерв лучше ставить при оформлении заказа, а не при оплате. Иначе два человека могут дойти до оплаты почти одновременно, и вы получите оверселл, даже если «на витрине» цифры выглядели правильно.
Есть два рабочих варианта. Важно выбрать один и не смешивать:
«Продано» на оплате. Подходит цифровым товарам или ситуациям, где отгрузка почти мгновенная.
«Продано» на отгрузке/выдаче. Подходит физическим товарам, где возможны отмены, переносы и частичная выдача. В этом случае после оплаты статус заказа скорее «оплачено», а резерв держится до фактической передачи.
Для склада с физическими товарами чаще удобнее второй вариант: он ближе к реальности, если сборка и доставка живут своей жизнью.
Если у вас есть сайт, маркетплейсы и менеджер в чате, им всем нужен один источник правды по остаткам. И почти всегда нужен журнал изменений, чтобы без расследований понимать, почему товар стал недоступен.
В истории фиксируйте минимум: кто сделал действие (пользователь, менеджер, интеграция), что произошло (резерв, оплата, отмена, отгрузка), время, количество и причину (например, «таймаут оплаты» или «отмена клиентом»). Тогда спорные ситуации решаются быстро: видно, когда резерв появился и почему он снялся.
Чтобы резерв работал без сюрпризов, сначала договоритесь о правилах, а уже потом автоматизируйте. Большая часть оверселла случается не из-за «плохой системы», а из-за разных трактовок единиц и статусов.
Начните с единицы учета. Для каждого товара выберите, чем вы торгуете на самом деле: штука, упаковка, набор, метры. Сразу закрепите правило округления (например, «продаем только кратно 1 упаковке» или «метры округляем до 0,1»). Иначе один сотрудник спишет 1, другой 0,5, и остаток поплывет.
Дальше разделите статусы на два уровня: статус заказа и статус позиции внутри заказа. Один заказ может быть частично оплачен или частично собран, и это нормально. Важно, чтобы позиция могла отдельно быть «зарезервирована», «снята», «продана», даже если весь заказ пока «ожидает оплату».
Рабочий минимум обычно такой:
Простой пример: клиент оформил заказ на 2 штуки, но оплату откладывает. Вы ставите TTL на 20 минут. Эти 2 штуки становятся «зарезервировано» и не должны показываться как доступные для другого заказа. Если оплата прошла - резерв превращается в продажу. Если нет - резерв снимается по таймеру, и товар снова доступен.
И обязательно включите журнал изменений. Записывайте, кто и когда создал резерв, снял его, изменил количество, подтвердил оплату. В спорных случаях это экономит время и деньги: видно причину изменения и цепочку событий, а не просто «остаток вдруг стал другим».
Таймаут оплаты нужен, когда заказ уже создан, товар отложен, но деньги не пришли. Без таймаута резерв висит часами или днями, и вы теряете продажи. С таймаутом вы честно держите товар ограниченное время, а потом возвращаете его в продажу автоматически.
Срок таймаута зависит от того, как обычно платят ваши клиенты и как быстро товар «улетает». Для кофе с собой и «горячих» билетов это может быть 10-15 минут. Для обычного интернет-магазина часто хватает 30-60 минут. Для счетов юрлицам или редких позиций логично ставить 24 часа или отдельный режим «ожидаем оплату по счету».
Важно правило одного источника правды: кто решает, что оплата не состоялась. Лучше, когда это решает платежная система (или банк) через подтвержденный статус, а ваша учетная система только реагирует. Если ориентироваться на «мы не видим денег», а платеж приходит с задержкой, начинаются ручные разборки.
Когда таймаут истек, резерв снимается автоматически: количество возвращается в «доступно», заказ получает понятный статус (например, «истекло время оплаты»), а дальнейшая отгрузка блокируется.
Поздняя оплата после таймаута встречается чаще, чем кажется. Заранее выберите сценарий и придерживайтесь его:
Клиенту лучше писать коротко и спокойно. Например: «Мы держали товар до 14:30. Оплата не успела подтвердиться, поэтому резерв снят. Если нужно, оформим заказ заново, а если товар закончился, предложим альтернативу или возврат».
Если вы автоматизируете учет, эти правила можно описать как простой поток событий: создание заказа, резерв, таймер, подтверждение оплаты, снятие резерва и обработка поздних платежей. В TakProsto (takprosto.ai) такой внутренний сервис можно собрать из чата, заранее зафиксировав статусы, таймауты, роли и экраны для остатков, заказов и журнала.
Чтобы не возникал оверселл, важно разделять похожие события: отмена до оплаты и возврат после оплаты. На складе они меняют разные статусы и по разным правилам. Если это не фиксировать документом и причиной, «точность складских остатков» быстро превращается в гадание.
Отмена до оплаты обычно означает одно: вы снимаете резерв и возвращаете товар в «доступно». Продажи еще не было, деньги не получены, значит статус «продано» трогать не нужно. Частая ошибка - держать резерв «на всякий случай», а потом забыть снять. В итоге товар как будто есть, но купить его нельзя.
Возврат после оплаты - это обратная операция к продаже. Товар был «продано», а потом (частично или полностью) вернулся. Здесь важно фиксировать не только количество, но и состояние товара и причину возврата.
Если в заказе было 3 позиции и вернули только одну, нельзя просто «прибавить остаток» по всему заказу. Возврат должен быть построчным: какая позиция, сколько штук, в каком состоянии. Тогда одна строка снова станет «доступно» (или уйдет в отдельное место), а остальные останутся «продано».
Практичное правило для учета:
Если товар вернулся с браком, часто его нельзя возвращать в «доступно». Лучше иметь отдельный склад или статус, например «карантин/брак/уценка». Тогда вы не продадите то, что нельзя отгрузить без проблем.
С доставкой тоже есть тонкость: товар может физически покинуть склад, но возврат еще возможен. В учете удобно отражать это как отдельный этап, например «отгружено». Тогда возврат становится понятным: вернули - приняли на склад (в доступно или карантин), не вернули - остается продано.
Главное правило: любое движение оформляйте как отдельную операцию (отмена, возврат, списание, уценка) и всегда храните причину. Это экономит часы разборок, когда цифры «не сходятся».
Представим обычный день в небольшом магазине. На складе осталось 3 штуки популярного товара. Два менеджера параллельно общаются с клиентами в мессенджерах и заносят заказы в учет.
В 12:01 менеджер А оформляет заказ N1 на 2 штуки. Сразу после создания заказа эти 2 штуки должны уйти из статуса «доступно» в статус «зарезервировано». Тогда в системе станет: доступно 1, зарезервировано 2, продано 0. Даже если второй менеджер не знает про первый заказ, он уже не сможет пообещать больше, чем реально осталось.
В 12:03 менеджер Б оформляет заказ N2 на 1 штуку, клиент платит сразу. Логика такая: сначала 1 штука резервируется под заказ, затем после подтверждения оплаты переходит в «продано». Итог: доступно 0, зарезервировано 2, продано 1. Оверселла нет, потому что резерв «закрыл» товар в первые минуты.
Дальше ключевой момент: клиент по заказу N1 не оплатил. Вы задаете таймаут (например, 15-30 минут, в зависимости от процесса). По его истечении заказ N1 автоматически получает статус «не оплачен» или «отменен», а резерв снимается. Тогда цифры возвращаются к реальности: доступно 2, зарезервировано 0, продано 1.
Иногда клиент по первому заказу пытается оплатить позже. Чтобы не было конфликтов, правило должно быть однозначным: поздняя оплата не «воскрешает» старый резерв, а запускает проверку наличия заново. Если доступные 2 штуки есть - создается новый резерв, заказ подтверждается. Если товара уже нет - менеджер предлагает замену или возврат.
Менеджерам помогают короткие заранее заготовленные сообщения:
Важно, что менеджер не правит остатки руками. Он работает со статусами заказа, а система сама двигает количество между «доступно», «зарезервировано» и «продано».
Оверселл почти всегда появляется не из-за «невнимательности», а из-за правил, которые каждый понимает по-своему. Кто-то считает, что товар уже «наш» после клика в корзине, кто-то - только после отгрузки. Без договоренности статусы начинают жить своей жизнью, и остатки расползаются.
Если резерв ставят на добавлении в корзину, склад замораживается. Покупатели «держат» товары часами, а продажи падают, потому что доступного вроде бы нет.
Если резерв ставят только после оплаты, появляется окно для гонки: два человека оформляют один и тот же последний товар, и система пропускает обоих. Резерв работает, когда его момент привязан к четкому событию (обычно: заказ создан и начата оплата) и есть понятное время жизни резерва.
Когда у резерва нет дедлайна, он снимается «по ситуации». Сегодня менеджер увидел неоплаченный заказ и очистил, завтра не увидел, послезавтра заказ всплыл в чате, и все вспоминают, кто и что держит.
Нормальное правило простое: резерв живет фиксированное время, а таймаут оплаты снимает его автоматически и одинаково для всех каналов продаж.
Частая история: при оплате товар «списали», а при отгрузке списали еще раз, потому что процесс отгрузки не проверяет, что уже было сделано. Другая версия - когда «оплачен» воспринимают как «отгружен», и действия делаются не в том месте.
Чтобы этого не было, держите события раздельно и следите, что именно меняется в остатках:
Когда остатки правят напрямую (в таблице или в админке «просто поправлю цифру»), теряется причина изменения. Потом невозможно ответить на простой вопрос: это был возврат, пересорт, брак или забытая отгрузка?
Лучше разрешать ручные корректировки только через понятную операцию с комментарием и привязкой к документу (инвентаризация, списание, возврат). Если вы собираете внутренний инструмент, сразу закладывайте журнал изменений: кто поменял, что поменял, почему и к чему это относится.
Если регулярно всплывает вопрос «почему товар в системе есть, а на полке нет», почти всегда проблема не в людях, а в правилах статусов и резерва.
В учете должны быть понятные цифры, которые можно объяснить одним взглядом:
И контрольный вопрос, который быстро выявляет слабое место: что происходит, когда человек оформил заказ, но не оплатил?
Если таймаут оплаты не закрыт автоматикой, резервы копятся и начинают «съедать» доступный остаток. Должны быть простые правила, которые система выполняет сама:
Чтобы закрепить результат, полезно завести привычку: раз в неделю смотреть топ-10 позиций с расхождениями. Если в лидерах один и тот же товар, причина обычно одна из трех: слишком длинный таймаут оплаты, нет автоснятия резерва, или возвраты оформляют как «корректировку» без причины. Такая сверка помогает править правила, а не спорить с цифрами.
Точность остатков держится не на героизме, а на одинаковых правилах для всех. Зафиксируйте, что именно означают статусы «доступно», «зарезервировано», «продано», и в какой момент товар переходит между ними. Это убирает споры вроде «я думал, резерв держим до завтра».
Соберите правила в коротком документе на одну страницу. Опишите не только «как должно быть», но и что делаете в исключениях: таймаут оплаты, отмена, частичная отгрузка, ручная правка.
Минимальный набор, который стоит утвердить:
Дальше начинайте с малого. Возьмите один канал продаж (например, только сайт или только менеджеров) и небольшой ассортимент, условно 20-50 SKU. Прогоните неделю: сколько раз был таймаут, сколько отмен, где чаще всего ломается логика. Потом подключайте остальные каналы и расширяйте каталог.
Продумайте роли. Обычно достаточно трех: оператор (создает заказы и видит статусы), кладовщик (подтверждает выдачу), админ (может отменять и править склад). И важное правило: любые ручные правки - только с причиной, чтобы журнал помогал, а не раздражал.
Если нужен простой внутренний сервис учета, его можно собрать в TakProsto: одним чат-заданием описать статусы, таймауты, права доступа и экраны (остатки, заказы, журнал). Для роста пригодятся экспорт исходников, деплой и хостинг, свой домен, а также снимки и откат, чтобы безопасно менять правила, не ломая работу команды.
Оверселл — это когда вы принимаете заказ (и часто оплату) на товар, которого уже нет в наличии. Чаще всего это происходит из‑за отсутствия четкого правила, в какой момент товар становится недоступным для других: два параллельных заказа «съедают» один и тот же остаток.
Обычно резерв ставят при создании заказа (или подтвержденной фиксации заказа менеджером), а не при оплате.
Так вы закрываете окно гонки, когда два человека почти одновременно доходят до оплаты последней штуки.
Базовая модель:
Практичная формула: доступно = на складе − резерв.
Выберите одно правило и закрепите его:
Главное — не смешивать: если вы уже перевели в «продано» на оплате, при отгрузке не должно быть второго списания.
TTL (таймаут) нужен, чтобы резерв не висел бесконечно и не «съедал» продажи.
Ориентиры по умолчанию:
По истечении TTL резерв снимается автоматически, заказ получает понятный статус, отгрузка блокируется.
Заранее зафиксируйте сценарий и применяйте его всегда:
Не «оживляйте» старый резерв автоматически — сначала проверяйте наличие заново.
Нужен единый источник правды по остаткам, иначе каждый канал будет жить своей версией.
Минимум, который спасает от споров:
Журнал изменений — это страховка от «почему цифры не сходятся».
Фиксируйте хотя бы:
Тогда разбор занимает минуты, а не часы.
Отмена до оплаты и возврат после оплаты — разные события:
Для брака/уценки лучше отдельный статус или «карантин», чтобы не продавать то, что нельзя отгрузить.
Начните с правил, потом автоматизируйте:
Если нужен простой внутренний инструмент, в TakProsto можно собрать сервис учета из чата: статусы, TTL, роли, экраны «остатки/заказы/журнал», а также безопасно менять правила через снимки и откат.
