Разработка B2B-портала для дилеров и партнёров

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

Что даёт портал и чего от него не ждать

Портал снимает с менеджеров рутину: дилер видит свою цену и остаток, оформляет заказ, получает статус и документы. Менеджер подключается там, где нужен разговор: нестандартная скидка, крупная партия, спорная отгрузка.

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

Разработка B2B-портала для дилеров: что решить до старта

Где живёт правда об остатках. Портал может показывать остатки из учётной системы, из складского сервиса или из собственной базы. Главное — одно место, где ставится резерв. Иначе два дилера оформят один и тот же товар. Мы решали эту задачу в StockFlow: остаток, резерв и «доступно» считаются в одной системе, а сделки остаются в Битрикс24.

Как считается цена. Уровни цен, персональные скидки, акции, валюта, минимальная партия. Цена всегда пересчитывается на сервере при оформлении, а не берётся из браузера.

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

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

Срок брони. Если товар бронируется до оплаты, нужно автоматическое снятие брони по сроку и уведомление менеджеру.

Пример: кабинет агентства в Kvadrum

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

Это тот же принцип, что у дилерского портала: партнёр работает сам, правила задаёт поставщик, CRM остаётся главной системой продаж.

Как устроен портал технически

Сервер на Node.js или Go проверяет права и цены, база PostgreSQL хранит дилеров, заказы и журнал действий, интерфейс на React работает на компьютере и телефоне. Обмен с CRM идёт через REST API: новый заказ создаёт сделку с товарами, смена стадии в CRM меняет статус на портале. С учётной системой обмениваемся по API или файлами по расписанию, в зависимости от того, что она умеет.

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