Единая запись гостя: дисциплина, стоящая за узнаванием

Почему в отелях появляются дубли профилей?

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

Бронирования через каналы — частый источник. OTA передаёт имя и номер телефона; PMS создаёт запись; позже гость бронирует напрямую с адресом электронной почты. Теперь есть два профиля и нет общего идентификатора.

Решение — не периодическая чистка. Это правило сопоставления в момент создания, видимая подсказка «возможный дубль» и процесс объединения, за который кто-то отвечает.

Что должно входить в профиль гостя?

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

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

Если у поля нет владельца и ему нет применения, это ответственность. Собирайте меньше и поддерживайте собранное в актуальном состоянии.

Как следует объединять дубли?

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

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

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

Кому что должно быть разрешено видеть?

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

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

Как не давать профилям устаревать?

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

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

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

Что следует измерять?

Измеряйте то, что меняет поведение, а не размер базы данных.

• Доля дублей: объединённые профили на сто созданных новых профилей
• Полнота профиля: процент с подтверждённым контактом и согласием
• Уровень узнавания: повторные гости, чей профиль использовался при заселении
• Прикрепление к точкам продаж: доля проживающих гостей с начислением в точке продаж
• Урегулирование жалоб: повторные жалобы одного и того же гостя

Как должны меняться карточки гостей в зависимости от размера объекта?

На объекте с 10–60 номерами узнавание гостя обычно живёт в памяти небольшой команды. Сотрудники помнят постоянного гостя, любимый номер и жалобу с прошлой весны, но эти знания не в системе и уходят вместе с человеком. Задача проектирования — фиксировать немногое, что команда действительно будет поддерживать: подтверждённые телефон и электронную почту, язык, структурированное предпочтение по номеру или этажу, требования к питанию и согласие. Долгое поле свободных заметок — это место, где умирают благие намерения. Профили создаются на стойке и через бронирования OTA, поэтому правило «сначала поиск, потом создание» важно и здесь; два профиля одного гостя одинаково легко получить и на объекте с 40 номерами, и на объекте с 400. Один человек, обычно руководитель службы приёма или владелец, должен отвечать за объединение и его проверку. Цель — не маркетинговая база данных. Достаточно преемственности, чтобы вернувшемуся гостю не задавали те же вопросы дважды, и достаточно дисциплины, чтобы карточка оставалась точной к следующему проживанию.

При 60–250 номерах гостя обслуживает больше людей в большем числе мест. Стойка, бронирование, ресторан, спа и отдел продаж обращаются к карточке, и каждому нужен свой взгляд на неё. Именно тогда ролевой доступ перестаёт быть формальностью: хостес ресторана нужна отметка об аллергии, а не кредитный лимит, а отделу продаж нужен корпоративный тариф, а не история жалоб. Интеграции тоже начинают иметь значение. Если POS и PMS хранят отдельные карточки гостей, узнавание в точке продаж зависит от того, кто-то введёт имя заново. Объекту следует решить, какая система является операционным источником истины, и синхронизировать наружу управляемое подмножество, а не позволять каждому подразделению вести свой список. Согласие заслуживает такой же дисциплины: канал, дата и источник фиксируются по каждому гостю, а отзыв соблюдается везде, куда данные передавались. Назначенный ответственный за объединение дублей и проверка доли дублей раз в 30 дней дадут больше, чем ежегодная кампания по очистке. Проверка должна смотреть на объединённые записи, а не только на их количество.

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

Определите границы до выбора полей. Первое — для чего нужна карточка: для преемственности обслуживания, коммерческой истории или маркетинга, потому что каждая цель оправдывает разные данные и разные сроки хранения. Второе — источник истины для идентичности и истории проживаний и то, какие системы получают подмножество. Третье — кто может видеть чувствительные заметки и как журналируется доступ. Четвёртое — модель согласия, включая то, как отзыв распространяется на каждую систему, получившую данные. Пятое — политика объединения: кто рассматривает кандидатов, какие доказательства нужны и как ведётся аудиторский след. Затем задайте минимальный набор полей, который команда будет поддерживать в точке обслуживания, и сопротивляйтесь желанию добавлять поля «на всякий случай». Если ответ хотя бы на один из этих вопросов неясен, набор полей, вероятно, слишком широк для первого выпуска. Граничное условие — правовое: правила хранения, трансграничной передачи и документов, удостоверяющих личность, различаются по юрисдикциям, и групповой стандарт должен оставлять место для местного обязательства. Карточка, которую нельзя законно хранить, не является активом.

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