B2B-портал для оптовых клиентов: когда он нужен и что включить в первую версию

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

B2B-портал — это рабочее пространство для клиентов компании, например для оптовых покупателей. В нём могут оформлять заказы, видеть доступные сведения и следить за выполнением. Я бы начинал его разработку с одного повторного заказа: что клиент сможет сделать сам и где по-прежнему потребуется менеджер.

Какой процесс вы хотите передать клиенту

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

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

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

Чем портал отличается от розничного магазина

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

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

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

Когда портал пока не нужен

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

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

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

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

Что включить в первую очередь

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

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

Не переносите все внутренние состояния в кабинет. Покупателю нужно понимать, получена ли заявка, требуется ли уточнение и что происходит дальше. Название внутреннего этапа «проверка №2» этого не объясняет. Составьте небольшое соответствие между рабочими и клиентскими состояниями.

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

Как согласовать роли и обмен

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

Проверьте границы доступа на примерах

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

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

У каждого вида данных нужен определённый источник

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

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

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

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

Как проверить запуск на ограниченной группе

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

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

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

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

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

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

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