Провал B2B-портала начинается не с неверного выбора платформы, а с неверного скоупа и грязных данных в ERP. Этот playbook даёт фреймворк «данные → процесс → метрики»: как провести аудит 1С до старта разработки, что включить в Phase 1, что вынести за скоуп — и как измерить, что MVP работает, прежде чем масштабировать. Когда B2B-портал становится приоритетом Есть несколько триггеров, после которых откладывать портал становится дороже, чем строить: • Рост «где мой заказ»-звонков. Если менеджеры тратят больше 20% рабочего времени на статусные запросы — это прямой сигнал: клиенты хотят самообслуживания, а не звонков. • Уход менеджера с клиентской базой. Когда история заказов, договорённости по ценам и контакты хранятся в голове одного человека — это операционный риск, не кадровый. • Требование дилеров к самообслуживанию. Крупные дилеры всё чаще выбирают поставщика по наличию портала — не потому что хотят «цифровизации», а потому что хотят оформить заказ в 22:00 без звонка. • Ошибки в заказах растут. Неверная цена, неверный остаток, пересортица — симптом того, что данные из 1С передаются через менеджера, а не напрямую. Если хотя бы два из четырёх триггеров актуальны — скоуп MVP стоит начать определять сейчас. Шаг 0: аудит данных в 1С до написания строчки кода Это самый недооценённый этап. Большинство проектов согласовывают скоуп, выбирают платформу и уходят в разработку — и только через два месяца обнаруживают, что номенклатура в 1С содержит 40% дублей, а типы цен не соответствуют реальным договорным условиям. Чеклист аудита данных в 1С/ERP перед стартом: • Номенклатура. Есть ли единый артикул для каждой позиции? Нет ли дублей с разными наименованиями? Заполнены ли обязательные атрибуты (единица измерения, группа, статус активности)? • Типы цен. Сколько активных типов цен в базе? Есть ли «мусорные» типы, которые не используются, но не удалены? Привязаны ли типы цен к договорам контрагентов? • Договоры и контрагенты. Актуальны ли договоры в 1С — или часть клиентов работает «по устной договорённости»? Есть ли у каждого контрагента корректный ИНН и реквизиты? • Остатки. Насколько часто обновляются остатки в 1С? Есть ли расхождение между физическим складом и учётной системой? • Статусы заказов. Есть ли в 1С чёткая статусная модель заказа, которую можно транслировать в портал? Или статус — это текстовое поле, которое каждый менеджер заполняет по-своему? Грязные данные по любому из этих пунктов делают интеграцию в 2–3 раза дороже. Это не преувеличение: каждый «грязный» тип цен — это дополнительная логика маппинга, которую нужно написать, протестировать и поддерживать. Phase 1 / Phase 2 / Отложить: таблица приоритизации Главный инструмент ЛПР при согласовании скоупа — явная таблица с обоснованием через бизнес-ценность, а не через техническую сложность. Функция | Phase | Бизнес-ценность | Зависимость от данных | Риск без этого Каталог с персональными ценами | 1 | Клиент видит свои условия без звонка | Чистые типы цен и договоры в 1С | Клиент звонит менеджеру — нагрузка не снижается Оформление заказа и reorder | 1 | Самообслуживание 24/7, повторный заказ в 2 клика | Актуальные остатки из 1С | Портал не заменяет звонок, adoption = 0 Статус заказа в реальном времени | 1 | Снижает «где мой заказ»-обращения на 40%+ | Статусная модель в 1С | Главный триггер не закрыт История заказов и документы (счёт, УПД) | 1 | Снижает «пришлите счёт»-запросы | Документооборот в 1С | Менеджеры продолжают пересылать PDF вручную Регистрация и базовая авторизация (одна роль) | 1 | Предусловие для всего остального | Справочник контрагентов в 1С | — Сложная ролевая модель (покупатель / согласующий / финансист) | 2 | Нужна крупным клиентам с внутренним согласованием | Зависит от результатов пилота | Без неё пилот работает нормально Мобильное приложение | 2 | Удобство для выездных закупщиков | Подтверждённые сценарии из Phase 1 | B2B-клиенты заказывают с десктопа Кастомный аналитический дашборд | 2 | Инсайты по заказам клиента | Накопленные данные портала (3+ месяца) | Нечего анализировать на старте Маркетинговые инструменты (промо, баннеры, рассылки) | Отложить | Маркетинговая задача, не операционная | — | Портал решает cost-to-serve, не лидген Полный электронный документооборот (ЭДО) | Отложить | Ценно, но требует отдельного проекта | Интеграция с оператором ЭДО | Базовые PDF из 1С закрывают 80% запросов Кредитный лимит и управление задолженностью | Отложить | Нужно финансовому директору клиента | Финансовый учёт в 1С | Можно добавить в Phase 2 по запросу пилота Матрица выбора: купить готовое / low-code / кастом Выбор платформы зависит от двух параметров: объём активной номенклатуры и глубина интеграции с 1С. Сценарий | Объём SKU | Логика цен | Рекомендация Стандартный дистрибьютор | до 5 000 | Прайс-лист + скидка | Готовое решение или low-code платформа Средний производитель / дистрибьютор | 5 000–20 000 | Индивидуальные договорные цены | Low-code + кастомный коннектор к 1С Крупный производитель / сложный каталог | 20 000+ | Матричные цены, несколько складов, серийный учёт | Кастомная разработка или глубокая кастомизация платформы Важная оговорка: «готовое решение» не означает «без интеграции». Интеграция с 1С — это ядро продукта в любом из трёх сценариев, а не опция. Сценарий пилота: 5–10 клиентов за 4 недели Запускать портал сразу на всю клиентскую базу — классическая ошибка. Пилот на малой группе позволяет дёшево исправить UX и интеграционные баги до того, как они стали системными. Как выбрать участников пилота: • Регулярные заказы (не разовые покупатели) — нужна частота для накопления метрик • Лояльность к компании — готовы дать честную обратную связь, а не просто уйти • Разный размер заказа: малый, средний, крупный — чтобы увидеть разные сценарии использования • Не самые крупные клиенты — цена ошибки слишком высока • Не проблемные клиенты — получите шум вместо сигнала Структура 4-недельного пилота: • Неделя 1. Онбординг: регистрация, первый вход, первый заказ с помощью менеджера. Фиксируем время онбординга. • Неделя 2–3. Самостоятельная работа. Считаем долю заказов через портал vs через менеджера. Фиксируем все обращения в поддержку. • Неделя 4. Структурированный опрос (5 вопросов, не больше): что мешало, чего не хватало, что работало хорошо. NPS-вопрос в конце. Обратную связь собирайте структурированно — не «как вам портал?», а конкретные вопросы по сценариям: «Смогли ли вы найти нужную позицию без помощи менеджера?», «Получили ли вы счёт без звонка?» Метрики MVP: что измерять и когда Регистрация пользователей — не метрика успеха. Вот что измерять: • % заказов через портал от общего числа заказов клиентов пилота. Цель: >30% за 60 дней. Если ниже — проблема в UX или в доверии к данным (неверные цены/остатки). • Снижение «где мой заказ»-обращений. Цель: -40% за 3 месяца. Считайте входящие звонки и письма по статусу заказа до и после. • Время от заказа до подтверждения в 1С. Цель: <15 минут. Текущий baseline — зафиксируйте до запуска. • Доля reorder. Показывает, что клиенты возвращаются самостоятельно. Рост от недели к неделе — сигнал adoption. • Ошибки в заказах (неверная цена, неверный остаток). Должны стремиться к нулю после стабилизации интеграции. • Время онбординга нового клиента — от регистрации до первого самостоятельного заказа. • NPS пилотной группы через 30 дней. • Окупаемость MVP: бюджет разработки ÷ ежемесячная экономия на операционных задачах менеджеров (часы × ставка). Последняя метрика часто удивляет: если 3 менеджера тратили по 2 часа в день на статусные запросы и пересылку документов, а портал снизил это на 60% — экономия считается в конкретных рублях и месяцах окупаемости. Топ-5 антипаттернов Phase 1 1. Мобильное приложение в Phase 1. B2B-закупщик работает за компьютером. Мобайл — это Phase 2, когда вы знаете, какие сценарии клиенты используют чаще всего. Включить его в Phase 1 — потратить 2–4 месяца на неподтверждённую гипотезу. 2. Кастомный аналитический дашборд до накопления данных. Классический пример 4 месяцев вне критического пути. Портал не собрал ни одного заказа, а дашборд уже готов. Аналитика — это Phase 2, когда есть что анализировать. 3. Сложная ролевая модель с первого дня. Покупатель / согласующий / финансист / администратор — это нужно крупным клиентам с внутренними процессами согласования. Для пилота достаточно одной роли. Сложная ролевая модель в Phase 1 удваивает объём тестирования. 4. Ручное обновление цен и остатков «для экономии». Это не экономия — это уничтожение доверия к платформе за 2–3 недели. Клиент оформляет заказ по неактуальному остатку, менеджер перезванивает с корректировкой. После двух таких случаев клиент перестаёт заходить в портал. 5. Маркетинговые инструменты в Phase 1. Промо-баннеры, персонализированные рассылки, программы лояльности — это маркетинговая задача. B2B-портал в Phase 1 решает операционную задачу: снизить cost-to-serve и дать клиенту самообслуживание. Смешивать эти задачи в одном релизе — значит размывать фокус команды и бюджет. Архитектурная оговорка: 152-ФЗ уже на MVP Для российских компаний это не «потом». Если портал хранит данные физических лиц (контакты закупщиков, ФИО подписантов) — требования 152-ФЗ применяются с первого дня. На этапе MVP это означает: выбор инфраструктуры на российских серверах, политика обработки персональных данных, согласие пользователя при регистрации. Это не большой объём работы, но его нужно заложить в скоуп Phase 1, а не добавлять постфактум. Качество данных в ERP как предусловие запуска портала — тема, которая пересекается с более широким вопросом о готовности данных к цифровым продуктам. Если вы параллельно думаете об аналитике поверх тех же данных, полезно прочитать о том, когда данных достаточно для BI — там разобрана смежная рамка зрелости данных, но под другим углом. *brezatech — интегратор ИИ в данные и процессы: разработка продуктов, BI и автоматизация для B2B-компаний в РФ.* Ключевые факты • Главная причина провала MVP B2B-портала — не выбор платформы, а грязные данные в 1С: дублирующиеся типы цен и неактуальная номенклатура делают интеграцию в 2–3 раза дороже. • Цель Phase 1 по метрикам: >30% заказов через портал за 60 дней и -40% входящих обращений 'где мой заказ' за 3 месяца. • Мобильное приложение, кастомный дашборд и маркетинговые инструменты в Phase 1 — топ-3 причины перерасхода бюджета без прироста ценности. • Пилот на 5–10 лояльных клиентах за 4 недели дешевле исправляет UX и интеграционные баги, чем rollout на всю базу. • Окупаемость MVP считается просто: бюджет разработки ÷ ежемесячная экономия FTE менеджеров на рутинных задачах.