B2B-портал для дилеров: функции, интеграция с 1С и стоимость первой версии

Зачем бизнесу отдельный дилерский контур

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

Текущая поисковая выдача по разработке B2B-порталов показывает устойчивый набор ожиданий. Letary описывает роли и связи с CRM и 1С, а BB Studio — технический каталог производителя, сертификаты, кабинет дилера и запрос коммерческого предложения. Это предложения самих подрядчиков, а не доказательство результата. Но они хорошо показывают, что покупатель ищет не «ещё один сайт», а новый порядок работы с партнёрами.

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

Сценарий важнее списка функций

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

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

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

Обмен с 1С — это договор о данных

В методическом примере 1С сайт и база обмениваются сообщениями через 1С:Шину, с отдельной настройкой адреса, ключей и проверки запросов. Конкретный проект может использовать другой механизм, но смысл тот же: портал не читает «1С вообще». Две системы обмениваются заранее определёнными объектами по известным правилам.

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

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

Что включить в первую рабочую версию

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

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

1. Вход сотрудников дилера, привязку к организации, роли и отзыв доступа у уволенного сотрудника.
2. Каталог с характеристиками и документами, доступными конкретной группе партнёров.
3. Персональные цены и понятную дату актуальности остатков.
4. Создание и повтор заказа, подтверждение получения и защита от дублей.
5. Статус исполнения, счета или накладные, если эти данные действительно приходят из учётной системы.
6. Рабочее место сотрудника, который видит ошибки обмена и может помочь дилеру без потери контекста.
7. Журналы важных действий, мониторинг интеграции, резервные копии и проверяемый выпуск обновлений.

Почему две сметы с одинаковым названием не сравнимы

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

В действующем прайсе pommeDeTerre первая версия веб-сервиса начинается от 300 000 ₽ и предполагает до пяти основных сценариев, авторизацию и запуск для ограниченной группы. Это ориентир нижней границы, а не цена любого дилерского портала: интеграция с 1С, сложные цены, документы и несколько ролей могут перевести проект в следующий объём. Точную оценку можно дать только после проверки данных и рискованного обмена.

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