Предзаказ товара в интернет-магазине: партии, сроки и изменения

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

Автор: Александр Поркулевич, CEO и основатель, 404gen.

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

В этом разборе рассматриваем устройство модуля для собственного магазина. Это не инструкция по приобретению товара определённого бренда и не юридическое толкование предоплаты. Конкретные условия продажи, отмены и возврата утверждает владелец бизнеса со своими специалистами. Здесь разложим пользовательские сценарии, состав данных, исключения и проверки, которые можно включить в задание на разработку.

Что должно быть понятно до оформления предзаказа

Человеку нужны четыре ответа: какой вариант товара он выбирает, когда ожидается поставка, что произойдёт после оформления и как узнать об изменениях. Если дата приблизительная, интерфейс должен говорить об этом прямо. Формулировка «отправим завтра» не подходит для товара, который поставщик ещё не подтвердил. Красивый обратный отсчёт тоже не заменяет сведения о состоянии партии.

Рекомендуем показывать условия рядом с основным действием, а не прятать их в общем FAQ магазина. На карточке может быть написано: «Ожидаем партию в указанном интервале. После оформления сообщим о подтверждении поступления». Это пример текста для обсуждения, а не готовые обязательства конкретного магазина. В проекте фраза должна соответствовать действительно поддерживаемому процессу.

Предзаказ, ожидание поступления и резерв: три разные модели

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

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

Начните с одного рабочего примера

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

Затем усложняем пример: поставщик привёз только часть графитовых ламп, один покупатель отменил ожидание, а другой изменил цвет. Такие разборы быстрее выявляют границы продукта, чем список из двадцати абстрактных функций. Числа в примере заданы для проверки логики. Они не описывают продажи, склад или результаты клиентов 404gen.

Карточка товара: сначала условия, затем действие

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

Полезно отделить карточку от сообщений об ошибке. Карточка объясняет нормальный процесс, а ошибка сообщает, почему сейчас нельзя продолжить. Например, «Количество в этой партии изменилось. Проверьте доступный вариант» лучше безадресного «Что-то пошло не так». Сообщение не должно самостоятельно менять цвет или количество и продолжать покупку за пользователя.

Срок поставки имеет собственную историю

Одна дата в поле недостаточна, когда магазин общается с поставщиками. Разделите ожидаемую дату, подтверждённую дату и дату последнего обновления. Для интервала храните начало и конец, источник сведений и ответственного за публикацию. Непроверенное сообщение менеджера не должно автоматически превращаться в обещание на сайте.

При переносе срока сохраните предыдущую версию. Поддержка должна видеть, что отображалось в момент оформления и о каком изменении уже уведомили покупателя. Иначе сотрудник объясняет ситуацию по текущей карточке, а у человека в письме лежат другие условия. Общая история изменений помогает восстановить основание действия, но для предзаказа важна именно связь версии условий с заказом.

Не смешивайте будущую партию с остатком на складе

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

На сервере задайте правило распределения. Например, сначала обрабатываются подтверждённые заявки в определённой очередности, затем свободный остаток становится доступен для обычной покупки. Конкретное правило утверждает бизнес. Важно, чтобы оно не зависело от того, кто первым открыл административный экран, и было воспроизводимо по данным.

Защита от одновременных заказов

Две вкладки могут одновременно увидеть одну последнюю единицу ожидаемой партии. Блокировка кнопки в браузере не решает этот конфликт: второй покупатель работает на другом устройстве. Проверка доступности и создание основания резерва должны согласовываться на стороне системы, которая управляет распределением партии.

Техническую стратегию выбирают под используемую базу и нагрузку. Уровни изоляции PostgreSQL описывают поведение конкурентных транзакций; выбор конкретного уровня не отменяет проверки бизнес-условий и обработки повторов. Заказчику полезнее требовать наблюдаемый результат: при двух одновременных попытках система не выделяет одну единицу двум заказам и объясняет отказ проигравшей попытке.

Повтор отправки не должен создавать вторую покупку

Покупатель нажал действие, сеть прервалась, подтверждение не появилось. Он повторяет попытку. Если каждая отправка создаёт независимый заказ, магазин получает дубли, а человек не понимает, сколько у него обязательств. Нужен устойчивый идентификатор операции и способ получить уже созданный результат.

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

Корзина с обычными товарами и предзаказом

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

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

Оплата и внешние статусы

Способ оплаты и момент её подтверждения описываются отдельным сценарием. Интерфейс не должен объявлять внешнюю операцию завершённой только потому, что человек вернулся со страницы платёжного сервиса. Зафиксируйте источник подтверждения, обработку задержавшегося ответа и действия поддержки при неопределённом результате.

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

Изменение условий уже оформленного ожидания

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

Условный пример проверки: человек открыл предложение версии 2, а сотрудник успел опубликовать версию 3. При попытке согласиться сайт сообщает, что условия обновились, и предлагает перечитать их. Он не переносит согласие на новую версию автоматически. Для бизнес-процесса это полезнее, чем простая галочка «ознакомлен», у которой не записано, с чем именно ознакомились.

Кабинет покупателя и обращения поддержки

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

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

Уведомления не равны состоянию заказа

Изменение сохраняется сначала в системе, после чего формируется сообщение. Недоставленное письмо не отменяет сохранённое изменение, а повтор письма не повторяет само действие. В журнале полезно различать созданное уведомление, принятие каналом и известный результат доставки. Если канал не предоставляет подтверждение прочтения, его нельзя рисовать в кабинете как установленный факт.

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

Состояния ожидания и доступность интерфейса

Не обозначайте состояние только оттенком. Человеку нужно прочитать «Заявка сохранена», «Ожидаем подтверждения поставки» или «Действие недоступно: партия закрыта». Кнопка во время отправки должна иметь понятное состояние, но длительная блокировка без сообщения выглядит как зависший сайт. При неопределённом ответе предложите проверить заявку, а не сразу создать новую.

Для динамических сообщений учитывайте вспомогательные технологии. В пояснении W3C о статусных сообщениях рассматривается объявление изменений без принудительного переноса фокуса. В модуле предзаказа это пригодится после сохранения заявки, обновления доступности и результата повторной проверки. Такие сообщения должны соответствовать реальному ответу, а не появляться по таймеру для красоты.

Что согласовать с 1С, CMS и складом

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

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

Матрица приёмки перед запуском

Приёмка строится вокруг наблюдаемых последствий. Вместо «модуль работает быстро» напишите: при повторе команды находится прежняя заявка; при изменении версии условий старое подтверждение отклоняется; при частичной поставке доступно только согласованное количество. Для каждой проверки сохраните входные данные, действия, ожидаемый результат и способ восстановления тестовой среды.

Шаблон задания на модуль предзаказа

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

• Модель: уведомление, предзаказ или резерв будущей партии.
• Сущности: товар, вариант, партия, заказ, версия условий и операция.
• Роли: покупатель, поддержка, склад и ответственный за сведения поставщика.
• Исключения: перенос, частичное поступление, отмена, повтор и потерянный ответ.
• Приёмка: конкурентная проверка, история условий и сверка внешних событий.

Как оценивать пользу после запуска

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

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

Частые вопросы

Можно ли начать без приёма оплаты?

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

Нужна ли точная дата поступления?

Не всегда такая информация существует. Можно показывать обоснованный интервал или объяснять, что дата пока уточняется. Важно сохранить источник сведений и не выдавать предварительную оценку за подтверждённый срок. Обновление уже сообщённых условий должно иметь понятную историю и предусмотренный процесс общения с покупателем.

Как предзаказ связан со складскими остатками?

Ожидаемая партия и принятый на склад товар описывают разные состояния. При приёмке нужно сверить фактическое количество и применить согласованное правило распределения. Резерв будущей партии не стоит прибавлять к доступному складу одной общей цифрой. Иначе возможна продажа количества, которого магазин ещё не получил.

Что проверить в мобильной версии магазина?

Переключение вариантов, читаемость условий, повтор после потери связи и смешанную корзину. Изменение срока нельзя прятать ниже нескольких длинных блоков. После отправки должно быть видно, принята ли заявка. Ошибка объясняет следующий шаг и не заставляет человека бесконтрольно повторять оформление.

С чего начинается оценка разработки?

С разбора текущего заказа, источника поставок и исключений. Полезно принести один товар с несколькими вариантами, пример переноса срока и описание распределения партии. Затем определяются роли, связи с CMS и учётной системой, состав первой версии и критерии приёмки. Срок и смета зависят от этих границ.

Следующий шаг для вашего магазина

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