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