Когда система бронирования ломается, это происходит беззвучно. Ни сигнала тревоги, ни жалобы на ресепшн, ни очереди у стойки. Гость закрывает вкладку и бронирует соседний отель, а потеря всплывает позже — слабым кварталом, который никто не может объяснить.
Один из отелей в нашем собственном портфеле — наглядный пример того, как это происходит. Его сайт до сих пор открывается по незашифрованному соединению с просроченным сертификатом, а кнопка «Забронировать» ведёт к форме запроса, письмо из которой падает в почтовый ящик. Гость, который уже принял решение, не станет заполнять эту форму и ждать ответа наутро.
Мы берём на себя весь путь — от прихода гостя на ваш сайт до денег, зачисленных по конкретной брони: сам модуль, платёж, доступность за тем и другим и языки, на которых всё это читают. За этот путь отвечает одна команда, и у сорвавшейся брони появляется ответственный.
Мы ведём тот модуль, через который номера действительно продаются: поиск, показ тарифов, подтверждение, которое получает гость. Его проверяют сначала на телефоне и только потом на компьютере — потому что именно там с ним встречаются ваши гости, — и за ним наблюдают, а не считают, что он работает. Сертификаты, продления и незаметное обслуживание, от которого зависит, откроется ли страница вообще, — наша забота, а не забота вашей стойки регистрации.
02
Прямые брони
Бронь, пришедшая через ваш собственный сайт, оставляет у вас комиссию, которая иначе ушла бы вместе с ней. Мы смещаем структуру продаж в сторону прямых броней, не отрезая агентов и каналы, которые заполняют межсезонье: свою долю они отрабатывают, но они не должны быть единственным входом. Это значит, что сайт, модуль бронирования и тарифы смотрят в одну сторону — и у гостя, который нашёл вас в канале, а потом зашёл на ваш сайт, нет причины возвращаться обратно.
03
Приём платежей
Гость платит той картой и в той валюте, которыми пользуется дома, — иначе вы теряете его на последнем экране. Мы настраиваем приём платежей в модуле так, чтобы сумма, авторизованная при бронировании, совпадала с той, что в итоге проходит по этой брони, и следим за этим шагом — отказы и отвалы, по рынкам и по способам оплаты, — чтобы сбой был замечен и разобран, а не остался необъяснимым провалом. Данные карт хранятся в системах, которые для этого созданы, и никогда — в почтовом ящике, в таблице или в сообщении на стойку регистрации.
04
Один источник доступности
Доступностью владеет одна система, а сайт, модуль бронирования и все каналы продаж читают из неё. Когда две системы одновременно считают, что последний номер у них, у стойки оказывается уже прилетевший гость с подтверждением, которое нельзя исполнить. Мы проектируем этот единственный источник до того, как к нему что-либо подключается, потому что за ошибку здесь платит живой человек в свою первую ночь.
05
На языках, на которых бронируют ваши гости
Процесс бронирования идёт на тех языках, на которых ваши рынки действительно бронируют, а не только на английском. Этот сайт работает на восьми, включая арабский с вёрсткой справа налево, и с бронированием отеля мы поступаем так же: названия категорий, условия тарифов, правила отмены и письмо-подтверждение, а не только главная страница. Гость, который прочитал о номере на своём языке, а на оплате встретил английский, может отвалиться на последнем шаге.
Мы ведём систему бронирования; записи о бронях и тарифах остаются в вашей PMS, и мы работаем по ней, а не в обход неё. Какой модуль, какой платёжный провайдер и какие каналы использует объект — решается по каждому отелю отдельно: от того, что у него уже есть, чем платят его рынки и что позволяют действующие договоры. Ничто здесь не предполагает, что вы начинаете с нуля. Условия ценового паритета остаются решением владельца, а данные гостей — в собственных системах отеля.