В первую версию оптовой платформы стоит включить четыре вещи: каталог с упаковками и кратностью, цену именно этого покупателя, заказ списком или файлом и обмен с учётом, который возвращает остатки и статусы. Всё остальное (акции, замены, рекомендации, мобильные приложения) добавляется после того, как покупатели начнут заказывать.
Причина в том, что платформа нужна ради снятия нагрузки с менеджеров, а не ради набора функций. Если покупатель заказывает в ней быстрее, чем по почте, и видит верные цену и остаток, платформа работает. Устройство платформы с примерами правил опта описано на странице «Платформа для оптовой торговли», здесь только то, что включать в первую версию и в каком порядке.
Сначала пять вопросов о ваших покупателях
Состав версии определяют не функции, а ответы на вопросы про реальных покупателей. Возьмите заказы за прошлый месяц и ответьте на примерах, а не по ощущениям.
- Как заказывают сейчас. Файлом, письмом, по телефону, через менеджера в мессенджере. Это покажет, какие способы ввода нужны первыми.
- Сколько позиций в заказе. Если три-пять, хватит обычной корзины. Если несколько десятков, нужен ввод списком и загрузка файла, иначе покупатель вернётся к почте.
- Сколько вариантов цены. Один прайс на всех, прайс по группам или цены по договору. От ответа зависит, откуда платформа берёт цену и что считает сама.
- Что покупатель спрашивает по телефону чаще всего. Наличие, срок, статус отгрузки, документ. Именно это платформа должна показать первым.
- Кто в компании покупателя участвует в заказе. Один закупщик или закупщик, бухгалтер и руководитель с разными правами.
Ответы записываются в виде короткого документа на одну-две страницы. Он становится основой для списка «входит / откладываем» и для разговора с подрядчиком, в том числе чужим.
Что входит в первую версию и что откладывается
Ядро версии — то, без чего покупатель не сможет оформить верный заказ. Остальное добавляется отдельными этапами, и у каждого этапа своя приёмка.
| Часть платформы | Входит в первую версию | Откладываем | Когда возвращаемся |
|---|---|---|---|
| Каталог | Позиции из учёта, упаковки, кратность, минимальная партия, поиск по артикулу и названию | Сложные фильтры по характеристикам, сравнение позиций, подборки | Покупатели жалуются, что не могут найти позицию |
| Цена | Цена покупателя из учёта: прайс группы или договорная цена, с датой актуальности | Скидочные шкалы по сумме заказа, акции, цена в валюте по курсу | Менеджеры вручную пересчитывают скидки в большинстве заказов |
| Заказ | Ввод по артикулу и количеству, загрузка файла, повтор заказа, проверка кратности и остатка | Шаблоны заказов, согласование внутри компании покупателя, распределение по грузополучателям | Покупатели просят |
| Остатки и резерв | Статус наличия или остаток из копии, резерв на время оформления, отметка времени данных | Предзаказ на ожидаемое поступление, остатки по нескольким складам | Склад начинает отгружать из нескольких точек |
| Обмен с учётом | Заказ в учёт, статусы и остатки обратно, очередь и журнал обмена | Обмен с WMS, транспортными компаниями, электронным документооборотом | Статусы по телефону остаются главным вопросом |
| Права и вход | Организации, роли закупщика и администратора, приглашение сотрудников, журнал действий | Корпоративный вход покупателей, настраиваемые роли, права на уровне договоров | Крупный покупатель ставит условием |
| Админка для вашей команды | Список покупателей, группы, блокировка, просмотр журнала | Вход «от имени клиента», отчёты по использованию | Поддержка тратит время на то, что можно автоматизировать |
Строки из столбца «Откладываем» не отбрасываются навсегда. Они записываются в документ с условием возврата, и тогда новая функция оценивается отдельно, а не добавляется молча. Более высокая вилка бюджета появляется ровно тогда, когда в первую версию попадают несколько таких строк сразу.
Что покупатель должен успеть за одну минуту
Хорошая проверка состава версии такая: оптовый покупатель, который знает свои артикулы, должен оформить повторный заказ за одну-две минуты, не обращаясь к менеджеру. Из этого условия следует многое.
- Вход и повтор. Покупатель заходит, видит прошлые заказы и копирует нужный. Цена и остаток проверяются заново, изменения подсвечены.
- Ввод списком. Позицию находят по артикулу, а не по названию. Нужен поиск по артикулам поставщика, покупателя и по штрихкоду.
- Понятные ошибки. Не кратно упаковке, нет в наличии, закрыто для вас: каждое сообщение называет причину и предлагает действие.
- Подтверждение. После отправки заказ получает номер и статус, и покупатель видит, принят ли он учётом.
Если ни одно из этих действий не требует звонка, первая версия выполняет задачу. Что именно показывать на экране кабинета и откуда брать данные, разобрано в статье «Личный кабинет для партнёров: что в него включать».
Какие данные должны быть готовы в учёте до начала
Самая частая причина затянувшегося проекта — платформа готова, а данных, которые она должна показывать, в учёте нет. Проверьте до начала разработки:
- Единицы и коэффициенты. У каждой позиции записаны базовая единица, упаковка и коэффициент пересчёта.
- Кратность и минимальная партия. Они заведены в учёте, а не известны менеджеру.
- Покупатели и группы. Один покупатель заведён один раз, у него указана группа цен и склад отгрузки.
- Договорные цены. Лежат в учёте с датой действия, а не в файле у менеджера.
- Остатки с резервом. Учёт умеет отдавать свободный остаток, а не только остаток на складе.
- Идентификаторы. У позиций, покупателей и договоров есть устойчивые коды, по которым платформа и учёт понимают друг друга.
Если хотя бы одно не выполнено, это не повод отказываться от проекта, а повод включить работу с учётом в первый этап. Как приводить справочники в порядок, описано в статье про нормативно-справочную информацию, а какие данные уходят между платформой и учётом и как, на странице интеграции ERP с B2B-платформой.
Чего не стоит включать, пока покупатели не начали заказывать
- Маркетплейс для сторонних продавцов. Это отдельный продукт: кабинеты продавцов, комиссии, модерация, расчёты. Сначала проверьте на собственном каталоге, что ваши покупатели заказывают онлайн. Такие площадки мы не делаем.
- Онлайн-оплата. В опте чаще работают счёт и отсрочка. Приём платежей добавляется через ваш эквайринг и только если покупателям он нужен.
- Рекомендации и персонализация. Для них нужна история заказов, а её ещё нет.
- Мобильное приложение. Адаптивный интерфейс с установкой на экран закрывает большинство задач. Нативные приложения мы не делаем.
- Конструктор акций и сложные скидочные правила. Сначала выясните, по каким правилам менеджеры действительно скидывают цену, а потом закладывайте их в систему.
- Собственная аналитика. Журнал заказов и данные учёта дают достаточно для первых выводов. Отчёты добавляйте, когда понятно, какие решения по ним принимаются.
Каждая из этих функций оправданна, но на первом этапе она превращает проект на несколько недель в проект на несколько месяцев и делает приёмку размытой.
Как понять, что версия работает
Запускайте на части покупателей, а не на всех сразу: на нескольких постоянных, которые согласились попробовать. Смотрите не на число регистраций, а на поведение.
| Что смотрим | Что значит хорошо | Что значит плохо | Что делаем |
|---|---|---|---|
| Доля заказов через платформу у подключённых покупателей | Растёт, повторные заказы идут без менеджера | Покупатель зашёл, посмотрел и вернулся к почте | Спросить его, на каком шаге остановился |
| Звонки менеджерам об остатках и статусах | Становятся реже | Не меняются | Проверить, видит ли покупатель верные данные и находит ли их |
| Ошибки в заказах после отправки | Исправлений в учёте стало меньше | Менеджер по-прежнему правит кратность и цены | Добавить проверку, которая пропускает ошибку |
| Расхождения платформы и учёта | Редкие и объяснимые | Регулярные, причина неизвестна | Разобрать журнал обмена и ввести ежедневную сверку |
| Заказы, застрявшие в очереди | Единицы и с понятной причиной | Копятся после сбоев учёта | Пересмотреть очередь и оповещения |
Цифры порогов («хорошо» и «плохо») вы задаёте сами до запуска и записываете: у каждой компании они свои. Без заранее названных порогов результат пилота можно толковать как угодно.
Типичные ошибки при запуске
Большинство проблем после запуска повторяются от проекта к проекту.
| Ошибка | К чему ведёт | Как избежать |
|---|---|---|
| Платформа хранит цены отдельно от учёта | Две версии прайса, споры «по какой цене заказывали» | Цена одна, хозяин — учёт; платформа показывает копию |
| Остаток показывают без учёта резерва | Одну позицию продают дважды, менеджеры извиняются перед покупателем | Показывать свободный остаток и записывать резерв при заказе |
| Запуск сразу на всех покупателях | Ошибки в правилах находят покупатели, а не вы | Запуск на нескольких, затем группами |
| Нет сценария на случай сбоя учёта | Покупатель видит пустой экран или устаревшие данные без пометки | Метка времени данных и очередь заказов |
| Права проверяет только интерфейс | Покупатель видит чужую цену через прямой адрес | Проверка прав на сервере и прогон из-под каждой роли |
| Менеджеров не обучили | Они продолжают принимать заказы по почте, и платформа простаивает | Менеджер сам оформляет заказ за клиента в платформе и видит ту же картину |
Больше всего проектов спотыкается на первой и второй строках: это вопросы к учёту, а не к платформе.
Нужен ли заказной вариант или хватит готового
Готовая платформа или модуль интернет-магазина с оптовым режимом подходит, если у вас один прайс на группу, простые правила и нет сложных договорных условий. Заказной вариант оправдан, когда цены по договору, кратность, лимиты, согласование и обмен с учётом нетиповые. Общий подход к выбору описан в статье «Коробочное ПО или заказная разработка».
Если ваша задача ближе к кабинету для дилеров с их документами и сверкой, см. разработку B2B-портала. Если сайт на 1С-Битрикс уже работает и нужен только обмен, посмотрите статью про CommerceML. Почему остатки на витрине расходятся с учётом и как это закрывать резервом и очередью, объяснено в статье про расхождение остатков.
Что делаем мы и с чего начать
Начинаем с обследования: 200 000 ₽ и 2–3 недели за один-два процесса, 350 000 ₽ и 3–4 недели, если платформа связана с несколькими системами и складами. На выходе документ с составом первой версии («входит / откладываем»), правилами опта в проверяемом виде, схемой обмена с учётом и вилкой бюджета. Стоимость вычитается из первого этапа, если продолжаете с нами, а документом можно пользоваться и без нас.
Дальше, если нужно, лёгкий пилот на одном сценарии (150 000–400 000 ₽, 2–8 недель) либо первая версия на одном потоке заказов как тяжёлый пилот (400 000–1 200 000 ₽, 2–3 месяца); на любой ступени можно остановиться. Мы делаем один контур, а не платформу за десятки миллионов, не делаем маркетплейсы со сторонними продавцами и мобильные приложения, не дежурим круглосуточно. Исходники лежат в вашем репозитории с первого коммита. Все цены и сроки — на странице «Тарифы», описание услуги — на странице «Платформа для оптовой торговли».
Частые вопросы
Что обязательно должно быть в оптовой платформе?
Каталог с упаковками и кратностью, цена покупателя из учёта, быстрый заказ списком или файлом и обмен с учётом, который возвращает остатки и статусы. Без этого платформа не снимает нагрузку с менеджеров.
Нужна ли онлайн-оплата в оптовой платформе?
Не обязательно. В опте чаще работают счёт и отсрочка. Приём платежей подключается через ваш эквайринг, если покупателям он нужен; данные карт платформа не хранит.
Сколько стоит первая версия оптовой платформы?
Обследование стоит 200 000 ₽ (350 000 ₽ при нескольких системах). Лёгкий пилот одного сценария — 150 000–400 000 ₽ за 2–8 недель, первая версия на потоке заказов — 400 000–1 200 000 ₽ за 2–3 месяца. Простой кабинет или витрина данных начинается от 250 000 ₽.
Что отложить, чтобы уложиться в срок?
Акции и скидочные шкалы, сравнение позиций, предзаказы, обмен с WMS и перевозчиками, корпоративный вход покупателей, отчёты. Все они записываются в список «откладываем» с условием возврата.
Можно ли сначала проверить спрос без платформы?
Да. Выберите нескольких постоянных покупателей и принимайте заказы через общую таблицу или форму, а остатки и статусы отправляйте вручную. Станет видно, какие данные они просят и какие вопросы задают.
Нужен ли свой маркетплейс, чтобы продавать в опте?
Нет. Для продажи со своего склада нужен закрытый оптовый каталог. Маркетплейс со сторонними продавцами — другой продукт с кабинетами продавцов, комиссиями и расчётами, мы такие площадки не делаем.
Что делать, если справочники в учёте в беспорядке?
Начать со справочников. Платформа показывает данные из учёта, поэтому единицы, кратность, группы цен и договоры сначала приводят в порядок. Это можно сделать в первом этапе проекта.
Как не потерять данные и права при смене подрядчика?
Исходный код лежит в вашем репозитории с первого коммита, развёртывание описано инструкцией, правила опта и источники данных записаны документом. С ними платформу может принять другой подрядчик.