B2B-портал и система заказов для контрагентов

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

Когда B2B-портал имеет смысл?

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

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

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

B2B-портал, API, интеграция или CRM?

Эти решения могут работать вместе, но означают не одно и то же.

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

Что может включать портал для контрагентов?

Мы подбираем объём под реальный процесс продаж. В него могут входить:

Индивидуальное предложение для контрагента

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

Наличие и правила оформления заказов

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

Корзина или форма заказа

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

Статусы и документы

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

Роли и права доступа

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

Интеграции

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

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

Главные решения до начала работ

Где находится основное предложение?

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

Что на самом деле означает наличие?

Остаток может измениться между показом предложения и приёмом заказа. Мы определяем, должна ли система резервировать товар, сразу подтверждать заказ или передавать его на последующую проверку.

Кто может просматривать и изменять данные?

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

Что происходит после отправки заказа?

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

Как обрабатываются ошибки и повторные попытки?

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

Как мы проверяем работу первого этапа?

Критерии приёмки следуют процессу, а не только внешнему виду экранов. Для примерного портала можно проверить, что:

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

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

Можно начать с меньшего объёма

Полный портал не обязательно создавать за один этап. Первая версия может охватывать:

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

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

Опыт: HUB-2-API

В 2018 году мы создали систему для компании, продававшей автомобильные детали на немецком рынке. HUB-2-API импортировал большой список товаров из Excel, публиковал и редактировал предложения на eBay.de, получал заказы и предоставлял панель для их обработки.

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

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

Прочитайте полное описание проекта HUB-2-API.

Как мы начинаем сотрудничество?

1. Кратко уточняем потребность. Бесплатный разговор длительностью до 20 минут помогает определить, кто оформляет заказы, где находится предложение и какая часть процесса сейчас создаёт главную проблему. Это не анализ и не готовая оценка.
2. Определяем, нужен ли анализ. При большом количестве ролей, ценовых правил, источников данных или неопределённых интеграциях предлагаем отдельный платный этап. Если позднее проект реализует Domin Software, оплаченную стоимость анализа мы засчитываем в общую стоимость проекта.
3. Выбираем первый полезный этап. Фиксируем объём, ответственность систем, важные исключения, критерии приёмки, срок и индивидуальную оценку стоимости.
4. Создаём и проверяем весь поток. Тестируем не только корректный заказ, но и отсутствие данных, изменение наличия, повторную попытку и ошибку соединения.
5. Согласовываем дальнейшее развитие и поддержку. Следующие группы контрагентов, функции и интеграции выполняются как отдельно согласованные этапы.

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

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

Заменит ли B2B-портал нашу CRM или ERP?

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

Могут ли разные контрагенты видеть разные цены и товары?

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

Могут ли портал и API работать вместе?

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

Можно ли использовать данные из Excel?

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

Сколько стоит B2B-портал и сколько длится реализация?

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

Нужно ли сразу переводить в портал всех контрагентов?

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

Что отправить в первом сообщении?

Опишите:

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

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

CTA: Опишите процесс оформления заказов

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

Смотрите также интеграции систем и API, CRM и системы обработки заказов на заказ и бизнес-анализ и объём MVP приложения.

Документы в процессе контрагента

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