Мобильное приложение для сетевого турагентства: зачем оно нужно и как устроен проект

За последние годы мы сделали до десяти мобильных приложений для турагентств, входящих во франчайзинговые сети крупных туроператоров — Coral Travel, Pegas Touristik, TEZ TOUR, ANEX Tour. Для агентств одной из сетей это уже третье приложение подряд.

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

Речь идёт о приложении агентства, а не туроператора

Различие принципиальное, и его часто смазывают. Туроператор создаёт турпродукт: договаривается с отелями и перевозчиками, формирует пакеты, ведёт всё это в системе бронирования вроде САМО-тур или Мастер-тур. Агентство продукт не создаёт — оно продаёт чужой, получая доступ к поиску и ценам оператора.

Из этого следует, каким может быть приложение агентства. Это не система бронирования и не личный кабинет туриста. Это витрина поиска по турам оператора плюс короткий путь к живому менеджеру. Всё, что сложнее, живёт на стороне оператора, и агентство не может это ни изменить, ни ускорить.

Зачем это агентству: не удержание, а новые клиенты

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

Механика такая. Агентство франчайзинговой сети живёт на брендовом трафике оператора. Человек уже выбрал продукт и ищет «Coral Travel», «Pegas», «TEZ TOUR» — ему нужно понять, где купить. В вебе за этот запрос конкурируют сам туроператор, десятки агентств той же сети, агрегаторы и отзовики: выдача плотная, пробиваться дорого и долго.

Те же люди вбивают то же название в строку поиска магазина приложений. Конкуренция там тоже есть — операторы выкладывают свои приложения, часть агентств тоже это делает, — но она меньше в разы: каталог магазина несопоставим по объёму с вебом, и карточек по конкретному туристическому бренду единицы, а не сотни. Если приложение аккуратно оптимизировано и стоит в выдаче магазина сверху, агентство получает нового клиента почти бесплатно — человек не искал агентство, он искал оператора.

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

Важная оговорка: всё это работает только там, где бренд есть. Само по себе приложение спроса не создаёт.

Право на бренд: без договора с оператором разговора нет

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

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

Отдельно: логотипы и фирменный стиль оператора — тоже предмет договора, а не свободный ресурс. Что именно можно использовать в интерфейсе, определяет соглашение конкретного агентства, и это стоит уточнить до того, как утверждён дизайн.

Что внутри: несколько экранов и один важный модуль

Технологически такие приложения устроены просто, и мы этого не скрываем. Это гибрид: веб-часть на HTML и JavaScript в нативной оболочке. Веб-часть мы собираем на собственном небольшом фреймворке, который переиспользуем от проекта к проекту: экраны переключаются с анимацией, листаются пальцем, ведут себя так, как человек ожидает от настоящего приложения. Экранов обычно три-пять, в зависимости от задачи агентства.

Сердце приложения — модуль поиска туров. Свой поиск мы не пишем: агентство продаёт чужой продукт, и правильное решение здесь — готовый виджет поиска. Чаще всего это Турвизор, в отдельных проектах — Слетать.ру. Через него приложение показывает туры, цены и горящие предложения, а дальше пользователь отправляет заявку менеджеру.

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

Как это выглядит на практике, видно в наших работах: приложение для поиска туров Coral, приложение Pegas и приложение TEZ TOUR.

RuStore: самый быстрый способ попробовать

Если задача — проверить гипотезу, а не сразу выйти на все платформы, начинать стоит с RuStore. Для нас это самый простой канал публикации, и для заказчика тоже: меньше требований к аккаунту, меньше документов, быстрее проверка. Загрузка занимает порядка двух недель против существенно более долгого пути в Google Play.

Практический сценарий такой: собираем приложение, публикуем в RuStore, смотрим на реальные установки и заявки, а уже с этими данными решаем, идти ли в Google Play и делать ли версию для iOS. Это дешевле, чем сразу штурмовать все магазины, и понятнее, чем спорить о гипотезах на словах.

Для Android это ещё и не эксперимент на обочине: мультимагазинная дистрибуция — норма. Кроме Google Play на устройствах живут RuStore и предустановленные магазины производителей, и обновления приложение получает из того магазина, откуда его поставили. То есть отсутствие в Google Play не означает отсутствия аудитории, а присутствие сразу в двух магазинах требует и двух публикаций.

Сроки: разработка предсказуема, публикация — нет

Разработка занимает три-четыре недели и делится примерно так:

• дизайн с согласованиями — одна-две недели;
• программная часть — неделя;
• сборка оболочки и тестирование — до недели.

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

Поэтому мы не обещаем дату выхода. Мы называем срок разработки и говорим, из каких этапов состоит публикация, — а дальше отсчёт идёт не от готовности кода, а от даты подачи документов в магазин.

Что кроме разработки

Примерно половина работ по такому проекту вообще не про программирование. Это аккаунты, документы, тестирование и модерация.

Аккаунт разработчика

Личный кабинет в магазине регистрирует и оплачивает сам заказчик — на себя или на свою компанию. Мы помогаем: подсказываем, что заполнять, какие документы готовить, как пройти проверку, — но на себя ничего не оформляем. Приложение, аккаунт и все доступы принадлежат клиенту, и при смене подрядчика ему не приходится ничего отвоёвывать.

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

Документы

Подтверждение прав на бренд, реквизиты, данные компании, политика конфиденциальности. Собирает это заказчик, а не разработчик, и именно здесь проекты чаще всего встают.

Модерация

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

Что происходит после запуска

Приложение — не разовая работа, хотя выглядит именно так.

Обновления требований магазинов

Google регулярно поднимает минимальную версию Android, меняет правила по данным и разрешениям. Приложение, которое год не трогали, в какой-то момент просто перестают показывать новым пользователям.

Push-уведомления

Их обычно ждут как главный инструмент возврата — горящие туры, дедлайны оплаты. Важно понимать, что это отдельная работа, а не функция, которая появляется вместе с приложением. Нужно подключить сервис рассылки: на Android это Firebase Cloud Messaging от Google либо пуш-сервис самого RuStore. Публиковаться в Google Play для этого не обязательно — Firebase прямо разрешает распространять приложение и вне своего магазина, но доставка уведомлений через него работает только на устройствах, где есть сервисы Google. На аппаратах без них — например, на новых Huawei — нужен пуш-сервис RuStore. Практический вывод: если пуши для агентства важны, закладывайте их в проект отдельной строкой и решайте на старте, через какой сервис они пойдут.

Контент и предложения

Туры в приложении обновляются сами — их отдаёт виджет поиска (Турвизор или Слетать.ру). Всё остальное — акции, тексты, баннеры — обновляет агентство.

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

Кому приложение не нужно

Мы регулярно отговариваем, и вот критерий. Приложение имеет смысл, если выполняется хотя бы одно из двух условий:

• у агентства есть узнаваемый бренд сети, по которому люди ищут;
• есть входящий трафик — контекстная реклама, таргет, действующая база клиентов.

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

С приложением это критичнее, чем с сайтом. Сайт без рекламы всё-таки индексируется в Яндексе и Google и потихоньку набирает поиск по десяткам разных запросов. У приложения такого длинного хвоста нет: либо его ищут по бренду, либо ставят по рекламе, либо не ставят вовсе.

Отдельно про iOS. Ограничения в России известны, но пользователей iPhone много, и для части проектов версия под iOS оправдана — мы её делаем, когда Android-версия уже показала результат. Начинать с iOS мы не советуем.

Как это выглядит на цифрах

Приложение агентства сети Coral Travel, которое мы запустили этим летом: первая версия опубликована 1 июня 2026 года, к 6 сентября — более 3000 установок и 127 оценок в RuStore. Данные открыты в .

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

Коротко

Приложение сетевого турагентства — это не система бронирования и не инструмент удержания лояльной базы. Удержание — задача туроператора. Агентству приложение приводит нового клиента: человек ищет бренд оператора в магазине приложений и находит там вас. Повторные продажи приходят потом — если поездка прошла хорошо и менеджеры агентства отработали с клиентом как следует. Приложение только приводит человека и остаётся у него на телефоне; удержит его не оно и не бренд оператора, а работа сотрудников.

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

Вопросы и ответы

• Можно ли использовать название туроператора в названии приложения?

  Да, если у агентства есть подписанный договор с оператором, дающий право использовать марку. Магазины приложений это проверяют. Без договора публиковаться нельзя.

• Сколько времени занимает публикация?

  Разработка — три-четыре недели, и этот срок предсказуем. Публикация — нет: RuStore обычно около двух недель, Google Play дольше, там проверка документов плюс обязательные четырнадцать дней закрытого тестирования с двадцатью тестировщиками. Любой запрос дополнительных документов со стороны магазина добавляет к проекту неделю-другую, поэтому точную дату выхода мы не обещаем.

• Нужно ли приложение, если уже есть хороший мобильный сайт?

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

• Кому принадлежит приложение и аккаунт разработчика?

  Заказчику. Личные кабинеты в магазинах он регистрирует и оплачивает сам, на себя ничего мы не оформляем — только помогаем пройти регистрацию и подготовить документы. Для Google Play и App Store обычно советуем оформлять аккаунт на физическое лицо: провести юридическое сейчас крайне сложно.

• Можно ли сделать только под iOS?

  Технически да, но мы не советуем начинать с этого. Разумнее выйти в RuStore, посмотреть на реальные установки и заявки и уже потом решать по Google Play и iOS.