B2B-портал заказов для дистрибьюторов: гид

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

Что такое B2B-портал заказов?

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

Портал стоит отделить от трех соседей, с которыми его часто путают:

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

Раздел личного кабинета на маркетинговом сайте. Полезен для загрузок и тикетов поддержки, но без логики каталога, ценообразования и заказов не убивает ни единого звонка в отдел продаж.

PDF-прайс-лист по почте. Состояние, в котором живет большинство дистрибьюторов до портала: точный в день отправки, неверный к следующей неделе и непоисковый для каждого аккаунта.

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

Таблица функций: должно, желательно, потом

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

Таблица A: функция | назначение | фаза (1/2/3) | зависимость от ERP

Функция	Назначение	Фаза	Зависимость от ERP
Клиентские аккаунты и вход	Каждый дистрибьютор видит только свои данные	1	Аккаунты и контакты
Прайс-листы по аккаунту	Контрактные цены, ценовые группы или поэтапное ценообразование по аккаунту	1	Прайс-листы и ценовые группы
Каталог с видимостью по аккаунту	Товары, которые может покупать каждый аккаунт, с документами и изображениями	1	Номенклатура, правила аккаунт-товар
Быстрый заказ и повторный заказ	Артикулы, CSV или панель загрузки, повтор последнего заказа	1	Номенклатура, правила минимального заказа
Отправка заказа в ERP	Заказ становится документом ERP, а не письмом	1	API заказов или канал интеграции
Статус заказа и видимость документов	Инвойсы, кредит-ноты, поставки видны по аккаунту	2	Архив документов или финансовая система
Котировки и переход котировки в заказ	Запрос цены, согласование, превращение в заказ	2	Документы-котировки в ERP
Кредитные лимиты и отсроченные условия	Показывать аккаунту его позицию и условия; блокировать отправку заказа вне правил	2	Кредитные данные и условия в ERP
Платежи в портале	Онлайн-расчет против инвойсов или заказов	3	Платежный шлюз плюс сверка в ERP
Роли согласования заказа	Покупатель предлагает, согласователь выпускает, лимиты по ролям	3	Данные согласований или воркфлоу на стороне портала
Многоязычный каталог и документы	Торговый язык по рынку или по аккаунту	3	Переводы товаров, шаблоны документов
Отслеживание и уведомления об отгрузке	Статус отгрузки без звонка в отдел продаж	3	Логистические данные или данные перевозчика

Фаза 1 — это релиз, меняющий поведение: если дистрибьютор может войти, увидеть свои цены, повторить заказ прошлого месяца и провести его в ERP, телефон и таблица начинают закрываться сами. Фазы 2 и 3 добавляют денежный и управленческий слои, для которых решения организации о кредитах, финансах и согласованиях должны быть приняты до того, как программное обеспечение сможет их удержать.

Интеграция с ERP и CRM

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

Направление синхронизации. Мастер-данные — аккаунты, товары, цены, условия — идут из ERP в портал. Заказы, запросы цен и платежи идут обратно. Все остальное требует явного владельца: кто может изменить цену и где живет это изменение?

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

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

Сверка. Как вы знаете, что каждый заказ портала стал ровно одним документом ERP, — без дублей, без пропусков, без наполовину преобразованных записей? Ответ — операционный отчет, который кто-то читает ежедневно в первые месяцы, и это один из тестов приемки ниже.

Два типовых паттерна развёртывания покрывают большинство проектов. Путь «ERP-native» строит портал как расширение собственных возможностей ERP, что минимизирует число систем, которые должны сходиться, но наследует ограничения интерфейса ERP. Путь «платформа» поднимает коммерческую платформу — в материале вендоров обычно приводятся Shopify и подобные системы, — и соединяет ее с ERP через промежуточное ПО или коннекторы; этот маршрут покупает гибкость интерфейса и знакомую админ-панель ценой еще одной системы, которую нужно держать в синхронизации. Вопрос кастомного или коробочного ERP разбирает более широкую версию этого выбора между строить и покупать, а чек-лист RFP для вендоров превращает оба варианта в вопросы, которые можно оценить в предложении.

Многоязычные и многовалютные каталоги

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

Языки. Каталогу нужны переводы названий товаров, категорий и документов; структуре аккаунтов — предпочтительный язык по аккаунту, чтобы портал не заставлял одного и того же покупателя выбирать его при каждом визите. Два практических пункта: решите, кто владеет переводами и каков их ритм обновления, — наполовину переведенный каталог хуже для заметившего это покупателя, чем вовсе англоязычный, — и решите, идут ли документы (котировки, инвойсы) за языком интерфейса или остаются на языке, которого требует ваша финансовая система. Второй вопрос не технический: инвойс на неверном языке — бухгалтерская проблема.

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

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

Безопасность и роли

Портал — это дверь в ваши коммерческие данные, поэтому вопросы дизайна — это вопросы доступа:

Доступ выдается, а не регистрируется самостоятельно. Каждый аккаунт создается вашей командой против аккаунта в ERP; альтернатива — открытая регистрация со ступенькой согласования — приглашает шум и размывает, кто является клиентом.

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

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

Аудиторский след. Кто оформил заказ, кто его согласовал, кто изменил цену и когда, — хранится как данные, а не как лог-файлы, к которым надо кого-то уговаривать читать. Споры в торговле улаживает этот след чаще, чем память.

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

Защита данных. Данные клиентов в портале подпадают под те же обязанности, которые компания уже несет по своим клиентским записям; для турецких операций это рамка KVKK, для европейских клиентов — GDPR, тема, подробно разобранная на странице аутсорсинга в контексте работы с партнером по разработке.

Стройка против платформы

Выбор не в абстрактном противостоянии кастомного и коробочного; речь о том, какой слой вы на самом деле покупаете.

Таблица B: маршрут | что получаете | что несете | подходит когда

Маршрут	Что получаете	Что несете	Подходит когда
Портал на базе ERP	Одна система-рекорд, цены и кредит уже согласованы, меньше интерфейсов	Интерфейс и мобильность ограничены возможностями самой ERP; циклы релизов ERP управляют порталом	ERP современная, ее модуль покрывает большинство фазы 1, а внутренняя ИТ может администрировать его
Коммерческая платформа + коннектор к ERP	Знакомая админка, сильный интерфейс и мобильный опыт, быстрая работа каталога	Вторая система для удержания в синхроне; обслуживание коннектора; два пути обновления	Покупательский опыт важен не меньше данных, и кто-то долгосрочно владеет интеграцией
Кастомный портал	Точное попадание в коммерческие правила, включая странные, которые определяют вашу торговлю	Полная ответственность: безопасность, производительность, обновления, весь жизненный цикл	Процесс по-настоящему отличает бизнес, и ни одна платформа его не несет; тест — подошла бы ли стандартная функция плюс изменение процесса

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

Поэтапный запуск и тесты приемки

Запуск портала падает молча, когда «работает» означает «работало демо». Каждая фаза должна нести письменные тесты приемки, проведенные с реальными аккаунтами и реальными данными:

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

Точность ценообразования. Для выборки аккаунтов и артикулов цена в портале равна цене в ERP, — включая лежащие в основе правила (ценовая группа, уровень, соглашение). Это тот тест, который защищает коммерческие отношения: неверная цена в портале хуже неверной цены в котировке, потому что клиент увидел ее как действующее соглашение.

Целостность заказа. Заказ, оформленный в портале, становится ровно одним документом ERP с верными артикулами, количествами, единицами и ценами, и отчет о сверке это показывает. Проверьте и путь отказа: заказ, заблокированный правилом, должен четко об этом сказать, а не молча упасть.

Статус и документы. Инвойс и поставка, записанные в ERP, появляются в представлении нужного аккаунта с нужным статусом в согласованное окно синхронизации.

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

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

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

Часто задаваемые вопросы

Нужен ли нам сначала ERP?

Не обязательно новая, — но мастер-данные должны быть где-то надежными: аккаунты, товары, прайс-листы и условия. Если они живут только в таблицах, портал автоматизирует ошибки таблиц по каждому аккаунту, что хуже, чем оставаться на телефоне. В этом случае честная последовательность — сначала стабилизировать данные (часто в существующей ERP, которой мало пользуются), а портал уже после; страница про Odoo для торговых компаний разбирает это решение с стороны ERP.

Могут ли клиенты иметь собственные прайс-листы?

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

Как согласуются заказы?

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

Может ли портал работать на нескольких языках?

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

Кому принадлежат данные?

Вам — аккаунты, цены, заказы, документы и история остаются записями компании в ERP. Это стоит указать в договоре с тем, кто строит портал: доступ к хостингу, исходный код или конфигурация и выгрузка ваших данных при выходе, — все названо. Страница аутсорсинга покрывает интеллектуальную собственность и условия выхода в более широком контексте договора на разработку.

Как вводить дистрибьюторов?

Начните с аккаунтов с наибольшими заказами, пригласите их лично и дайте три вещи в первом сообщении: их доступ, их прайс-лист, видимый на экране, и одного человека, кому звонить. Затем следите за сигналом вовлечения, который действительно важен, — не за входами, а за долей повторных заказов, приходящих через портал. Параллельная работа (заказ через портал, затем подтверждение по телефону) нормальна неделями; она заканчивается, когда портал доказуемо верен в ценах и документах, и для этого и нужны тесты приемки выше.

Источники и стандарты

Описанный здесь типовой набор функций (аккаунты, прайс-листы по аккаунту, повторные заказы, инвойсы и кредит-ноты, видимость по аккаунту, роли с лимитами, отсроченные условия, платежные шлюзы) следует описаниям возможностей вендоров для B2B-порталов заказов в целом; на этой странице не заявляется ни один показатель результативности, стоимость или срок.
Паттерны развёртывания (портал на базе ERP; коммерческая платформа вроде Shopify, синхронизируемая с ERP через промежуточное ПО или коннекторы) описаны как два повторяющихся маршрута; партнерства ни с одним вендором платформы не заявляется.
Утверждения о процессе и управлении следуют страницам этого сайта: кастомный против коробочного ERP, чек-лист RFP для вендоров, Odoo для торговых компаний и ИТ-аутсорсинг из Турции (обязательства по защите данных, IP и условия выхода, дизайн пилота).
На этой странице нет ни примеров клиентов, ни бюджетов порталов, ни длительностей проектов; область, фазирование и коммерческие условия задаются в предложении по проекту.

Связанные страницы

Разработка ПО · Кастомный против коробочного ERP · Чек-лист RFP для вендоров · Odoo ERP для торговых компаний · Интернет-маркетинг · Запросить КП