Сервис-платформа онлайн-бронирования отелей
(01)
Сразу по результатам
Запустили MVP платформы онлайн-бронирования, которая заменила зависимость от отдельных сайтов отелей и стала резервным каналом для рекламного трафика.

Результат:
  1. появился единый продукт для приема трафика
  2. снизилась зависимость от сайтов конкретных отелей
  3. трафик можно было перераспределять внутри платформы
  4. пользователи получали альтернативы при недоступности выбранного отеля
  5. продукт был передан в развитие после запуска MVP
(02)
Как оценивали успех MVP
  1. возможность принимать трафик не на отдельные сайты, а на единую платформу
  2. корректная работа поиска и доступности номеров через API
  3. наличие альтернативных предложений при недоступности выбранного отеля
  4. возможность редактировать данные через админку
  5. готовность аналитики для отслеживания поисков, переходов и бронирований
(03)
Контекст
Компания развивала сеть сайтов отелей с разными шаблонами. Каждый сайт был заточен под конкретный объект и работал как отдельная точка привлечения трафика.

Со временем это привело к ряду ограничений. Отели начали предъявлять претензии, так как сайты могли конкурировать с их официальными ресурсами. В отдельных случаях возникали юридические риски и необходимость временно отключать сайты.

При этом у компании уже была накопленная база данных по отелям, контенту и доступ к API партнёров.
В этих условиях было принято решение создать отдельный продукт — сервис онлайн-бронирования, который не привязан к конкретному отелю и работает как агрегатор.
(04)
Бизнес-проблема
Система из отдельных сайтов перестала масштабироваться и начала создавать риски для бизнеса.

Ключевые ограничения:
  1. претензии со стороны отелей к отдельным сайтам
  2. юридические ограничения и риски блокировок
  3. зависимость от конкретных сайтов и невозможность быстро перераспределять трафик
  4. отсутствие единой платформы с альтернативными предложениями
  5. слабая масштабируемость модели “один отель — один сайт”

В результате компания теряла гибкость в управлении трафиком и потенциальные заказы.
(05)
Цель
Создать полноценный сервис онлайн-бронирования, который:
  1. объединяет все предложения в единую платформу
  2. позволяет гибко управлять трафиком
  3. снижает юридические риски
  4. масштабируется без необходимости создавать отдельные сайты
  5. становится дополнительным и резервным каналом привлечения
(06)
Что было на входе
  1. сеть отдельных сайтов отелей
  2. накопленная база контента
  3. доступ к API партнеров
  4. юридические и репутационные риски по отдельным сайтам
  5. необходимость сохранить рекламный трафик и заказы
(07)
Что было на входе
  1. сеть отдельных сайтов отелей
  2. накопленная база контента
  3. доступ к API партнеров
  4. юридические и репутационные риски по отдельным сайтам
  5. необходимость сохранить рекламный трафик и заказы
(08)
Моя роль
Product Designer / Product Owner на стороне продукта

Я вел продуктовую проработку MVP: собирал требования, описывал пользовательские сценарии, проектировал логику сервиса и админки, готовил backlog и ТЗ, синхронизировал решения с разработкой, участвовал в тестировании и описывал требования к аналитике.
(09)
Мои продуктовые зоны ответственности
  1. сбор и структурирование требований
  2. описание MVP и ключевых сценариев
  3. проектирование пользовательской логики и админки
  4. синхронизация решений с backend/API
  5. подготовка backlog и ТЗ
  6. тестирование закрытой версии
  7. требования к аналитике и метрикам
(10)
Метрики успеха MVP
  1. единая платформа принимает рекламный трафик
  2. пользователь может искать отели по датам и параметрам
  3. при недоступности выбранного отеля показываются альтернативы
  4. данные подтягиваются через API
  5. команда может управлять данными через админку
  6. события для аналитики описаны до запуска
Ключевые продуктовые решения
1
Единая платформа вместо отдельных сайтов
  1. убрать зависимость от сайтов конкретных отелей
  2. трафик можно вести на один масштабируемый продукт
2
Альтернативы при отсутствии номеров
  1. не терять пользователя в тупике
  2. выше шанс сохранить сессию и довести до бронирования
3
Работа через API
  1. снизить ручное наполнение
  2. быстрее масштабировать базу отелей
4
Админка
  1. сохранить управляемость контента
  2. команда может корректировать данные без разработки
Мой вклад
Что я сделал
Я вел проект от идеи до запуска MVP
(01)
Discovery
Сначала собрал требования от стейкхолдеров и синхронизировал их с техническими возможностями команды. Параллельно провёл анализ конкурентов и существующих решений на рынке.

Отдельный акцент был на том, что сервис должен максимально работать на данных из API и не зависеть от ручного наполнения.
(02)
Архитектура продукта
  1. спроектировал информационную архитектуру сервиса
  2. отдельно проработал архитектуру админки совместно с разработкой
  3. провёл пользовательские опросы и интервью в рамках доступных ресурсов
  4. выявил слабые места существующих решений
(03)
Сценарии и валидация
  1. сформировал и несколько раз переработал пользовательские сценарии
  2. быстро проверил ключевые сценарии через wireframes
  3. валидировал пользовательский сценарий до разработки
(04)
Подготовка к разработке
  1. полностью собрал дизайн сервиса и адаптивы
  2. перевел продуктовую логику в требования и backlog
  3. подготовил технические задания
(05)
Delivery
  1. проводил тестирование закрытой версии
  2. собирал обратную связь
  3. формировал backlog и задачи для команды
(06)
Launch readiness
  1. синхронизировал логику продукта с backend
  2. синхронизировал пользовательский сценарий с ограничениями backend/API
  3. участвовал в финальном тестировании
(07)
Аналитика
  1. поставил требования по внедрению аналитики
  2. описал метрики для оценки эффективности продукта
Результаты
  • запустили отдельную точку приема рекламного трафика вместо зависимости от сайтов конкретных отелей
  • при претензиях к отдельному сайту трафик можно было переводить на страницы агрегатора без остановки рекламной кампании
  • появилась возможность гибкого перераспределения трафика
  • новые отели могли добавляться через API/админку без запуска отдельного сайта под каждый объект
  • MVP был запущен, передан в развитие и стал частью продуктовой инфраструктуры компании
Made on
Tilda