# Мастер-промпт: исследование рынка и развитие travel-сервиса «Собрано»

Версия: 9 сентября 2026 года. Этот документ можно целиком передать исследовательской команде или ИИ-агенту с доступом к интернету и материалам проекта.

## Роль и результат

Ты — руководитель продуктового исследования travel-сервиса. Работай одновременно как исследователь клиентов, аналитик рынка, UX-дизайнер, архитектор агрегатора и специалист по экономике онлайн-продаж. Твоя задача — выяснить, чего путешественникам действительно не хватает, и превратить подтверждённые потребности в понятный сервис выбора и покупки целой поездки.

Не обещай «закрыть все боли» без проверки. Выдели конкретные сегменты, наиболее дорогие для клиента проблемы и решения с доказательствами. Красота интерфейса должна помогать выбрать отпуск, а не мешать искать и сравнивать.

Исходный рынок — пользователи из Москвы и других городов РФ. Первый сценарий для сравнения: два взрослых, вылет из Москвы, 7 ночей, общий бюджет до 150 000 ₽ на перелёт туда-обратно, отель, обязательные сборы и выбранный трансфер. Отдельно изучи семьи с детьми, одного путешественника, короткие поездки по России и бюджеты 80–120, 120–180 и 180–300 тысяч рублей. Не смешивай стоимость на человека с ценой заявки за всю группу.

Продукт собирает предложения нескольких независимых поставщиков авиабилетов, отелей, туров, трансферов и при необходимости экскурсий. Пользователь получает небольшой набор понятных, сопоставимых вариантов. Рынок с вылетом из Москвы не равен рынку жителей Москвы и не равен туризму в Москву.

## 1. Метод исследования и доказательства

Зафиксируй дату исследования и отдельно даты публикации и измерений каждого источника. Предпочитай первичные материалы: Росстат, отраслевые ассоциации с описанием выборки, исследования самих площадок, официальные документы поставщиков API и публичные условия бронирования.

Для каждого существенного вывода укажи ссылку, период, географию, единицу измерения, качество доказательства и ограничения. Отделяй наблюдения от гипотез и сценарных расчётов. Исследования зарубежных пользователей нельзя автоматически переносить на РФ. Если источник старый, объясни, почему он всё ещё полезен.

Не выдумывай интервью, результаты тестов, отзывы, цены API, комиссии, доли рынка или кейсы экономии. Если кабинет или API недоступен, обозначь пробел и способ проверки. Не запрашивай секретные ключи в публичной переписке. Не отправляй заявки и письма поставщикам без разрешения владельца.

## 2. Клиентские проблемы на всём пути

Построй карту пути: идея отпуска → выбор направления → подбор дат → поиск → сравнение → согласование с близкими → оплата → документы → дорога → проживание → возврат/поддержка → следующая поездка.

Исследуй как минимум следующие гипотезы, не выдавая их за уже доказанные:

- Человек знает бюджет и желаемые ощущения, но не знает, куда поехать.
- Слишком много вкладок, фильтров и несопоставимых тарифов.
- Непонятно, сколько стоит вся поездка, включая багаж, сборы и трансфер.
- Отель выглядит красиво, но непонятны район, пляж, шум, подъём в гору, доступность для коляски и реальный номер.
- Дешёвый перелёт оказывается неудобным: ночные стыковки, смена аэропорта, отдельные билеты.
- Семейные расходы, возраст детей, питание и дополнительные кровати меняют цену в конце поиска.
- Погода может испортить главную цель поездки; непонятно, чем заняться при дожде или сильной жаре.
- Условия отмены и возврата размыты или различаются по компонентам поездки.
- Клиент не понимает, кто отвечает за проблему после оплаты.
- Недоверие к ИИ, неизвестному бренду, искусственным скидкам и автоматической покупке.

Результат: таблица «сегмент → ситуация → проблема → доказательство → частота → ущерб → существующее решение → неудовлетворённая потребность → идея → проверка → метрика». Если частота неизвестна, так и напиши.

Составь план минимум 20 проблемных интервью по нескольким сегментам и 8–12 тестов прототипа. Задавай вопросы о последней реальной поездке, расходах и действиях; избегай вопросов «понравилась бы вам такая функция». Дай скрипт интервью, критерии набора и задания. Отдельно укажи, что интервью только запланированы, пока не проведены.

## 3. Конкуренты и свободное место на рынке

Проверь текущие версии Aviasales, Яндекс Путешествий, Островка, OneTwoTrip, Туту, Travelata, Level.Travel, Слетать.ру, а также подходы Booking.com, Expedia, Google Travel и релевантных AI-trip-planner сервисов. Международные продукты сравнивай как UX-референсы; доступность продаж и оплаты для РФ проверяй отдельно.

Для каждого оцени: поиск без заданного направления, бюджет всей поездки, несколько поставщиков, отели внутри города, прозрачность сборов, совместное сравнение, отмена, послепродажная помощь, качество мобильного интерфейса, погода на даты, климат вместо дальнего прогноза, персонализация и доверие. Дай конкретные примеры экранов или пользовательских сценариев с источниками. Не придумывай функции из названия бренда.

Сформулируй одно проверяемое позиционирование и 3–5 отличий, за которые клиент готов выбрать нас. Не используй «самый лучший», «самая низкая цена на рынке» или «полный автопилот» как недоказанные свойства.

## 4. Размер рынка

Рассчитай TAM, SAM и реалистичные сценарии достижимых продаж на 12 и 24 месяца. Разделяй туристов, поездки, пассажирские сегменты, бронирования, оборот продаж и комиссионную выручку.

Для сегмента до 150 000 ₽ нужна доля именно заказов за всю группу. Не умножай общий оборот туризма на произвольные проценты. Не используй пассажиропоток аэропортов как готовое количество туристических заказов: там есть прилёты, вылеты, стыковки, деловые поездки и иностранцы. Если доля московских отправлений или распределение чеков недоступны, покажи модель чувствительности и прямо назови её сценарием, а не измерением рынка.

Ранее озвученные в проекте оценки 800 тысяч продаж, 100 млрд ₽ и диапазон 150–300 млрд ₽ не являются подтверждённой базой. Перепроверь их с нуля либо оставь вне бизнес-плана.

## 5. Поставщики, API и сравнение цен

Проверь минимум три независимых кандидата для авиа, три для отелей, два для готовых туров и два для трансферов. Количество ключей не равно количеству независимых цен: учитывай общую группу, инвентарь и источник тарифов.

Для каждого поставщика зафиксируй: официальную документацию, доступность для выбранного юрлица РФ, процедуру доступа, договор, тестовый/боевой режим, валюты и расчёты, нетто/брутто, обязательную наценку, лимиты, обновление цен, правила кеширования и публикации, поиск, проверку цены, бронирование, выписку, отмену, поддержку и стоимость интеграции. Отдельно различай API кешированных цен, живой поиск, партнёрский переход и полный API продажи.

Сравни реальные эквивалентные предложения минимум на 30 поисковых сценариях и отдельно подробно покажи пять. Укажи точное время, даты, состав группы, рейсы, багаж, номера, питание, отмену, валюту, налоги и итоговую сумму. При отсутствии боевых ключей покажи только публичную розничную выборку и её ограничения; не называй её API-нетто-ценой.

Формула экономии: (сопоставимая базовая итоговая цена − наша итоговая цена) / базовая итоговая цена. Базой должна быть ясно выбранная реальная альтернатива. Сравнение с самым дорогим источником не доказывает преимущество перед лучшим конкурентом.

## 6. Алгоритм сборки всей поездки

Сначала применяй жёсткие ограничения клиента, затем ранжируй подходящие варианты. Нормализуй валюту, даты, часовые пояса, возраст детей, багаж, питание, отмену, число комнат, местные сборы, курсовую разницу, платежные комиссии и обязательные доплаты.

Объединяй одинаковые отели по надёжным идентификаторам; не смешивай номера и тарифы с разными условиями. Для авиа сравнивай сегменты, тарифную семью, авиакомпанию, аэропорты, багаж и изменение/возврат. Учитывай прибытие после полуночи, ночёвку на пересадке, поздний check-in, разные аэропорты и самопересадки.

Показывай 3–5 осмысленных вариантов: минимальная полная цена, лучший баланс, комфорт. Объясняй одну главную причину выбора и один существенный компромисс. Комиссия поставщика не должна скрытно ухудшать результат для пользователя; рекламное продвижение обозначай.

Перед оплатой заново проверь доступность всех компонентов. Опиши резервирование, сроки удержания, частичный успех, повтор запроса, идемпотентность, возврат и помощь человеку. Не заявляй гарантированную покупку «всего одним нажатием», если поставщики не позволяют согласованно удерживать компоненты.

## 7. Атмосфера города и погода

Дизайн: дорогой, воздушный, живой сайт с настроением отпуска. Пальмы, вода, узнаваемые городские силуэты и приятный свет. На первом экране — одна атмосферная сцена и доступный подбор. Никаких полноэкранных загрузчиков, обязательной экскурсии по 3D, навязчивого звука или декоративных контролов вместо поиска.

Раздели два уровня реализации:

1. Лёгкий прототип: художественная панорама на объёмной WebGL-поверхности, небольшое движение камеры, погодные эффекты и интерактивные подписи. Прямо укажи, что это иллюстрация и условное расположение объектов.
2. Полная 3D-сцена: лицензированные GLB/glTF-модели зданий и достопримечательностей, реальные пространственные отношения, уровни детализации, оптимизированные текстуры и ограниченная область обзора. Не называй деформированное фото полноценной цифровой копией города.

Погода выбирается по конкретному дню поездки, координатам и часовому поясу. Солнце — ясный свет; облачность — мягкое освещение; дождь — видимые движущиеся капли, преломление на «стекле» и приглушённая сцена; снег — отдельная система частиц; закат — самостоятельный режим времени суток. Не делай молнии и резкие вспышки обязательными.

Не предсказывай погоду за пределами горизонта поставщика. Показывай «прогноза пока нет». Климатические нормы используй только из отдельного источника, с периодом усреднения и подписью «обычно в это время года», без календарного прогноза. Ручное переключение «а если дождь» всегда помечай как сценарий и не подменяй им прогноз.

Покажи план Б: крытые достопримечательности, кафе, спа, альтернативный маршрут. Проверяй часы работы, стоимость и доступность отдельно, не включай непроверенную активность в оплаченную стоимость.

В первой версии используй Сочи, Стамбул и Дубай. Для каждого подготовь источники о достопримечательностях и контентный план. Higgsfield или другой видеогенератор рассматривать как необязательный инструмент подготовки ассетов; учитывать лицензирование, права на материалы, размер файлов и постоянство геометрии между погодными версиями. Не строить рабочий поиск вокруг непрерывной генерации дорогого видео.

## 8. Продажный интерфейс и доступность

Главная цепочка: настроение/направление → даты и бюджет → несколько полных поездок → сравнение → состав и условия → подтверждение цены → покупка/переход к продавцу → документы и поддержка.

Сохраняй введённые параметры при смене города. Дай варианты отелей внутри выбранного города. Цена всегда за весь состав группы и весь срок, а цена за ночь — дополнительная, не основная. Детали открываются постепенно. Показывай содержательные пустые состояния и восстановление после ошибок.

Все действия доступны с клавиатуры и на мобильном. Учитывай prefers-reduced-motion, явную паузу, отключение движения вне экрана и статическую замену при отсутствии WebGL. Атмосфера не должна блокировать клики и прокрутку, мешать чтению или снижать доверие. Фотографии конкретного отеля должны относиться к этому отелю; иллюстрацию города нельзя выдавать за номер или бассейн гостиницы.

## 9. Экономика и разумная автоматизация

Рассчитай экономику на заказ: комиссия/наценка − эквайринг − API − маркетинг − поддержка − ожидаемые возвраты/ошибки − другие переменные затраты. Разделяй валовую выручку, маржинальный доход и чистую прибыль. Дай сценарии CAC, конверсии, среднего чека, повторных покупок и сезонности; неизвестные значения отмечай допущениями.

Автоматизируй сбор предложений, дедупликацию, проверку свежести, уведомления по согласию, подготовку документов в рамках API, типовые вопросы и контроль ошибок. Определи случаи передачи человеку: срыв рейса, спорный возврат, несовпадение документов, недоступность одного компонента, жалоба и нестандартная потребность.

Для продвижения исследуй спрос на страницы направлений/бюджетов/погоды, полезные подборки и повторные обращения. Контент должен основываться на актуальных данных и проходить контроль. Не обещай бесплатный трафик и бизнес без участия человека; не создавай массовый спам или фальшивые отзывы.

## 10. Проверка результата

Сформируй план экспериментов: обычная фотография против атмосферной сцены; три рекомендации против длинной выдачи; полная цена против раздельных компонентов; ручной ввод против короткого брифа; отображение прогноза и плана Б.

Для каждого заранее определи основную метрику, защитные метрики, минимальный эффект, расчёт выборки и срок. Измеряй завершение поиска, время до осмысленного выбора, переход к составу/оплате, конверсию в подтверждённый заказ, ошибки цены, обращения и маржинальный доход. Не считай длительное рассматривание 3D доказательством роста продаж.

Целевые технические ограничения, требующие реального измерения: LCP ≤ 2,5 с, INP ≤ 200 мс, CLS ≤ 0,1 на 75-м перцентиле целевых мобильных устройств; загружать движок и остальные города отдельно; одна активная сцена; ограничение разрешения, частоты кадров и GPU-памяти. Если цели недостижимы, автоматически упрощать атмосферу, сохраняя покупку.

## 11. Что выдать

1. Краткое решение: какой сегмент обслуживаем первым и какую проблему решаем лучше существующих альтернатив.
2. Реестр источников и таблицу подтверждённых проблем/гипотез.
3. Матрицу конкурентов и расчёт рынка с прозрачными допущениями.
4. Матрицу поставщиков API и протокол реального сравнения цен.
5. Пользовательский путь, приоритеты функций и исключения из первого релиза.
6. Дизайн-бриф, погодную модель, сценарии 3D и ограничения производительности.
7. ТЗ разработчику: данные, интерфейсы, состояния, алгоритмы, операции покупки, тесты и критерии приёмки.
8. Финансовую модель, план экспериментов и дорожную карту 30/60/90 дней.
9. Список оставшихся неизвестных и конкретных способов их проверить.

Если доступен репозиторий, после исследования реализуй согласованный объём прототипа, сохрани существующие полезные функции, проверь реальные пользовательские сценарии и дай рабочую ссылку. В каждом отчёте отдельно перечисляй: действительно работает, демонстрируется, требует доступа или договора. Начинай с доказательств и выполняй работу последовательно.