Почему B2B-маркетплейс нельзя просто сделать «интернет-магаз
Последние несколько лет я развиваю Optovik — B2B-маркетплейс ингредиентов и компонентов для производителей косметики, бытовой химии и пищевой продукции. На первый взгляд задача довольно стандартная: есть поставщики, каталог, цены и покупатели. Значит, нужно дать возможность найти товар, положить его в корзину и оформить заказ. На практике оказалось, что B2B-покупка устроена совсем иначе. Представим производителя косметики, которому нужна новая парфюмерная отдушка. Он редко готов сразу заказать 20–50 кг незнакомого сырья. Сначала нужно найти подходящие варианты. Получить образцы. Провести тесты. Проверить документы. Сравнить поставщиков. Рассчитать экономику. И только потом сделать коммерческий заказ. Поэтому одной из важных частей продукта стала не корзина, а заказ образцов. Но дальше возникает следующий вопрос. Что происходит после получения образца? Если просто дать пользователю образец и забыть о нём, значительная часть потенциальных продаж потеряется. Значит, нужно понимать, когда клиент получил образец, что он тестировал и когда имеет смысл вернуться к нему с предложением коммерческой поставки. То же самое произошло с повторными заказами. Для многих ингредиентов закупка циклична. Если компания регулярно приобретает определённый компонент, данные позволяют приблизительно определить момент следующей потребности. Так обычный каталог постепенно превращается в систему, которая сопровождает B2B-клиента на всём пути: поиск → образец → тестирование → первая покупка → доставка → повторная покупка. Сегодня в Optovik: — более 1 100 зарегистрированных компаний; — около 600 активных покупателей; — 31 поставщик; — более 7 600 товаров в каталоге; — десятки миллионов рублей продаж в год. Но для меня главный результат проекта даже не эти цифры. Optovik хорошо показал одну вещь, которую я считаю принципиальной для продуктовой разработки: не стоит начинать с вопроса «какие функции нам нужны?». Сначала нужно понять, как на самом деле пользователь решает свою задачу. А уже потом строить продукт вокруг этого процесса. Иногда оказывается, что самая ценная функция продукта — совсем не та, которую команда считала главной в начале.