Как не потерять гостя на сайте отеля

Гость уже пришёл на сайт отеля, выбрал номер — и всё равно может уйти бронировать через другой канал. Или оформить проживание напрямую, но так и не узнать, что в отеле есть ресторан, SPA, трансфер и другие услуги.

В опросе «Островка» участвовали 800 путешественников. Среди причин отказа от прямого бронирования они называли более высокую цену на сайте отеля — 33%, отсутствие программы лояльности — 21%, негибкие условия отмены — 20% и неудобный интерфейс — 20%.

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

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

Человек может искать не конкретный отель, а «отель с SPA», ресторан, конференц-зал, площадку для свадьбы, определённую категорию номера или гостиницу рядом с нужным местом. Ту же задачу можно сформулировать AI-сервису: например, попросить подобрать несколько вариантов по заданным условиям.

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

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

Эта логика важна и для SEO, и для GEO — оптимизации контента под ответы поисковых и AI-сервисов. Если ресторан, SPA, номера и мероприятия описаны несколькими абзацами на общей странице «Услуги», поиску сложнее подобрать точный ответ на конкретный запрос.

Яндекс Вебмастер указывает, что при выборе источников для ответов Алисы AI учитываются экспертность, полезность, оригинальность и содержательность страниц. Полноценная страница ресторана с меню, условиями бронирования и другой конкретной информацией в этом смысле полезнее, чем одно упоминание ресторана в общем описании отеля.

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

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

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

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

Один номер может продаваться по нескольким тарифам: с завтраком и без него, с возможностью отмены, по невозвратной цене или с предоплатой. Названия вроде «Базовый», «Оптимальный» и «Специальный» сами по себе мало что объясняют.

Гостю проще, когда условия можно сравнить рядом и до перехода к оформлению. В этот момент он уже не решает, нравится ли ему отель вообще. Он выбирает конкретный вариант проживания.

Номер выбран. Человек нажимает «Забронировать» и ожидает продолжить оформление с теми условиями, которые уже выбрал.

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

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

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

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

В одном из наших обследований смартфоны давали 68,1% визитов, но доля пользователей с зафиксированным целевым событием на мобильных устройствах была примерно в 2,1 раза ниже, чем на компьютерах. Причин у такой разницы может быть несколько, поэтому связывать её только с интерфейсом нельзя. Но при такой доле мобильного трафика бронирование со смартфона точно стоит проектировать и тестировать отдельно.

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

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

По данным TravelLine, в загородных отелях средний чек бронирований с дополнительными услугами, не включёнными в тариф, выше на 23%. Переносить эту цифру на все гостиницы нельзя, но она показывает, зачем учитывать дополнительные услуги ещё при проектировании сайта.

Человеку, который уже выбрал номер, можно показать SPA-программу, трансфер или подходящее специальное предложение. Главное — не мешать ему закончить бронирование.

Если во время оформления на экране появляется десяток дополнительных предложений, они скорее отвлекают. А связанная услуга рядом с подходящим тарифом или уже после основного действия воспринимается естественнее.

Здесь проще отталкиваться от конкретной задачи. Организатору конференции могут понадобиться номера для участников. Гостю SPA — проживание. Человеку, который бронирует номер, — трансфер или столик в ресторане.

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

Бывает наоборот: человек вообще не собирался начинать с номера. Он искал ресторан, SPA или панорамную террасу и сразу попал на страницу этой услуги.

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

Сначала такому посетителю нужны меню, часы работы, стоимость, условия посещения и бронирование. А уже после этого можно показать следующий логичный вариант — например, проживание после позднего ужина или пакет с номером для гостя, который выбирает SPA-программу.

При сравнении нескольких гостиниц человек оценивает не только номер. Фраза «отель находится в центре» даёт координату, но не отвечает на вопрос, что гость сможет делать после заселения.

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

Вместо общего «рядом с основными достопримечательностями» человек получает более практичную картину: чем можно заняться и насколько удобно будет жить именно здесь.

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

На сайте отеля такой инструмент помогает заранее оценить окружение и спланировать свободное время. Одновременно на страницах появляется конкретная информация о локации, которую могут использовать поиск и AI-сервисы.

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

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

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

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

Можно перевести меню и карточки номеров, а на следующем клике вернуть человека в русскоязычный раздел. Формально иностранная версия есть, но пользоваться ею от начала до конца нельзя.

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

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

Гость открывает страницу, выбирает номер, переходит к бронированию, смотрит ресторан или SPA. Ему неважно, что номерной фонд и бронирование могут находиться в одной системе, работа с гостями — в другой, а контент — в CMS.

Для него всё это один сайт.

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

Как организовать обмен, зависит от ИТ-инфраструктуры конкретной гостиницы. Где-то достаточно прямых интеграций, а в более сложном контуре может понадобиться отдельный интеграционный слой.

Похожий принцип работает с контентом. Номер, SPA-услугу, ресторан, зал или специальное предложение удобнее создавать как отдельные объекты и затем связывать между собой.

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

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

При изменении структуры нужно сопоставить старые и новые URL, а для изменившихся адресов настроить 301-редиректы. Также стоит проверить метаданные, канонические страницы, связи между языковыми версиями, карту сайта и правила индексации.

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

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

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

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