Разработка программного обеспечения для бизнеса часто сталкивается с невидимыми подводными камнями еще на этапе проектирования финмодели. Команда EmitLab делится реальным кейсом создания b2b-экосистемы.

Статья подготовлена командой EmitLab. Наш профиль — профессиональная разработка мобильных приложений, сервисов и сайтов под ключ. Мы привыкли мыслить бизнес-целями клиента, выстраивать устойчивую архитектуру и создавать сложные программные продукты, которые приносят реальную прибыль. Имея за плечами этот опыт, мы решили провести детальный разбор одной критической ошибки в проектировании ИТ-платформ.

От идеи к экосистеме: как расширялся b2b-стартап

Не так давно меня пригласили поучаствовать в качестве технологического партнера в одном перспективном стартапе. Для реализации проекта требовалась опытная команда и сильные компетенции в разработке платформ со схожим функционалом: биржа заказов и CRM-система. В ходе обсуждения со стейкхолдерами концепция значительно расширилась. Вместо базовой CRM появилась комплексная ERP-система для автоматизации управления ресурсами компаний, планирования нагрузки и распределения заказов (аналог цифрового штатного расписания). Дополнительно были спроектированы блок финансового учета и внутренний маркетплейс техники и расходных материалов.

В итоге получилась масштабная b2b-экосистема. На бумаге проект выглядел безупречно: замкнутая win-win-win система, где для каждого участника предусмотрены понятные сценарии генерации ценности и распределения бюджетов.

Поиск модели монетизации: где скрывался просчет

При коммерциализации экосистемы b2b-платформы возник логичный вопрос: как именно стейкхолдеры будут получать прибыль? С ERP-системой и маркетплейсом товаров все было прозрачно. Для модуля ERP идеально подходила SaaS-модель (подписка, привязанная к количеству сотрудников компании). Для маркетплейса — классическая комиссия с продаж, удерживаемая с продавца. Однако монетизация биржи заказов завела команду в тупик.

Бизнес-логика сломалась на этапе точного определения ролей пользователей. При проектировании архитектуры мы допустили критическую ошибку — перепутали заказчика и конечного потребителя услуги.

Для наглядности рассмотрим пример из сферы образования. Родственник, оплачивающий обучение студента, выступает юридическим и финансовым заказчиком, но не является потребителем. Потребитель здесь — сам студент. Из-за этого возникает сильный разрыв в мотивах. Заказчик ждет качественных знаний для карьеры, а потребитель часто воспринимает учебу как формальность и ищет любые способы упростить процесс (списать, купить готовую работу). В коммерческом ИТ-продукте такой разрыв в мотивациях сторон может полностью разрушить экономику проекта.

Роль посредника в b2b цепочке

В нашей ИТ-платформе заказчик и потребитель также оказались разными лицами с противоположными интересами. Как показал анализ рынка, крупные заказчики технически далеки от современных цифровых платформ. Им привычнее использовать прямые звонки и проверенных посредников. Переучивание такой аудитории требует колоссальных инвестиций в маркетинг и внедрение. В реальности конечным потребителем интерфейса биржи стал посредник — агент между заказчиком и непосредственным исполнителем работ.Эта схема напоминает классический рынок недвижимости, где риелторы аккумулируют спрос и берут процент за сделку. Посредник уже имеет стабильный личный контакт с заказчиком и напрямую влияет на его решение о найме конкретных исполнителей. Стоимость услуг в данной нише высокая — от 150 000 до 200 000 рублей за один рабочий день. Традиционный порядок расчетов выглядит так: посредник подбирает исполнителей, согласовывает размер своего вознаграждения, а после выполнения работ получает оплату наличными или прямым переводом на карту.

Какая модель монетизации эффективна: комиссия против подписки

Мы изначально определили, что платить за доступ к заказам должен исполнитель. Рынок исполнителей высококонкурентный и имеет выраженную сезонность, поэтому компании максимально заинтересованы в постоянной загрузке своей техники и специалистов. Исполнитель сам формирует итоговую стоимость услуг, а значит, может заложить в прайс как долю посредника, так и комиссию ИТ-платформы. Кроме того, они уже привыкли тратить рекламные бюджеты на досках объявлений.Мы детально проанализировали два сценария монетизации биржи: транзакционную модель (комиссия) и фиксированную плату (подписка).

Минусы транзакционной модели (комиссия с объема сделки):

• Отсутствие официальных договоров. Сделки между сторонами часто заключаются на доверии, поэтому платформа выступает лишь как информационный сервис и не может жестко контролировать финансовые потоки.
• Высокий уровень отмен. По статистике, до 25% b2b-заказов отменяются по разным причинам. Технологически доказать факт отмены или фиктивного отсутствия исполнителя на объекте крайне сложно.
• Расхождение плановых и реальных объемов. Фактически выполненный объем работ регулярно отличается от первоначально заявленного в системе.

Внедрение транзакционной модели привело бы к лавинообразному росту спорных ситуаций. Нагрузка на службу поддержки и арбитраж съела бы всю маржинальность ИТ-продукта. Если на один спор тратится до двух часов работы менеджера, то обработка 25% проблемных заказов делает бизнес убыточным.

Минусы подписочной модели (SaaS для исполнителей):

• Проблема «курицы и яйца» на старте. Чтобы исполнители платили за подписку, на бирже должно быть много лидов. Но привлечь заказчиков без готовой базы исполнителей невозможно.
• Сложность расчета справедливой стоимости. Без накопления долгосрочной аналитики и статистики по среднему чеку и числу заказов невозможно рассчитать экономически обоснованный тариф.
• Сезонные спады. В периоды низкого спроса исполнители будут массово отменять подписку, что приведет к нестабильности доходов платформы.

Итог: почему мы временно отказались от монетизации биржи

Взвесив все риски, команда стартапа приняла стратегическое решение — полностью отказаться от монетизации функционала биржи на первом этапе. Введение платных тарифов для исполнителей затормозило бы органический рост пользовательской базы (Network Effects). А ведь именно высокая активность пользователей необходима для успешных продаж основных сервисов — ERP-системы и маркетплейса.

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

Справочно о проекте: целевая предметная область данной платформы — автоматизация услуг агродронов в рамках рынка БАС (беспилотных авиационных систем). Однако разработанная нами бизнес-модель универсальна. Она работает точно так же, если вы проектируете b2b-сервисы в сфере грузоперевозок, крупного ремонта или аутсорсинга персонала.

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