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