Вернуться к статьям У продуктового каталога много переменных: весовой товар, фасовка, упаковки разного объёма, сезонные позиции, скоропортящиеся продукты, товары с ограничениями по продаже. Если не описать эти условия до проектирования, после запуска появятся ручные корректировки заказов, спорные статусы и расхождения между сайтом и фактическим наличием.
Ассортимент продуктового интернет-магазина
Количество товаров само по себе мало говорит о сложности каталога. Один магазин продаёт фиксированные упаковки, другой — овощи и мясо по весу, третий собирает наборы из нескольких позиций. Внешне карточки могут выглядеть одинаково, но правила расчёта и оформления будут разными.
Для каждой товарной группы нужно определить:
- единицу продажи: штука, упаковка, килограмм, набор;
- допустимый шаг количества;
- варианты товара: вкус, объём, вес, тип упаковки;
- сведения, обязательные для карточки;
- признак временного отсутствия и действие для покупателя;
- возможность замены товара или отказа от отдельной позиции;
- зависимость цены и доступности от региона, склада или типа покупателя.
Отдельного решения требуют товары с примерным весом. На сайте можно показать ориентир, но в заказе должно быть понятно, что произойдёт при фактическом взвешивании: изменится ли сумма, потребуется ли подтверждение, как отобразится разница в составе заказа. Это правило фиксируют и в пользовательском сценарии, и в инструкции для сотрудников, собирающих заказ.
Каталог продуктов: категории, фильтры и карточки
Структура каталога должна соответствовать тому, как покупатель ищет продукты. Раздел «Бакалея» понятен для ассортимента, но не всегда отвечает на вопрос, где искать крупу, соус или готовый завтрак. До разработки составляют карту категорий и проверяют её на реальных товарах.
Фильтры строят по данным, которые поддерживаются в актуальном состоянии. Если у товара нет надёжно заполненного признака, фильтр покажет неполный результат. Это относится к бренду, типу продукта, составу и другим параметрам, по которым предполагается подбор.
Карточка продукта не должна быть универсальным шаблоном без учёта ассортимента. Для части товаров достаточно изображения, названия, веса и цены. Для других нужны характеристики, условия хранения, состав, варианты фасовки, документы или связанные позиции. Заранее согласуют набор полей и источники данных: кто добавляет сведения, как исправляются ошибки, что поступает из учётной системы и что заполняет редактор сайта.
Остатки и доступность товаров в интернет-магазине
Показатель «в наличии» слишком груб для продуктового магазина. Товар может быть доступен на одном складе и отсутствовать на другом, продаваться только в определённой зоне доставки или резервироваться после оформления заказа. Если покупатель видит общую доступность, а сборщик не может выполнить заказ, проблема возникает после оплаты или подтверждения.
В требованиях к каталогу фиксируют источник остатков, состав передаваемых данных и момент обновления. Отдельно описывают поведение сайта, если данные не поступили, товар исчез во время оформления или фактическое количество оказалось меньше заказанного. Возможные сценарии различаются: запрет добавления в корзину, предложение замены, частичная сборка или передача вопроса сотруднику. Выбор зависит от внутренних правил магазина, а не от оформления карточки.
Если планируется обмен с внешней системой, формулировки «синхронизировать товары и заказы» недостаточно. Нужны перечень полей, правила сопоставления товаров, направление передачи, порядок повторной отправки и ответственный за разбор ошибок. Иначе одинаковые названия позиций, упаковки и варианты товара могут трактоваться по-разному.
Доставка продуктов: зоны, интервалы и состав корзины
Доставка в продуктовом магазине зависит не только от адреса. На доступные варианты могут влиять вес и состав корзины, температурный режим товаров, минимальная сумма, выбранная дата, район, загруженность сборки или наличие позиции на конкретном складе. Эти зависимости перечисляют до проектирования оформления заказа.
Путь покупателя следует разобрать по шагам: ввод адреса, проверка зоны, выбор способа получения, выбор интервала, подтверждение состава, оформление. Для каждого шага определяют, какие данные уже известны и что может изменить следующий экран. Например, адрес может ограничить набор интервалов, а добавление замороженных продуктов — изменить способ доставки.
Особое внимание требуется текстам об ограничениях. Покупатель должен видеть причину недоступности без технических формулировок: товар не доставляется в выбранную зону, интервал недоступен для состава корзины, заказ требует уточнения. Логика зависит от проекта, но сообщение на сайте не должно заменять причину общим уведомлением об ошибке.
Оформление заказа и замены товаров
Продуктовый заказ может измениться после отправки. Часть позиций отсутствует, цена весового товара отличается от предварительной, покупатель разрешает или запрещает замены. Эти правила влияют на состав формы заказа, статусы и информацию для сотрудника.
До разработки определяют допустимые варианты замены: аналог того же бренда, товар другой марки, позиция в иной фасовке или только согласование с покупателем. Также устанавливают, где хранится это решение и как оно отображается при сборке. Если разрешение на замену существует только в комментарии, его легко пропустить.
Сценарий изменения заказа описывают целиком: кто видит проблему, как фиксируется отсутствие, что происходит с заменённой позицией, как пересчитывается итог, может ли покупатель отменить заказ или отдельный товар. Это не относится к возможностям CMS как таковым. CMS сайта обеспечивает работу каталога и оформления, а внутренние действия сотрудников и обмен с другими системами задаются отдельно.
Ограничения каталога и выбор технического решения
Техническое решение выбирают после того, как понятны правила торговли, а не по названию платформы. Если для проекта рассматривают «1С-Битрикс: Управление сайтом», для обсуждения нужны структура каталога, примеры карточек, источник товарных данных, сценарии доставки и перечень нестандартных ограничений. CMS сайта не заменяет описание этих правил и не является CRM.
Ограничения каталога собирают в отдельный перечень. В него могут входить запрет на продажу отдельных товаров в определённых зонах, разные единицы измерения, наборы, зависимые товары, скрытие части ассортимента, особые условия заказа и различия для групп покупателей. Для каждого пункта определяют источник условия, место проверки и сообщение, которое увидит покупатель.
На основе этого перечня формируют первую очередь работ: в неё включают правила, без которых каталог, корзина и оформление заказа не смогут работать по принятому сценарию. Пожелания к интерфейсу и функции, не влияющие на оформление заказа, фиксируют отдельно для последующих изменений.
Часто задаваемые вопросы
Как подготовить каталог продуктов к разработке?
Соберите примеры реальных категорий и карточек: названия, фотографии, описания, характеристики, вес, варианты упаковки, цены, остатки и связанные товары. Отдельно отметьте, какие данные уже существуют и кто отвечает за их актуальность.
Что делать с весовыми товарами?
Нужно описать единицу продажи, шаг заказа, способ показа ориентировочного веса и действия при фактическом отличии веса. Заранее определяют, допускается ли изменение итоговой суммы и как покупатель узнаёт об этом.
Можно ли настроить доставку по районам?
Да, если в требованиях есть источник зон, способ проверки адреса и правила для каждого района. Следует определить, что произойдёт при адресе вне зоны, недоступном интервале или корзине, для которой действует отдельное ограничение.
Как учитывать отсутствие товара после оформления заказа?
Сценарий зависит от правил магазина: возможны замена, частичная сборка, согласование с покупателем или отмена позиции. Решение фиксируют в заказе так, чтобы его видел покупатель и сотрудник, работающий со сборкой.
Нужна ли интеграция с учётной системой?
Она нужна, когда товарные данные, остатки или заказы должны передаваться между системами. Для постановки задачи перечисляют передаваемые поля, правила сопоставления, момент передачи и порядок действий при ошибке обмена.