Единый профиль гостя: какие данные собирать и как не плодить дубли

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

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

Какие данные нужны в профиле

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

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

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

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

Сначала разберите источники, потом переносите базу

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

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

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

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

Loona.ai подключается к системам бизнеса через доступные интеграции; также предусмотрены API и вебхуки. Это способы обмена данными, а не подтверждение переноса любых полей из любой базы. До начала работ согласуйте состав данных, правила обновления и проверку результата. CRM не заменяет кассовую или учётную систему.

Как работать с возможными дублями

Сначала договоритесь, какую запись считать основной и кто принимает решение в спорном случае. Одинаковое написание телефона полезно для поиска совпадений, но не доказывает, что за всеми записями стоит один человек.

Следующий порядок - рекомендация по организации работы с базой. Он не описывает подтверждённый механизм автоматического объединения карточек в Loona.ai.

Приведите контакты к согласованному виду

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

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

Разделите совпадение и решение об объединении

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

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

Проверьте историю, а не только список карточек

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

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

Как учитывать согласия и доступ сотрудников

В CRM-презентации Loona.ai описаны фильтры по согласию на получение рассылок и настраиваемые согласия при регистрации. Эти инструменты помогают отбирать аудиторию, но не заменяют проверку основания, содержания и актуальности согласия.

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

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

Для сети единая база не должна означать одинаковый доступ для всех. В Loona.ai предусмотрены общая гостевая база по заведениям и брендам, а также настройка прав сотрудников. На этапе внедрения определите, кому нужны контакты, кому - история обслуживания и кто вправе исправлять сведения. Общая база сама по себе не отвечает на вопрос, можно ли использовать данные одного бренда для коммуникаций другого: это нужно оценить отдельно.

Как использовать профиль в работе ресторана

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

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

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

Работа с несколькими заведениями. Общая база позволяет рассматривать историю в контексте сети, а права сотрудников - ограничивать доступ. Заранее определите, для какой задачи вы смотрите данные: конкретного ресторана или нескольких точек. В инструкции по аналитике Loona.ai есть важная оговорка для описанной вкладки: фильтр по точке продаж не фильтрует аудиторию. Не переносите смысл одного фильтра на все отчёты и выборки.

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

Что проверить перед использованием базы

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

1. Найдите гостя из каждого подключённого источника. Проверьте контакт и связь с историей.
2. Сопоставьте покупку в исходной системе и CRM. Убедитесь, что повторная передача не создала вторую такую же операцию.
3. Разберите запись с разным написанием телефона и случай общего номера у разных людей. Зафиксируйте, кто принимает решение о совпадении.
4. Проверьте отменённую бронь и возврат покупки. Уточните, как они отражаются в профиле и выбранном отчёте.
5. Проверьте запись с неизвестным согласием и запись с отказом. Убедитесь, что выбранная рекламная аудитория не включает их вопреки согласованным правилам.
6. Откройте профиль под каждой рабочей ролью и проверьте, какие сведения доступны сотруднику.

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