Сайт дистрибьютора: как разделить открытый каталог и оптовый доступ

Зачем дистрибьютору два уровня доступа

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

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

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

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

Разделите посетителей по рабочим задачам

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

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

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

Уточните, продаёт ли компания конечным покупателям. Если розничные заявки не обрабатываются, это нужно объяснить до формы. Если дистрибьютор направляет таких посетителей к партнёрам, предусмотрите понятный путь. Закрытый прайс сам по себе не объясняет, кому компания готова продавать.

Что оставить в открытом каталоге

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

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

Таблица показывает варианты проектирования, а не обязательное правило публикации. Некоторым компаниям нельзя открывать подробные остатки или отдельные документы. Решение должно иметь владельца и объяснение. Пометка «закрыто» без перечня каналов доступа не гарантирует, что сведения не попадут в выгрузку или файл.

Как выдавать доступ новым партнёрам

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

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

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

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

С кем связаны условия и полномочия

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

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

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

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

Выберите форму оптового обращения

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

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

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

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

Проверьте источники каталога и условий

Для каждой группы данных назначьте источник и владельца. Характеристики могут поступать от производителя, цены — из учётной системы, а описания — редактироваться маркетологом. При нескольких источниках нужно заранее решить, что произойдёт при противоречии. Регулярная загрузка не должна стирать согласованные тексты без установленного правила.

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

Согласуйте обработку временно недоступного источника. Можно ли показывать последние подтверждённые сведения и с какой пометкой? Следует ли временно заменить оформление запросом менеджеру? Решение зависит от риска неверного обещания и должно быть принято до сбоя, а не в момент обращения недовольного партнёра.

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

Как принять границу открытого и закрытого

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

• Гость понимает ассортимент и порядок получения условий.
• Неодобренный аккаунт не видит закрытые коммерческие сведения.
• Два клиента получают только свои условия и историю.
• Прямые ссылки и скачиваемые документы соблюдают те же ограничения.
• После прекращения доступа закрытые действия недоступны.
• Переключение организации явно меняет контекст закупки.

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

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

Что подготовить для оценки разработки

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

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

Подготовить общий документ поможет статья о техническом задании на сайт, а требования к поиску артикула — материал о поиске по сайту. Для обсуждения со ШТАБ ИТ достаточно начать с карты доступа и обезличенного примера закупки: по ним видны ключевые зависимости и вопросы для оценки.