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

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

Что решает предзаказ товара в интернет-магазине и где проходят границы задачи

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

У этой задачи есть границы, и их полезно проговорить до начала работ.

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

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

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

Чем предзаказ отличается от отсутствующего товара и от «под заказ»

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

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

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

Предзаказ. Оформление происходит до поступления партии. Магазин заранее объявляет условия: срок, цену, порядок оплаты и правила переноса. Обязательство возникает в момент оформления, а не после звонка.

Разница между режимами — не в кнопке, а в том, что магазин обещает и когда. Поэтому в карточке товара полезно явно писать, что это предзаказ, а не «скоро в наличии» и не «уточните у менеджера». Формулировка «уточните» перекладывает работу на покупателя и почти всегда снижает конверсию.

Модель состояний предзаказа

Модель состояний — обязательный артефакт. Без неё заказ «зависает»: непонятно, кто и когда должен сдвинуть его дальше, а покупатель не получает обновлений.

Перечень состояний

Для типового сценария достаточно такого набора. Названия можно менять, важна суть.

• Оформлен. Покупатель оставил заявку, оплата ещё не подтверждена.
• Оплачен, ожидает поступления. Деньги получены, товара на складе нет.
• В поставке. Партия заказана у поставщика или находится в пути.
• Поступил на склад. Товар физически есть, идёт комплектация.
• Готов к отгрузке. Заказ собран, ожидает передачи в доставку.
• Отгружен. Товар передан службе доставки или выдан.
• Срок перенесён. Поставка сдвинулась, покупатель уведомлён.
• Отменён покупателем. Заказ закрыт по инициативе клиента.
• Отменён магазином. Заказ закрыт по инициативе магазина, например из-за отказа поставщика.

Переходы и ответственные

Каждый переход должен иметь условие и владельца. Оформление и оплата — зона сайта и платёжного сервиса. Переход в «В поставке» — зона закупки. «Поступил на склад» и «Готов к отгрузке» — зона склада. «Срок перенесён» и «Отменён магазином» — зона категорийного менеджера, потому что именно он знает причину.

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

Что видит покупатель: кнопка, срок и оплата

Кнопка вместо «Купить»

В публичных обсуждениях разработчиков 1С-Битрикс описывается сценарий, при котором у торгового предложения с нулевым остатком вместо кнопки «Купить» выводится кнопка «Предзаказ», а дальнейшее оформление идёт обычным путём. Там же указывается, что текст кнопки и логика вывода задаются в шаблонах компонентов каталога и оформления заказа. Это описание относится к конкретному решению и конкретной версии, поэтому перед реализацией его нужно проверить на актуальной сборке и на тестовом стенде, а не переносить вслепую.

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

Срок и текст в корзине

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

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

Оплата, изменение срока и отмена

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

Что нужно описать до запуска:

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

Юридические формулировки оферты, права потребителя при предоплате и сроки передачи товара — это зона профильного специалиста. Техническая реализация лишь следует тем правилам, которые он подтвердил, и не подменяет их.

Таблица решений: какой режим выбрать

Таблица помогает согласовать сценарий с бизнесом до начала работ. Строки — типовые ситуации, колонки — что видит покупатель и кто отвечает.

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

Учебный пример: предзаказ партии товара

Учебный пример. Данные условные и не описывают реальный проект.

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

Что нужно сделать по шагам.

1. Согласовать модель состояний и назначить владельца каждого перехода. 2. Подготовить тексты для карточки: что это предзаказ, ориентировочный срок, условия оплаты, порядок отмены. 3. Проверить, как выводится кнопка при нулевом остатке, и убедиться, что она не выглядит как обычная покупка. 4. Проверить, что срок и условия видны в корзине и на шаге оформления. 5. Описать порядок уведомления при переносе срока и при отказе поставщика. 6. Провести тестовое оформление на стенде и пройти весь путь до отгрузки на тестовом заказе.

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

Отдельно проверяется поведение при частичном поступлении: если пришло меньше единиц, чем заказано, нужно понимать, кто и в каком порядке распределяет товар между заявками. Это организационное решение, и его лучше принять до запуска, а не в момент поставки.

Какие исходные данные подготовить для оценки

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

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

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

Как проверить результат и принять работу

Приёмка идёт по сценариям, а не по внешнему виду страниц. Ниже — рабочий чек-лист.

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

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

Типичные ошибки и ограничения

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

Срок указан только на карточке. В корзине он исчезает, и возникает ощущение подмены. Текст должен сопровождать покупателя до подтверждения заказа.

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

Молчаливый перенос срока. Дата в личном кабинете меняется без уведомления. Это подрывает доверие сильнее, чем сам перенос.

Нет правил при отказе поставщика. Магазин оказывается должен объяснить покупателю то, что сам не решил.

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

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

Если предзаказ затрагивает отображение позиций в каталоге, полезно свериться с материалом про каталог товаров на Битрикс: логика вывода карточек и статусов availability должна быть согласована, иначе покупатель увидит противоречивые сигналы на разных страницах.