Туристический интернет-портал — один из самых сложных видов порталов. Он должен одновременно вдохновлять на поездку, помогать спланировать маршрут, подсказывать, где поесть и что посмотреть, и оставаться полезным уже на месте, когда гость стоит посреди незнакомого города со смартфоном в руке. При этом у портала сильные конкуренты: агрегаторы бронирования, карты и путеводители в соцсетях.
Регионы, туристические объединения и компании вкладываются в такие проекты, но многие порталы так и остаются витриной, куда заходят один раз. Ниже — семь типичных ошибок, которые мы встречаем при разработке интернет-порталов для туризма, почему их допускают и почему они гарантированно снижают отдачу.
У туристического портала короткое окно внимания. Человек выбирает направление за несколько вечеров, сравнивая десятки источников. Если портал не помог в эти вечера, второго шанса не будет: гость уйдёт к агрегатору или в соцсети и вернётся туда же, когда будет на месте.
Кроме того, портал обычно финансируется из ограниченного бюджета, а переделки после запуска случаются редко. Ошибки, заложенные на этапе проектирования, живут годами. Поэтому создание интернет-порталов для туризма требует особенно тщательной работы со сценариями — подробнее о нашем подходе на странице разработка интернет-порталов.
Самая частая ошибка — портал строят как справочник: разделы «Музеи», «Отели», «Рестораны», «Пляжи», в каждом — длинный список карточек. Так делают, потому что это просто: структура повторяет таблицу с данными.
Но гость думает не категориями, а задачами: «куда поехать на выходные с детьми», «что посмотреть за один день», «где поужинать с видом на море». Каталог заставляет его самому собирать поездку из кусочков. Правильный портал предлагает готовые сценарии и маршруты, а каталог остаётся справочным слоем под ними.
Портал проектируют на большом мониторе, а мобильную версию получают автоматически, сжимая колонки. В результате на смартфоне — бесконечная прокрутка, мелкие кнопки и карты, которые невозможно двигать пальцем.
При этом больше половины визитов на туристический портал приходится на смартфоны, а во время поездки — почти все. Мобильные сценарии «что рядом», «как добраться», «открыто ли сейчас» должны быть главными, а не второстепенными.
На старте портал наполняют с энтузиазмом, но через полгода в афише висят прошедшие события, а в карточках — неверные часы работы и закрытые заведения. Гость один раз натыкается на закрытую дверь — и перестаёт доверять порталу.
Причина — отсутствие процесса обновления. Ошибка проектирования здесь в том, что не продумали, кто и как будет поддерживать данные:
Туристические порталы любят вдохновляющие фотографии и поэтичные тексты. Это правильно для первого экрана, но дальше гостю нужны факты: цена билета, время работы, как добраться, есть ли парковка, можно ли с собакой, сколько времени займёт посещение. Если этой информации нет, человек идёт искать её в другом месте — и уже не возвращается. Хорошая карточка объекта отвечает на практические вопросы в первых строках, а атмосферный текст и галерею оставляет ниже — для тех, кто уже решил поехать.
Портал рассказывает о гостинице, но для бронирования отправляет на сторонний сайт, где всё нужно искать заново. Каждый лишний переход теряет часть аудитории. Даже если портал не принимает оплату сам, он должен вести на конкретную страницу бронирования с сохранёнными датами, а в идеале — показывать доступность прямо в карточке.
Туристический портал конкурирует не с другими порталами, а с агрегаторами и картами в телефоне гостя. Выигрывает тот, кто экономит больше времени.
Портал делают только на русском языке и только для гостей из других регионов. Но у туристического направления несколько аудиторий: иностранные гости, местные жители, которые ищут, куда сходить в выходные, бизнес-путешественники, организаторы мероприятий. Каждой нужны свои сценарии и свой вход. Для приграничных и курортных регионов — как Калининградская область — многоязычность вообще базовое требование.
Портал запускают без настроенных целей и не знают, какие разделы работают, где пользователи уходят и какие маршруты сохраняют. Через год невозможно ответить, окупились ли вложения и что развивать дальше. Похожая проблема встречается и в личных кабинетах — мы разбирали её в статье об ошибках онбординга.
Правильный подход — заложить аналитику ещё в прототипе: какие действия считаем успехом, как измеряем вовлечённость, какие отчёты нужны заказчику.
Если свести все ошибки в один список требований, получится минимальный набор, без которого портал не стоит запускать:
Этот список не про объём функций, а про приоритеты. Лучше запустить портал с маршрутами, мобильным режимом и живыми данными, чем с десятком разделов, которые никто не обновляет.
Попросите трёх–пяти человек, которые никогда не были в регионе, спланировать с помощью портала поездку на выходные, а затем пройти один день маршрута со смартфоном. Их вопросы и остановки покажут слабые места лучше любого внутреннего обсуждения. Такой тест занимает неделю и дешевле любой переделки после запуска.
Вопрос «интернет-порталы цена» обычно задают про стоимость разработки. Но для туристического портала важнее стоимость владения: наполнение, обновление данных, поддержка, продвижение. Портал, спроектированный без процессов обновления и без личных кабинетов для объектов, дёшево стоит на старте и очень дорого — через год, когда данные устарели и доверие потеряно.
Разумно распределить бюджет так, чтобы значительная часть пришлась на исследование и проектирование сценариев, а не только на визуальную часть. Именно этот этап определяет, будут ли порталом пользоваться.
Все семь ошибок имеют общий корень: портал проектируют от данных и от заказчика, а не от гостя. Лекарство тоже общее — начинать с исследования: как люди выбирают направление, планируют поездку и ориентируются на месте. Из этого вырастают сценарии, структура, мобильные функции и процессы обновления.
Сначала интервью с гостями и туроператорами, затем карта сценариев, потом прототип мобильной версии и тестирование на реальных пользователях. Каталог и административная часть проектируются после — как инструмент, обслуживающий сценарии.
У региона есть особенности, которые стоит учесть в портале с первого дня: сезонность, маршруты по побережью, особенности въезда и логистики. Onebanan проектирует порталы с учётом таких деталей и помогает выстроить процессы, чтобы портал оставался живым после запуска. Обсудить туристический портал можно на встрече в Калининграде или онлайн.
Честное сравнение двух внутренних систем: где заканчивается интранет и начинается корпоративный портал, и что нужно вашей компании на самом деле.
Психология первых минут: семь ошибок онбординга, из-за которых клиенты регистрируются в личном кабинете и больше никогда в него не возвращаются.
Фундаментальный разбор: что такое SaaS, почему модель подписки выгодна, какие бывают сервисы, из чего они состоят и как проходит их разработка.
© Onebanan Digital Agency.