🗯80. Кейс. Варианты проверки гипотез для трехсторонних продуктов (маркетплейсов) ‼️Инсайт: пока готовил для вас кейсы - поймал важный инсайт. Взаимоотношения субъектов (собственник продукта vs клиент, поставщик vs покупатель) можно описать следующим образом: одна сторона хочет продать товар и получить деньги, а вот хочет ли вторая сторона их заплатить (нужен ли товар или услуга) - еще нужно доказать. То есть одна сторона платит деньги (или не платит), но вторая сторона их формально просто получает. ➡️ Так вот самое сложное и то, что мы должны в первую очередь проверять - готовность клиента платить деньги за конкретный товар или услугу. Не желание поставщика продать товар или получить за него деньги, не "нытинг" поставщика по поводу, что денеге мало, маржи мало или клиентов мало (всё очевидные факты), а готовность покупателя платить за конкретный товар или услугу. 👉 Кейс - платформа для бронирования отелей: ⚫️Продукт: платформа для бронирования отделей (аналог booking). 🟠На чем НЕ фокусируемся: готовность отелей сотрудничать. В общем и целом никто не будет отказываться от денег или клиентов. Почему отели могут не сотрудничать на начальном этапе - могут не верить в новую платформу для бронирования. Нужно показать убедительную GTM стратегию, которая объясняет почему на платформу будет поток клиентов. Собственно получение лидогенерация, привлечение клиентов - одна из ключевых задач собственника технического решения. 🟠Что проверяем: готовность клиентов бронировать (платить) на новой платформе. Почему клиент должен переключиться с существующего продукта и старого клиентского пути (через booking) на новый? Тут так же есть развилки - привлечение новых клиентов (формирование нового клиентского пути) и переключение старых (замена старого клиентского пути). 🟠Как проверяем: лучше всего с командой сформировать бэклог гипотез и методично их реализовывать (проверять варианты, смотреть что работает, считать CAC в каждом канале). - Как минимум на старте имеет смысл сфокусироваться на узком сегменте - районе города (центральный или деловой квартал), только одном городе (не стране). Такая фокусировка даст точечный клиенский сегмент (туристы, бизнесмены) и потребует от нас меньше усилий для проверки - в том числе меньшую стоимость привлечения клиентов за счет конкретного целевого действия (туристические маршруты) или GEO. - Имеет смысл проверить как онлайн, так и оффлайн варианты привлечения. Оффлайн варианты - визитки сайта в номерах отеля партнера, крупные компании, который часто посылают сотрудников в командировку в конкретный город. Онлайн - нужно четкое позиционирование (минимум по GEO), показывать рекламу на всех людей или всю страну - не хватит денег. Тут вопросы - как вы найдете в интернете потенциальных клиентов, какое целевое таргетное действие они совершают в сети? 🟠Замечания: должен быть бюджет на сбор отелей (формирование стартового пула исполнителей) и бюджет на привлечение клиентов (проверку гипотез ценности). 🟠Техническая реализация: безусловно, нужен какой-то сайт прототип. Но его можно собрать достаточно минимально: 1) Ограничить число отелей в рамках прототипа; 2) Парсить с них нужную информацию через тот же booking; 3) Просто забирать с клиентов информацию и заказ на бронирование; 4) Проксить, перекидывать бронирование в booking и тем самым закрывать вопрос с клиентами; 5) Нет проблем, если большую часть работ будете делать руками. 💯 Ваша задача - проверять готовность бронировать номера минимальными усилиями. На данном этапе только проверять клиентскую готовность, а не закрывать бизнес процесс в какой-либо части (реализовывать бронирование). На старте - оставляйте себе только проверку готовности клиентов к бронированию номеров на вашем сайте, а само бронирование и другие технические вопросы отдавате тем, кто уже умеет это делать (booking). Ваши клиенты - останутся с вами (у вас есть все их контакты). Получите существенный поток клиентов - будете закрывать вопрос с бронированием уже сами. #Маркетплейсы #Платформ