Лояльность в индустрии гостеприимства без баллов: память, признание и восстановление

Основная идея

Лояльность в индустрии гостеприимства растёт, когда гость чувствует, что его точно помнят и надёжно поддерживают, а не просто вознаграждают за транзакции.

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

Что изменилось и почему это важно сейчас

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

Построение операционной модели

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

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

Измеряйте результаты

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

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

Где возникают сбои

Программа лояльности может превратиться в книгу скидок, если оперативная память сотрудников фрагментирована по объектам и каналам.

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

Как это выглядит на практике

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

Основной контраргумент

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

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

Что должно и чего не должно быть в записи гостя

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

Записывайте в языке гостя. Запись, что предпочитает тихую комнату — нейтрально и действует; запись с интерпретацией причин — нет, и она плохо смотрится, если данные станут доступны гостю, что время от времени случается.

Делайте запись компактной. Шесть-семь полей читаются перед приездом; сорок — нет. Нечитаемая запись хуже отсутствия: создаёт иллюзию знаний, которые не используются.

Момент прибытия: признание либо срабатывает, либо нет

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

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

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

Честная оценка затрат

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

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

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

30-дневная последовательность внедрения

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

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

Отслеживайте выполнение предвстречных процедур, а не размер базы данных

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

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

Редакционный вывод

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