B2B-портал помогает автоматизировать типовую работу менеджера, учитывая при этом специфику B2B-рынка: индивидуальные цены, отсрочку платежа, товары «в пути», закрывающие документы и т.д.
Часто B2B-бизнес работает «на людях»: чтобы ознакомиться с прайсом или каталогом, оформить заказ или получить документы, нужен персональный менеджер. При этом все эти процедуры типовые — они не требуют принятия решений, но требуют много времени.
Заниматься увеличением продаж и развитием отношений с клиентами в условиях бесконечной рутины просто некогда.
Внедрение B2B-порталов позволяет освободить время менеджеров на развитие бизнеса
Вы получите
Повышение качества обслуживания за счёт исключения человеческого фактора из типовых процессов
Снижение затрат на обработку заказов в несколько раз
Увеличение производительности отдела продаж и дохода с одного менеджера
Ваши клиенты получат
Доступ к документам в два клика, самостоятельный контроль ДЗ, отсрочки и графика гашения
Возможность оформить заказ 24/7
Всегда актуальные цены
Решенные бизнес‑задачи
Трансформация процесса сбыта
Автоматизация работы с торговыми точками по всей России, работающих с разными торговыми домами в условиях сложной системы ценообразования и гибко настраиваемых трейд‑маркетинговых акций.
Типовая структура B2B-портала
Как правило, портал состоит из нескольких блоков, отвечающих за автоматизацию разных бизнес-процессов. Функциональность в этих блоках может существенно различаться в зависимости от специфики работы компании.
Портал для торгово-производственных и оптовых компаний имеет похожую на интернет-магазин структуру, но при этом каждая составляющая существенно отличается из-за характерных для B2B-рынка особенностей работы.
Каталог
Размещение в каталоге нескольких сотен тысяч SKU, распределённых по разным складам.
Вывод актуальных цен с учётом индивидуальных условий у каждого клиента.
Прогнозирование сроков доставки с учётом времени на перемещение товаров между складами, сроков поступления товаров «в пути» и «под заказ со склада поставщика».
Трансформация портала в маркетплейс с помощью подключения новых поставщиков.
Хорошие вопросы перед стартом
Запуск B2B-портала — важный, ответственный и дорогостоящий шаг в развитии компании. Прежде чем его сделать, хочется быть уверенным в достижении результата. Вот несколько популярных вопросов перед запуском проекта.
«У нас очень специфичный бизнес и всё зависит от людей. Что, если его просто невозможно оцифровать?»
Практика показывает, что все бизнесы имеют свою специфику со множеством сложных нестандартных процессов и исключений. Однако всё, что можно объяснить человеку, можно уложить в единую работающую архитектуру при индивидуальном подходе и правильной кастомизации.
«Расходы на B2B-портал окупятся?»
По статистике через B2B-портал совершается столько же продаж, сколько через личный контакт с менеджером. При этом после запуска портала выручка от личных продаж менеджеров в компании не уменьшается, но за счет внедрения возможности самообслуживания появляются дополнительные объемы выручки, которые компания ранее упускала. Создание B2B-портала не бывает дешёвым, но эти расходы окупаются.
«В наших внутренних системах часть данных отсутствует или не актуальна. Можно ли запускать портал?»
На старте может быть много учетных систем, в которых могут быть неактуальные данные или данные, не подходящие для коммерческого использования. Такие ситуации не уникальны и успешно решаются на этапе ввода в эксплуатацию резервированием дополнительного времени команды.
«Как объяснить сотрудникам, что портал не заберёт у них работу, и избежать сопротивления внутри компании?»
На практике портал решает именно типовые задачи, где менеджер не нужен. Благодаря автоматизации у менеджеров появляется время, чтобы решать более творческие задачи, требующие участия человека: искать новых клиентов, а с существующими обсуждать их бизнес, проблемы и ассортимент, что напрямую влияет на развитие продаж.
Команда проекта
Каждый из этапов создания проекта требует высокой экспертизы, поэтому для решения бизнес-задачи над созданием e-com платформы работает команда из 10-15 специалистов.
Процесс и этапы проекта
Аналитика и проектирование системы
Цель этапа — формализация целей проекта, составление бизнес-требований и функциональных требований, формирование задания на разработку и дизайн‑концепции.
На этапе аналитики мы обсуждаем цели, задачи и способ оценки эффективности выполненного проекта. Эту информацию мы фиксируем и обращаемся к ней в ходе работы для принятия решений.
Этап требует много времени от команды клиента, поскольку нужно прояснить много деталей, критически влияющих на результат. Чтобы сделать его более предсказуемым и комфортным, мы составляем календарь встреч и визуализируем план на диаграмме Ганта.
В процессе этапа мы анализируем бизнес‑процессы и IT‑ландшафт компании, готовим спецификации интеграций, анализируем конкурентов и целевую аудиторию, составляем customer journey map, описываем функциональные требования к проекту.
Ключевая роль клиента на этапе аналитики — описание проблемы и образа желаемого результата. Далее мы сами предлагаем и аргументируем архитектурные, функциональные и дизайн‑решения.
Функциональные требования фиксируются по горячим следам после обсуждения, чтобы клиент сразу мог проверить, что всё описано корректно. Такой подход позволяет согласовывать требования по частям в комфортном для клиента темпе, поскольку объём финального документа может занимать более 100 страниц.
Вся документация хранится в одном месте и доступна клиенту в любой момент. Аналитик находится в проекте на всех этапах работы и дополняет документацию технической информацией по мере разработки проекта.
Результат этапа:
- схемы бизнес процессов, которые связаны с e‑com платформой;
- описание систем IT‑ландшафта и схема движения данных между системами;
- спецификации обменов;
- технологическая архитектура системы;
- функциональные требования;
- сформированный MVP проекта и roadmap развития;
- прототипы ключевых интерфейсов;
- формализованные требования к дизайну;
- дизайн‑концепция на базе одной страницы.
Состав команды на этапе аналитики: менеджер проекта, аналитик, архитектор, UX‑дизайнер, UI‑дизайнер.
Оценка проекта
Цель этапа — утверждение периметра MVP проекта и его стоимости.
Определить бюджет до начала работ можно только для простых e‑com проектов или когда клиент предоставил детальные и качественно описанные функциональные требования.
В остальных случаях на старте мы имеем только представление о приблизительном диапазоне цены и фиксированную стоимость аналитики, после завершения которой мы приступаем к оценке всего проекта.
На этом этапе мы можем пересмотреть состав MVP, убрав в бэклог не критичные, но уже оценённые блоки.
Результат этапа — детальная смета, в которой по пунктам описана стоимость функциональных блоков и сроки производства.
Состав команды на этапе оценки: менеджер проекта, аналитик, архитектор, руководители отделов.
Производство и QA
Цель этапа — дизайн, разработка, тестирование и приёмка проекта.
Перед запуском проекта в производство мы составляем календарный план проекта. В нём отмечены вехи по сдаче функциональных блоков проекта, а также задачи и события на стороне клиента. Это позволяет в любой точке проекта видеть, всё ли идёт по графику, когда будет демо и когда планируется следующая оплата.
К дизайну подходим системно, чтобы проект был визуально консистентным, технологичным и развиваемым на уровне кода. В дизайне прорабатываем все элементы и состояния, разрабатываем дизайн‑систему и сторибук для систематизации работы, упрощения разработки и повторного использования кода.
В разработке используем принципы гибких методологий, разделяя всю работу на двухнедельные циклы (спринты).
Работа над задачами поддерживаются аналитиком: он помогает оперативно решать вопросы разработчиков и актуализирует документацию, если что‑то в процессе реализации меняется.
Тестирование проводится на собственных устройствах и в облачных фермах. Мы составляем тест‑кейсы, выделяем из них кейсы для регрессионного тестирования, когда требуется проверка работоспособности ранее внедрённой функциональности.
Типы тестирования, которые мы проводим:
- визуальное, в разных версиях браузеров на разных устройствах;
- функциональное: проверяем, что все функции проекта работают согласно документации;
- интеграционное, чтобы убедиться в корректности взаимодействия модулей;
- тестирование производительности: убеждаемся, что сайт работает быстро;
- нагрузочное: проверяем как сайт ведет себя в условиях высокой посещаемости;
- приемочное, когда клиенту нужно принять работу от сторонних подрядчиков;
- регрессионное, когда выпускаем в проекте новые фичи и убеждаемся, что не нарушена ранее реализованная функциональность.
После разработки функциональности проводим внутреннюю приёмку и убеждаемся в том, что всё корректно работает, а затем проводим демо с клиентом. Чтобы облегчить процесс приёмки, каждый функциональный блок демонстрируется отдельно (по мере готовности), а в конце — проект целиком.
Результат этапа — разработанный проект, готовый ко вводу в эксплуатацию.
Состав команды на этапе разработки и QA: менеджер проекта, аналитик, UX‑дизайнер, UI‑дизайнер, архитектор, 2 frontend‑разработчика, 2‑3 backend‑разработчика, тимлиды, devops‑инженер, 1‑2 QA инженера.
Ввод в эксплуатацию
Цель этапа — публикация проекта для пользователей и сотрудников.
На этом этапе мы готовим пользовательские инструкции для сотрудников, передаём функциональные требования, по которым реализован проект, и тест‑кейсы (при необходимости).
Параллельно с этим мы готовим и согласовываем протокол приемо‑сдаточных испытаний со сценариями и проводим испытания совместно с клиентом.
Составляем план релиза, включающий привлечение подрядчиков клиента, перенастройку всех систем и интеграций, чистовую миграцию данных и другие процедуры. Это технически сложный и объёмный процесс, который обеспечивает целостность данных и работоспособность проекта, поэтому к нему мы подходим с особой внимательностью и тщательностью.
Также на этапе ввода в эксплуатацию мы помогаем обеспечить сохранение результатов SEO‑продвижения и связь нового проекта с существующими маркетинговыми кампаниями.
Результат этапа — введенная в эксплуатацию система, переданная документация.
Состав команды на этапе ввода в эксплуатацию: менеджер проекта, QA инженер, devops‑инженер, frontend‑разработчик, backend‑разработчик.
Переход в развитие
Цель этапа — сбор результатов запуска MVP и составление плана развития.
Анализируем обратную связь от сотрудников и пользователей, текущие приоритеты бизнеса и на основании этого актуализируем бэклог для развития проекта.
Подробнее о том, как мы подходим к развитию и поддержке ранее запущенных проектов, можно узнать в разделе Доработка и поддержка.
B2B-портал, автоматизирующий управление продажами
Новабев (ex. Белуга групп) — крупнейшая алкогольная компания в России, один из главных импортеров алкоголя в стране
Результат
Разработан и запущен
B2B-портал для автоматизации управления продажами и бизнес-процессами продаж, обеспечения прямой дистрибуции товаров в торговые точки на федеральном уровне.
Совместно с 
B2B-портал, автоматизирующий бизнес-процессы продаж и работы с дилерами
Kramp — международный поставщик запчастей для сельскохозяйственной техники
Результат
B2B-портал автоматизирует продажи и другие типовые операции по работе с дилерами компании.
95% заказов от оформления до отгрузки выполняются автоматически, без участия менеджера.
На портале индивидуальные цены, оплата кредитным лимитом и эквайринг, информация об остатках на складах и будущих поставках, закрывающие документы по заказам и т.д. Данные синхронизируются с 1С.
Сервис бронирования услуг в аэропортах мира
Ваба — крупнейший агрегатор услуг в аэропортах
Результат
Разработан и запущен сервис для B2B и B2C.
Headless архитектура, интеграция с тысячей аэропортов и глобальными поставщиками данных о рейсах.
Сервис учитывает особенности ценообразования разных аэропортов, дает возможность устанавливать индивидуальные цены для B2B-клиентов, автоматизирует типовые операции и формирует управленческую отчетность.
