Программа лояльности живёт на ресепшене. И обычно там она и умирает

Мы видели программы, у которых был блестящий стратегический документ на 80 страниц, правильно построенные tier'ы, экономика на 3 года вперёд — и которые умерли через 6 недель после soft-launch.

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

Где это ломается на практике

Сценарий 1: Check-in

Гость приехал, имеет Silver-статус. Ресепшен не знает, что:

• Silver получает приоритет на upgrade при availability
• Silver получает welcome-drink в баре
• Silver видит свой tier-бейдж в системе перед глазами receptionist'а

Не активирует — гость не чувствует разницу. На следующий год гость думает: «А зачем мне эта программа? Я ничего не получил».

Сценарий 2: Check-out

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

Если ресепшен говорит «спасибо, до свидания» — программа невидима. Если говорит «вы заработали 4,580 баллов, до Gold вам осталось 6 ночей, забронируйте сейчас на январь» — это retention в действии.

Сценарий 3: Жалоба

Гость недоволен. Loyalty-программа имеет «service recovery» механизм: ресепшен может выдать compensation points мгновенно (например, до 2000 баллов без эскалации).

Большинство отелей этого не настраивают. Жалоба эскалируется к менеджеру, гость уходит раздражённым. С playbook'ом и authority к ресепшену — жалоба гасится за 2 минуты и превращается в loyalty story.

Что должно быть в operations playbook'е

1. Скрипты для 8 типовых сценариев

Check-in (gold-tier), check-in (новый member), check-out, жалоба, спор по баллам, отказ от участия, gift-status просьба, family-account.

Каждый скрипт — 3-4 предложения с конкретными словами. Не «расскажите про программу», а ««Иван Сергеевич, как наш Gold-гость, мы подготовили для вас suite на этаже выше. Если устроит — заселим прямо сейчас»».

2. Authority matrix

Кто может выдать compensation points? Кто может зачислить баллы вручную? Кто может изменить tier?

Без чёткой матрицы — все вопросы идут к GM. GM перегружен. Не делает ничего. Программа умирает.

Правильно: ресепшен 0-2000 pts (без эскалации), supervisor 0-10000 pts, manager 0-50000, GM выше.

3. Tier-aware system prompts в PMS

Когда гость есть в системе, PMS должна показывать ресепшен:

• Tier (большой бейдж)
• Предпочтения (диета, температура комнаты, любимый этаж)
• Прогресс до следующего уровня
• Дату последнего визита
• 3-4 conversation hooks: «обычно бронирует в марте», «годовщина 14 февраля»

4. Daily huddle template

Каждое утро — 5-минутная летучка: «сегодня заселяются 2 Gold и 1 Platinum, для них приготовлены X, Y, Z. У одного гостя — годовщина».

Без этой летучки tier-инфо бесполезна — receptionist'у она недоступна в момент check-in'а, потому что он не помнит.

5. Monthly KPI для front-desk

Что мерим:

• % guests, у которых при check-in упомянут их tier (target: 95%+)
• % check-out'ов с упоминанием баллов (target: 80%+)
• Среднее compensation pts на жалобу (target: minимизировать)
• % gift-status registrations on-the-spot (target: 40%+ от eligible)

Что мы делаем в implementation-фазе

Поднимаем платформу — это технический tasks. Параллельно (а не последовательно!) пишем operations playbook для front-desk, проводим 2 тренинга по 3 часа с скриптами и role-play, ставим metrics-дашборд для GM, делаем weekly check-ins первые 6 недель после launch'а.

Это не extra. Это часть запуска. Без этого технически идеальная программа становится мёртвым активом — софт работает, но никто им не пользуется.

Самый частый компонент нашего проекта, который удивляет hoteliers — что мы реально проводим training-сессии и пишем скрипты. Большинство loyalty-софт-вендоров считают, что это «не их зона ответственности». Мы считаем — это самая важная зона.