Хостес-сервис нового формата – мобильное приложение, которое связывает рестораны и инфлюенсеров: заведение получает гостей и публикации, инфлюенсер получает комиссию за фактический визит. Я вёл проект как продакт- и проджект-менеджер: собирал команду, проектировал модель и метрики, отвечал за привлечение обеих сторон.
Ниже – как устроен этот хостес-сервис, какая метрика оказалась единственной по-настоящему важной и где в такой модели прячутся риски.
Задача: реклама, за которую платят по факту
Ресторан, который хочет продвигаться через блогеров, обычно платит вперёд: за пост, за сторис, за визит с камерой. Дальше начинается неизвестность. Придут ли гости, сколько их будет, окупится ли размещение – на эти вопросы никто не отвечает, потому что связи между публикацией и посадкой за столик просто нет.
Инфлюенсеры с небольшой, но живой аудиторией сталкиваются с зеркальной проблемой. Договориться с рестораном напрямую сложно: у заведения нет ни процесса, ни доверия к незнакомому аккаунту, а торговаться за каждое размещение дорого по времени для обеих сторон.
Как устроен хостес-сервис
Хостес-сервис устроен как двусторонний маркетплейс, в котором единицей сделки стало не размещение, а бронирование.
- Ресторан размещает условия – комиссию за пришедшего гостя и отдельную ставку за публикацию.
- Инфлюенсер бронирует стол через приложение, и бронь привязывается к его аккаунту.
- Заведение подтверждает визит и сумму чека, после чего начисляется комиссия.
- Публикация оплачивается отдельно – как дополнительная опция, а не как основа сделки.
Смысл конструкции в том, что ресторан платит после результата, а не за обещание охвата. Это снимает главное возражение заведения и одновременно отсеивает аккаунты, которые продают цифры, а не влияние.
Главная метрика: доходимость, а не охват
В первых версиях модели мы, как и все, считали охваты, число активных заведений и инфлюенсеров, средний чек. Быстро выяснилось, что почти всё это – метрики тщеславия. Единственный показатель, который определял, живёт ли платформа, – доля броней, закончившихся реальным визитом и оплаченным счётом.
Причина простая. Ресторан считает не подписчиков, а выручку и загрузку зала. Бронь, по которой никто не пришёл, для него хуже отсутствия брони: стол простоял пустым в прайм-тайм. Поэтому доходимость стала и метрикой качества площадки, и основанием для рейтинга инфлюенсера внутри сервиса.
Остальные показатели мы оставили как вспомогательные: стоимость привлечения заведения и инфлюенсера, доля повторных броней, средний чек по категории. Они помогают понять экономику, но решение о том, кому давать доступ к лучшим заведениям, принималось по доходимости.
Риски, которые пришлось закладывать в продукт
Фиктивные брони. Как только комиссия привязана к визиту, появляется соблазн его имитировать: договориться со знакомым администратором, оформить визит без чека, забронировать и не прийти. Подтверждение визита со стороны ресторана и привязка к сумме счёта – не бюрократия, а защита экономики платформы.
Несовпадение по контенту. Заведение ждёт одну подачу, инфлюенсер снимает другую. Мы решали это на входе: ресторан заранее описывает, что для него приемлемо, а публикация оплачивается как отдельная позиция, поэтому спорная съёмка не ломает всю сделку.
Холодный старт двустороннего рынка. Инфлюенсеры не идут туда, где мало заведений, заведения не подключаются туда, где мало инфлюенсеров. Мы шли по географии: набирали плотность в одном районе, чтобы в приложении было что выбрать, и только потом расширялись. Тот же принцип, что и в eXpresso Coffee, где спрос сначала проверялся на одном городе.
Что я вынес из проекта
Двусторонние площадки красиво выглядят в презентации и тяжело живут в реальности: одна и та же комиссия должна быть достаточно большой, чтобы заинтересовать инфлюенсера, и достаточно маленькой, чтобы ресторан считал её выгодной сделкой. Зазор между этими двумя числами и есть весь бизнес.
Второй вывод касается доверия. Модель оплаты по факту визита выглядит справедливой для всех, но работает только при честном подтверждении с обеих сторон. Проверяемость события оказалась важнее любой функции приложения – то же самое я потом решал техническими средствами в PharmAPI. Подробнее о подходе к оценке подобных рисков – в материале про комплексное управление рисками.
Моя роль в проекте
- Продакт и проджект-менеджмент. Постановка задач команде, приоритеты разработки, сроки и приёмка.
- Бизнес-модель. Структура комиссий, условия для обеих сторон и логика начисления выплат.
- Метрики и аналитика хостес-сервиса. Отбор показателей, по которым принимались решения, и отказ от метрик тщеславия.
- Привлечение. Работа с заведениями и с инфлюенсерами, включая условия для первых участников на старте.
Частые вопросы
Что такое хостес-сервис в этом проекте? Мобильное приложение, связывающее рестораны и инфлюенсеров: бронь через приложение, подтверждение визита рестораном, комиссия по факту. Публикация оплачивается отдельно.
Чем это отличается от обычной рекламы у блогеров? Ресторан платит за пришедшего гостя, а не за обещанный охват, поэтому результат виден в выручке.
Какая метрика была ключевой? Доходимость – доля броней, закончившихся визитом и оплаченным счётом. Всё остальное оказалось метриками тщеславия.
Как решалась проблема фиктивных броней? Комиссия начислялась после подтверждения визита рестораном и привязки к чеку, а доходимость влияла на рейтинг инфлюенсера.
Нужна консультация?
Если вы запускаете маркетплейс и не уверены, какая метрика в нём настоящая, запишитесь на бесплатную 15-минутную консультацию. Разберём вашу модель и точки, где она может не сойтись.