B2B приложение для оптовых продаж

Задача / повторная закупка

Клиенту нужен свой заказ.
Менеджеру — понятные исключения.

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

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

Модельный сценарий / поставщик упаковки

Повторить закупку —
не значит скопировать старые условия.

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

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

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

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

До разработки / правила продаж

Зафиксируйте, какие условия
кому разрешено видеть.

• Персональные цены. Как определяется прайс: по компании, договору или группе клиентов? Кто может изменить цену и нужно ли подтверждение менеджера?
• Упаковка и минимум заказа. Можно ли заказать одну штуку, если отгрузка идёт коробками? Минимум считается по позиции или по сумме?
• Остатки. Что показываем покупателю: физическое наличие, доступный к продаже остаток или только статус «уточнить»? Когда обновлялись эти сведения?
• Резерв. Корзина ещё не означает, что товар закреплён за клиентом. Определите, на каком шаге создаётся резерв и что происходит при отказе.
• Роли. Закупщик, руководитель и менеджер могут видеть разные данные. Проверьте доступ сотрудников одной компании к её заказам и условиям.

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

Интеграция / источник данных

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

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

Например, в официальном описании «1С:Управление торговлей» предусмотрены типовые и индивидуальные соглашения с клиентами, а также контроль заказов на соответствие условиям. Поэтому при интеграции нужно выяснить, какие соглашения действительно используются в вашей конфигурации. Это возможность указанного продукта 1С, а не обещание готового подключения к любой базе.

Источник: управление продажами в «1С:Управление торговлей» ↗

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

Первая версия / границы проекта

Сначала один полный цикл.
Затем дополнительные каналы продаж.

Стоимость B2B приложения зависит не только от числа экранов. Для оценки нужны правила заказов, роли и границы интеграции. На странице стоимости есть ориентиры BORNLI; принадлежность вашего проекта к типовому объёму нужно подтвердить отдельно. Фиксированную цену за интеграцию без её разбора здесь не обещаем.

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

Обсуждение / что подготовить

Пришлите один типичный заказ
и одну сложную ситуацию.

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

• Как покупатель передаёт заказ сейчас и где менеджер вручную переносит данные?
• Что отличается у двух ваших клиентов: цена, ассортимент, отсрочка или доступные склады?
• Какая ситуация требует звонка: замена, изменение количества, отсутствие товара или согласование суммы?
• Что для вас означает «заказ принят» и кто вправе подтвердить этот статус?

Используйте обезличенные примеры: без телефонов клиентов, коммерческих условий конкретных контрагентов и паролей. Обсудить разработку можно через форму BORNLI.