Данные о гостях в ресторанном бизнесе традиционно живут в разных системах и никогда не пересекаются: бронирования — в одном сервисе, чеки — в учётной системе, переписки — в мессенджере, отзывы — на агрегаторах. Для сети из 10 ресторанов эту проблему решили радикально: все источники данных объединили в единую базу, где каждый гость получает сквозной профиль.
Архитектура системы строится вокруг семи источников. Telegram даёт историю переписок между гостем и менеджером — контекст, который раньше терялся после закрытия диалога. Remarked, система онлайн-бронирования, передаёт данные о визитах: когда гость приходит, с кем, по какому поводу, какие комментарии оставляют сотрудники. IIKO — ресторанная учётная система — связывает коммуникации с реальным потреблением: составом заказа, суммой чека, длительностью визита. RocketData агрегирует оценки и отзывы с внешних площадок, добавляя в профиль качественную обратную связь. Мобильное приложение сети собирает ФИО, дату рождения, аллергии, предпочтения и историю покупок. Эквайринг фиксирует факт оплаты, сумму и статус транзакции. Наконец, технические логи хранятся отдельным слоем и привязываются к конкретному пользователю.
| Источник данных | Система | Что передаёт в профиль гостя |
|---|---|---|
| Мессенджер | Telegram | История переписок, обращения, уточнения |
| Бронирования | Remarked | Визиты, слоты, поводы, комментарии сотрудников |
| Учётная система | IIKO | Состав заказов, суммы чеков, длительность визита |
| Отзывы | RocketData | Оценки и тексты отзывов с агрегаторов |
| Мобильное приложение | Собственное | ФИО, телефон, аллергии, предпочтения, история покупок |
| Платежи | Эквайринг | Факт оплаты, сумма, дата, статус транзакции |
| Технические события | Внутренние логи | Сбои бронирования, ошибки оплаты, инциденты в приложении |
Последний элемент — технические логи — решает задачу, которую обычно игнорируют при проектировании CRM-систем. Когда гость жалуется, что оплата не прошла или билет не пришёл, поддержка теперь может проверить, был ли реальный сбой и на чьей стороне: пользователя, платёжного провайдера, партнёрской системы или внутренней инфраструктуры. Это принципиально меняет качество разбора претензий — вместо споров по памяти сотрудников решение принимается на основе данных.
Альфа-версия системы запущена и используется для разбора спорных ситуаций, контроля качества сервиса и сегментации рассылок.
Альфа-версия системы уже работает в операционной деятельности сети. Основные сценарии использования на текущем этапе — разбор конфликтных ситуаций, контроль качества коммуникаций (супервайзер может открыть любой диалог и оценить работу менеджера) и сегментация рассылок по фактической истории взаимодействия, а не по абстрактным группам. Например, можно выделить гостей конкретного ресторана или клиентов с определённым паттерном бронирований.
На уровне бизнес-аналитики система позволяет собирать агрегированные показатели по всей сети без дополнительных интеграций: DAU и MAU приложения, конверсию из просмотра слотов в бронирование, успешность оплат, retention и LTV гостей, динамику отзывов по ресторанам. Микроданные по каждому гостю складываются в картину работы всего продукта.
Следующий этап развития предполагает два ключевых сценария. Первый — ИИ-досье на гостя: при визите официант или менеджер получает краткое саммари с предпочтениями, историей визитов и персональными рекомендациями. Второй — формирование сегментов рассылки через текстовый запрос вместо ручной настройки фильтров: менеджер описывает нужную аудиторию словами, система интерпретирует запрос и строит выборку. Оба сценария уже заложены в архитектуру, но пока не запущены.
Подобный подход к консолидации данных не уникален для ресторанного рынка — крупные ритейлеры и телеком-операторы строят единые профили клиентов уже несколько лет. Для ресторанной отрасли, где данные традиционно фрагментированы между десятками специализированных сервисов, такая архитектура остаётся редкостью. Ключевая сложность здесь не техническая, а организационная: каждая из интегрируемых систем — Remarked, IIKO, RocketData — имеет собственную модель данных и логику идентификации пользователя, и сшить их в единый профиль без потери данных требует значительной инженерной работы.