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