Единый цифровой профиль гостя без риска штрафа: как связать QR-сценарий, согласия и CRM для возврата гостей

Зачем ресторану в 2026 году нужен именно «профиль гостя», а не просто база телефонов

Последние пару лет ресторанный рынок в России живёт в режиме, когда маржинальность всё меньше зависит от среднего чека и всё больше — от повторных визитов. Гость, который возвращается хотя бы раз в кварт, кормит выручку надёжнее, чем случайный турист с одной чашки кофе. Но именно этот гость у ресторана до сих пор «невидим»: его телефон теряется между QR-кодом на столе, официантом, администратором и доставкой. В итоге собственник смотрит в CRM и видит не человека, а набор обрывков — здесь онлайн-заказ, там бронь, тут отзыв, а связать это в одну историю не получается.

Одновременно усиливается давление регулятора. После волны проверок 2024–2026 годов рестораны всё чаще получают не абстрактные «рекомендации», а протоколы за обработку персональных данных. Штрафы за отсутствие согласия на маркетинговые рассылки, за хранение e-mail без основания, за передачу данных третьим лицам (например, сервисам рассылок) стали реальной статьёй расходов — особенно для сетей, где точек десятки.

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

В этом материале разберём, как связать в одну работающую систему три слоя — QR-сценарий на точке контакта, согласие на маркетинг как юридический и UX-инструмент, и CRM как хранилище и автоматизацию. Без штрафа, без «серых» рассылок и без раздражения гостя.

Как устроена легальная связка «QR — согласие — CRM»

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

Слой 1: точка контакта, где гость «отдаёт» свои данные

Это может быть QR на столе, QR на чеке, QR у входа, форма бронирования, окно оформления доставки, экран оплаты, бот в мессенджере, Wi-Fi с авторизацией. Все эти точки объединяет одно — там вы просите у гостя номер телефона или e-mail. По 152-ФЗ сам факт запроса не равен согласию. Но в момент запроса вы обязаны либо:

• получить согласие по утверждённой форме (отдельный чек-бокс с понятной формулировкой и ссылкой на политику), либо
• обрабатывать данные на ином законном основании (например, исполнение договора — доставка, бронирование).

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

Слой 2: согласие как объект хранения

Согласие — это не просто галочка. Это документ. Вам нужно хранить:

• текст согласия, который видел гость (версия политики, дата, формулировка);
• факт согласия (лог: когда, с какого устройства, какие каналы коммуникации выбраны);
• основание (например, «п. 1 ч. 1 ст. 6 152-ФЗ — согласие субъекта»);
• цель обработки («информирование об акциях, бонусах и событиях ресторана»).

Хранить это нужно отдельным логом, а не в виде комментария в CRM. Иначе при проверке вы не сможете доказать, что у конкретного e-mail было согласие именно на e-mail-рассылку, а не только на обработку в рамках заказа.

Слой 3: CRM как место, где сходятся данные

CRM — это не база согласий, а операционное хранилище профиля. Сюда попадает обезличенный или минимально-персональный набор: имя (если гость дал), телефон, e-mail, история заказов, броней, отзывов, источник визита. CRM должна уметь:

• принять событие из любой точки контакта через единый идентификатор (чаще всего телефон в нормализованном виде — +7…11 цифр);
• различать события «маркетинговые» и «операционные»;
• передавать в рассылочные сервисы (SMS, e-mail, мессенджеры) только тех гостей, у которых есть действующее согласие нужного типа;
• «гасить» согласие и автоматически исключать гостя из коммуникаций, если он отозвал его.

Если CRM не умеет работать с понятием «согласие как атрибут», вы рано или поздно начнёте слать тому, кому нельзя. Это либо штраф, либо жалоба, либо потеря доверия.

QR-сценарий как главная точка входа в профиль

QR-код давно перестал быть «ссылкой на меню». Для ресторана это точка, где гость добровольно достаёт телефон, показывает интерес и готов получить что-то взамен. Это окно, в котором разумно и законно запросить согласие на дальнейшую коммуникацию.

Что повесить за QR-кодом, чтобы получить согласие, а не отказ

Самый частый провал — гость видит QR, сканирует, попадает на лендинг с кнопкой «Получить скидку 10%». Он вводит телефон. Дальше — пустота или списание бонуса. Согласия на маркетинг нет, профиль пустой, через месяц вы шлёте ему SMS «Возвращайтесь!» и получаете претензию.

Работающий сценарий 2026 года строится иначе:

1. Лендинг за QR — это не «скидка», а ценность. Бронь очереди, доступ к Wi-Fi, заказ без официанта, участие в розыгрыше, запись на дегустацию, загрузка отзыва с фото за бонус.
2. Перед вводом контакта — экран согласия. Не внизу мелким шрифтом, а отдельный шаг. Формулировка — простым языком: «Я согласен получать SMS и e-mail о бонусах и событиях [название ресторана]. Политика обработки данных — по ссылке».
3. Разделение каналов. Чек-боксы «SMS», «e-mail», «push в мобильном приложении» — отдельно. Это и UX-плюс, и юридическая чистота: согласие на SMS ≠ согласие на e-mail.
4. Понятный бонус сразу. «За регистрацию — десерт в подарок при заказе от 1500 ₽ до воскресенья». Гость видит прямую связку «данные → выгода». Это повышает и конверсию, и качество согласия.

Какие данные реально нужны в профиле, а какие — лишний риск

Минимальный юридически безопасный набор на входе: телефон (для подтверждения и SMS), имя (необязательно, но удобно), согласие на конкретные каналы. Этого достаточно, чтобы:

• связать гостя в CRM по нормализованному телефону;
• отправлять ему операционные сообщения (статус брони, заказ доставки);
• при наличии согласия — маркетинговые SMS и e-mail.

Что не стоит собирать на входе «на всякий случай»:

• паспортные данные (кроме случаев, когда это требует закон — например, доставка алкоголя);
• точный адрес проживания (геолокация допустима только при явном согласии);
• дата рождения — только если вы заранее спроектировали «клуб именинников» и можете показать логику обработки;
• данные о детях, составе семьи и т. п. — это чувствительная категория.

Принцип: собирайте только то, что реально используется в течение 30 дней. Всё, что «потом пригодится», увеличивает ваш риск и не приносит выручки.

Как технически связать QR-сценарий и CRM

Вариантов несколько, и они не равноценны по риску.

• Прямая интеграция лендинга с CRM через API. Гость оставляет данные → CRM создаёт или обновляет контакт → CRM фиксирует согласие как атрибут → событие уходит в нужный сегмент. Это самый чистый сценарий.
• Промежуточный слой — форма-конструктор (Tilda, Marquiz, Smartis и аналогичные). Допустимо, если вы контролируете, что форма отправляет данные в CRM, а не просто хранит их у сервиса формы. Иначе вы нарушаете требование локализации и согласия.
• Сторонние платформы сбора лидов с собственной базой. Это самый рискованный путь: данные гостя становятся активом третьего лица, а вы — их получателем. Без согласия на передачу третьему лицу и поручения обработки — это нарушение.

В любом случае у вас должен быть один нормализованный идентификатор гостя. В 2026 году стандартом остаётся телефон в формате +7 и 10 цифр. По нему вы сшиваете заказы из разных каналов: доставка, бронь, QR-заказ, отзыв.

Согласие на маркетинг: как собрать его правильно и не потерять гость

Согласие — это единственное, что отделяет вас от штрафа в момент, когда вы решите написать гостю «не по делу». Поэтому к его сбору стоит относиться как к продукту, а не к формальности.

Минимально необходимые элементы согласия в 2026 году

Согласие должно содержать:

1. Название и реквизиты оператора (юрлицо или ИП, ИНН, адрес).
2. Цели обработки — конкретно: «информирование о скидках, акциях, событиях и бронировании в ресторане [название]».
3. Перечень персональных данных — телефон, e-mail, имя.
4. Перечень действий с данными — сбор, запись, систематизация, хранение, использование, передача сервису рассылок, обезличивание, удаление.
5. Срок действия согласия — до момента отзыва или определённый период (например, 3 года). Срок должен быть разумным.
6. Условия отзыва — «отозвать можно в любой момент, написав на e-mail … или по ссылке в каждом сообщении».
7. Ссылка на политику обработки персональных данных.
8. Отдельное подтверждение по каналам — SMS, e-mail, мессенджеры.

Где и как показывать согласие гостю

Несколько проверенных UX-паттернов, которые не раздражают гостя и сохраняют юридическую чистоту:

• Экран согласия отдельным шагом перед вводом контакта. Не внизу формы, а как полноценный шаг: «Шаг 1 из 2 — Контакт», «Шаг 2 из 2 — Подтверждение».
• Краткая формулировка согласия с раскрытием по ссылке. Длинный текст в форме снижает конверсию. Короткая формулировка «Я согласен получать SMS и e-mail об акциях [ресторан]» — рабочая.
• Возможность выбрать каналы. Чек-боксы «SMS», «e-mail», «push». Если хотите только SMS — берите только согласие на SMS.
• Двойное подтверждение для критичных каналов. SMS-код или e-mail-код, который одновременно подтверждает и контакт, и согласие. Это золотой стандарт 2026 года.

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

Регулятор (и гость) может в любой момент спросить: «А у вас точно было моё согласие?». Чтобы ответить «да», нужны не только сами данные, а доказательства:

• Версия политики на дату согласия. Не «текущая редакция», а та, что действовала в момент клика.
• Версия формулировки согласия — текст, который видел гость.
• Дата, время, IP-адрес, user-agent, идентификатор сессии.
• Перечень каналов, на которые согласился гость.
• Идентификатор источника — какой именно лендинг, форма, точка сбора.

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

Что делать с «наследием» — старыми базами без согласия

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

Что делать:

• Сегментировать базу на «есть согласие» и «нет согласия».
• Запустить легитимацию через re-permission кампанию: письмо или SMS с просьбой подтвердить согласие по короткой ссылке. Кто подтвердил — остаётся. Кто не подтвердил — через 30 дней уходит в «холодный» сегмент и не получает маркетинга.
• Документировать сам факт re-permission кампании: тексты письма, даты, статистика отклика.

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

CRM как ядро профиля: что должна уметь система в 2026 году

CRM — это не «адресная книга». Для ресторана это операционная память, в которой сходятся все цифровые следы гостя. Разберём, какие функции обязательны, а какие — маркетинговая обёртка.

Обязательная функциональность: идентификация, согласия, сегментация

В базовом наборе CRM должна:

1. Нормализовать идентификаторы. Один и тот же гость может прийти как «+7(903)123-45-67», «8 903 123 45 67» и «9031234567». CRM должна привести всё к единому виду и сшить профиль.
2. Хранить атрибут согласия по каналам. Поля типа consent_sms, consent_email, consent_push со значениями true/false/null и датами. Это минимальная гранулярность, без которой вы не сможете фильтровать аудиторию для рассылок.
3. Поддерживать событийную модель. Заказ, бронь, отзыв, визит в зал, обращение в поддержку — это события, привязанные к идентификатору гостя. Не «поля в карточке», а поток событий с таймстемпами.
4. Уметь работать с отзывом согласия. По e-mail или звонку приходит «отпишите меня». CRM должна зафиксировать отзыв, прекратить коммуникации и сохранить факт отзыва на нужный срок.
5. Поддерживать срок хранения. Через N месяцев без активности (типично — 12–24) CRM должна либо удалять данные, либо переводить их в обезличенный режим — в зависимости от вашей политики.

Расширенная функциональность: сегменты, сценарии, аналитика

На уровне «хочется большего»:

• Динамические сегменты: «Гости, которые были 2+ раз за квартал, оставили отзыв и не получали от нас SMS последние 30 дней».
• RFM-анализ: recency, frequency, monetary — классическая разбивка для ресторана.
• Триггерные сценарии: «Гость не был 45 дней → отправить бонус на день рождения, если он близко».
• Связь с POS: видеть средний чек, любимые позиции, предпочтения по кухне.
• Связь с системой бронирования: история визитов по брони, no-show.

Этот уровень не обязателен, но именно он превращает CRM из «хранилища» в инструмент возврата.

Какой стек выбрать: облачная или серверная CRM

Вопрос локализации данных в 2026 году критичен. Если вы обрабатываете данные граждан РФ, основная база должна храниться в России. Это касается:

• телефонов,
• e-mail,
• истории заказов,
• логов согласий.

Поэтому облачные зарубежные CRM, не имеющие серверов в РФ, — прямой путь к нарушению. Серверные или российские облачные решения — рабочий вариант. Среди популярных у ресторанов — российские платформы автоматизации, модули CRM в iiko и R-Keeper, отдельные специализированные сервисы.

Как интегрировать CRM с остальными системами, не размывая ответственность

CRM — не единственное место, где живут данные. Дополнительно у вас есть:

• POS-система (iiko, R-Keeper, Poster и др.) — заказы, оплаты.
• Платформа доставки — отдельные заказы, свои идентификаторы.
• Сервис рассылок (SMS, e-mail) — отдельная база подписчиков.
• Сервис отзывов — профиль гостя в системе отзывов.
• Система бронирования — брони и гости.

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

• иметь договор поручения обработки с каждым из них (если они обрабатывают ПДн от вашего имени);
• уведомить Роскомнадзор о каждом обработчике, если требуется;
• зафиксировать в политике обработки, кому и зачем передаются данные.

Это не мелочь. Именно здесь в 2024–2026 годах рестораны получали протоколы. Причём не за сам факт передачи, а за отсутствие договора и уведомления.

Сценарий «от гостя до возврата»: как связать всё в работающий конвейер

Теперь — конкретный сценарий. Пусть у нас сеть из трёх ресторанов в Москве, средний чек 1800 ₽, есть доставка, бронь, мобильное приложение. Цель — собрать профиль гостя легально и использовать его для возврата.

Шаг 1. Гость сканирует QR-код на столе

Гость заходит, садится, сканирует QR-код. Попадает на лендинг ресторана. Что он видит:

• кратко — что можно сделать без официанта: заказать, попросить счёт, вызвать менеджера;
• бонус за регистрацию: «Десерт в подарок при первом заказе от 1500 ₽»;
• кнопка «Получить бонус».

Дальше — экран согласия. Отдельный шаг. Два чек-бокса: SMS и e-mail. Под ними — короткая формулировка согласия и ссылка на политику. Гость подтверждает → вводит телефон → получает SMS-код → вводит код → попадает в мини-профиль, где может указать имя.

На сервере в этот момент:

• В CRM создаётся/обновляется контакт с идентификатором по телефону.
• В логе согласий появляется запись: время, IP, user-agent, выбранные каналы, версия политики.
• В системе лояльности создаётся запись гостя с начисленным бонусом.

Шаг 2. Гость делает заказ через QR-меню

Гость оформляет заказ через интерфейс QR. Этот заказ — событие, которое:

• уходит в POS для кухни;
• привязывается к профилю гостя в CRM;
• формирует чек для оплаты.

Поскольку это исполнение договора (заказ), отдельного согласия на обработку не нужно — есть законное основание. Но в чеке и истории заказа лучше явно указать, что данные используются для исполнения заказа, а не для маркетинга.

Шаг 3. Гость бронирует стол на следующий визит

Через неделю гость хочет забронировать стол. Бронь можно оформить:

• через сайт с системой бронирования;
• через мобильное приложение;
• по телефону через администратора.

Во всех случаях:

• вводится тот же нормализованный телефон;
• система бронирования проверяет, есть ли профиль в CRM;
• если есть — событие брони привязывается к профилю;
• если нет — создаётся новый профиль, но без автоматического согласия на маркетинг. Гость должен подтвердить его явно.

Шаг 4. Гость оставляет отзыв

Через три дня после визита гость получает e-mail «Спасибо за визит! Оцените, пожалуйста, ресторан — 1 минута». Это маркетинговая коммуникация? Нет — это обратная связь, часть клиентского опыта. Но формально это всё равно обработка ПДн с целью «улучшение сервиса», что тоже должно быть в политике.

Если гость оставляет отзыв, событие уходит в систему отзывов и в CRM. Это даёт вам:

• ещё одно событие в профиле (можно триггерить, например, программу лояльности для активных авторов отзывов);
• рейтинг, который влияет на сегментацию;
• повод для follow-up: «Спасибо за отзыв! Возвращайтесь в этом месяце — у нас обновилось меню».

Шаг 5. Гость «пропадает» на 40 дней

CRM видит: последний визит — 40 дней назад, заказов больше не было. Срабатывает триггерный сценарий:

• если согласие на e-mail есть — отправить письмо с персонализированным предложением;
• если согласия нет — ничего не отправлять, но сохранить событие «потенциальный возврат»;
• если согласие на SMS есть и событие критичное (например, гость — постоянный) — SMS с коротким предложением.

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

Шаг 6. Гость отзывает согласие

Гость приходит в ресторан и говорит: «Удалите меня из рассылки». Или отвечает на SMS словом «СТОП». Или нажимает «Отписаться» в письме.

Что должно произойти:

1. Зафиксировать отзыв в логе согласий: дата, канал отзыва, идентификатор гостя.
2. Обновить атрибуты согласия в CRM — поставить false или удалить атрибут.
3. Исключить гостя из всех активных рассылок. Сервис рассылок должен получить команду на удаление контакта из соответствующих списков.
4. Сохранить профиль в обезличенном виде для статистики, либо удалить — в зависимости от вашей политики. Если вы храните историю заказов — обезличивайте, не удаляйте полностью.

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

Самый частый страх ресторатора: «Если я начну собирать всё по закону, гость уйдёт». На практике — наоборот. Гость готов делиться контактом, если:

• Ценность очевидна и быстрая. «Скидка 10% на первый заказ» работает лучше, чем «Будьте в курсе наших новостей».
• Форма не длинная. Телефон + имя + согласие. Не больше. Остальное — потом, постепенно, по мере взаимодействия.
• Гость понимает, за что отдаёт данные. Формулировка «Я согласен получать SMS об акциях [ресторан]» понятнее, чем «Я согласен на обработку моих персональных данных в соответствии с политикой оператора».
• Гость может отказаться без потери базового сервиса. Если отказ от маркетинга мешает оформить доставку — это плохой UX и плохой юридический дизайн.

Конкретные UX-приёмы для роста согласий без потери гостей

• Бонус сразу, а не «потом». Не «зарегистрируйтесь, и мы когда-нибудь пришлём купон», а «вот ваш десерт в подарок — покажите официанту этот экран».
• Прогрессивный сбор данных. На первом шаге — только телефон. Через неделю после заказа — попросить e-mail. Через месяц — дату рождения, если планируете клуб именинников. Каждый шаг — отдельное согласие.
• Прозрачность. В каждом письме — короткая ссылка «Что это за письмо и как отписаться». Это не снижает open rate, но повышает доверие.
• Быстрый отзыв согласия. Если гость ответил «Стоп» — вы убрали его из рассылки в течение 24 часов. Это и закон, и репутация.

Как измерять качество согласий, а не только их количество

Соблазн — считать «базу растёт, значит, всё хорошо». Но для ресторана важнее не объём базы, а её здоровье:

• Доля согласованных контактов в базе. Если у вас 100 000 e-mail, но только у 40% есть действующее согласие — реальная маркетинговая база — 40 000.
• Конверсия в согласие на каждой точке сбора. Если из 1000 гостей QR согласие дали 50 — у вас проблема либо с UX, либо с ценностью предложения.
• Процент отписок по каждому каналу. Если по SMS он 8–10% — вы либо пишете слишком часто, либо не тем.
• Процент отзывов согласия. Сколько гостей за месяц сказали «отпишите». Высокий процент — сигнал, что вы переусердствовали.

Эти метрики должны быть в вашем дашборде рядом с классическими (средний чек, частота визитов). Иначе CRM остаётся «чёрным ящиком», а вы не понимаете, что с ней не так.

Типичные ошибки, которые приводят к штрафам и потере гостей

Разберём конкретные ошибки, которые в 2024–2026 годах встречаются у ресторанов чаще всего. Это то, на чём реально «горят» — и на проверках, и в глазах гостей.

Ошибка 1. Согласие «в нагрузку» к оформлению заказа

Сценарий: гость хочет заказать доставку. Чтобы оформить заказ, нужно поставить галочку «Согласен на получение рекламных материалов». Без галочки кнопка «Оформить» не активна.

Почему это плохо:

• юридически — согласие получено «в обмен» на услугу, что признаётся ненадлежащим;
• продуктово — гость злится и либо ставит галочку «на отвяжись», либо уходит к конкуренту.

Как правильно:

• согласие на маркетинг — отдельный шаг, отдельный чек-бокс, без которого заказ оформляется;
• если гость не дал согласия — он всё равно может заказать, просто не получит рассылок.

Ошибка 2. Хранение согласий «где придётся»

Часто согласия фиксируются только в CRM в виде комментария: «Согласие получено 12.03». Или только в сервисе формы-конструктора. Или только в почтовом ящике маркетолога.

Почему это плохо:

• при проверке вы не можете показать, что именно видел гость;
• при смене CRM или подрядчика вы теряете историю;
• при отзыве согласия вы не знаете, что и когда отзывать.

Как правильно:

• отдельное хранилище логов согласий (база, таблица, специализированный сервис);
• фиксация версии политики, текста согласия, технических метаданных;
• срок хранения — не меньше срока обработки.

Ошибка 3. Передача данных подрядчикам без договора

Ресторан отдаёт рассылку SMS сервису, e-mail — платформе рассылок, сбор отзывов — агрегатору, аналитику — внешнему сервису. Все они получают персональные данные. Но договоры поручения обработки есть не со всеми.

Почему это плохо:

• прямая ответственность оператора по 152-ФЗ;
• штрафы до нескольких сотен тысяч рублей;
• репутационный ущерб при утечке.

Как правильно:

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

Ошибка 4. Согласие не разделено по каналам

Сценарий: гость согласился на SMS, но не хочет получать e-mail. А CRM не умеет разделять каналы — есть поле «согласие: да/нет». В итоге гость получает и то, и другое.

Как правильно:

• отдельные атрибуты согласия по каждому каналу;
• сегментация в CRM и сервисах рассылок по этим атрибутам;
• возможность отозвать согласие по одному каналу, оставив по другому.

Ошибка 5. Отзыв согласия — это «долго и сложно»

Гость говорит: «Отпишите меня». Официант говорит: «Передам менеджеру». Менеджер передаёт маркетологу. Маркетолог вручную удаляет контакт. Проходит 2 недели. Гость получает ещё 3 письма.

Почему это плохо:

• нарушение закона (отзыв должен быть прекращён немедленно);
• негативный отзыв в геосервисах и соцсетях.

Как правильно:

• автоматизация отписки: ссылка «отписаться» в каждом письме, код «СТОП» в SMS, кнопка в приложении;
• время реакции — не более 24 часов с момента отзыва;
• проверка — случайный аудит: реально ли гость исключён из рассылок.

Ошибка 6. «Мы у себя всё храним» ≠ локализация

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

Как правильно:

• проверять реальное физическое расположение данных;
• избегать зарубежных сервисов, не имеющих локализации в РФ;
• читать договор: где написано «серверы», там должно быть «Россия».

Как проверить себя до проверки: внутренний аудит за один день

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

Блок 1. Документы и политика

• [ ] Политика обработки персональных данных опубликована на сайте и актуальна.
• [ ] Политика содержит все обязательные разделы (оператор, цели, правовые основания, сроки, условия отзыва).
• [ ] Согласие на маркетинг — отдельный документ, доступен по ссылке.
• [ ] Уведомление Роскомнадзора об обработке ПДн подано и актуально (включая сведения об обработчиках).
• [ ] Назначен ответственный за обработку ПДн (при необходимости — опубликован на сайте).

Блок 2. Точки сбора

• [ ] Все формы на сайте и в приложении проверены: нет галочек «по умолчанию».
• [ ] QR-сценарии проверены: согласие — отдельным шагом, есть разделение каналов.
• [ ] Бронирование: согласие на маркетинг — отдельно от согласия на обработку в рамках брони.
• [ ] Доставка: согласие на маркетинг — отдельно от согласия на обработку заказа.
• [ ] Wi-Fi с авторизацией: проверьте, что данные авторизации не идут в маркетинговые рассылки без отдельного согласия.

Блок 3. Хранение и логи

• [ ] Логи согласий хранятся отдельно от CRM, содержат версию политики и метаданные.
• [ ] Срок хранения логов — не меньше срока обработки.
• [ ] Есть процедура отзыва согласия, известная всем сотрудникам.
• [ ] Есть автоматизация отписки (ссылка в письме, «СТОП» в SMS, кнопка в приложении).
• [ ] Регулярная (раз в квартал) проверка: реально ли отписанные гости исключены из рассылок.

Блок 4. Подрядчики

• [ ] Реестр обработчиков ПДн — актуальный.
• [ ] С каждым обработчиком — договор поручения обработки.
• [ ] Все обработчики — российские юрлица или российские представительства.
• [ ] В договорах — пункт о хранении данных на территории РФ.
• [ ] В договорах — пункт о мерах защиты ПДн.

Блок 5. CRM и интеграции

• [ ] CRM хранит атрибуты согласия по каждому каналу.
• [ ] CRM нормализует идентификаторы и сшивает профиль.
• [ ] Между CRM и сервисами рассылок — фильтр по согласию.
• [ ] Событийная модель: заказы, брони, отзывы привязаны к профилю.
• [ ] Настроен срок хранения и обезличивание/удаление неактивных.

Что сделать на этой неделе: пошаговый план

Не нужно перестраивать всё за месяц. Возьмите следующие две недели и пройдите этот план.

Неделя 1. Юридический фундамент

1. Поднимите текущую версию политики обработки ПДн. Если её нет или она устарела — отдайте юристу на ревизию.
2. Проверьте формулировку согласия на маркетинг. Если её нет — согласуйте с юристом и подготовьте шаблон.
3. Составьте реестр обработчиков. Кто получает данные: SMS-шлюз, e-mail-сервис, агрегатор отзывов, платформа доставки, CRM. С каждым — договор поручения обработки.
4. Проверьте уведомление Роскомнадзора. Соответствует ли текущим обработчикам и целям. Если нет — подайте обновление.

Неделя 2. Продуктовый и технический слой

1. Пройдите по всем QR-сценариям. Где есть форма сбора контакта — проверьте: согласие отдельно? Каналы раздельно? Текст понятный?
2. Проверьте CRM: есть ли атрибуты согласия по каналам? Если нет — добавьте и проведите миграцию текущих данных.
3. Настройте автоматизацию отписки: ссылка в письме, «СТОП» в SMS, кнопка в приложении, e-mail для отзыва.
4. Запустите re-permission кампанию для базы, собранной без явного согласия. Это самая тяжёлая, но и самая важная часть.

Неделя 3. Процессы и команда

1. Обучите персонал: что говорить гостю, который просит отписаться. Куда передавать запрос. Сколько времени на реакцию.
2. Назначьте ответственного за соблюдение 152-ФЗ в ресторане. Не обязательно юрист — это может быть управляющий, но с понятной зоной ответственности.
3. Зафиксируйте регламент: как собираем согласия, как храним, как отзываем, как проверяем. Простой документ на 2–3 страницы.

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

В 2026 году на рынке много сервисов, которые обещают «единый профиль гостя». Но не все понимают, что этот профиль должен быть легальным. Как выбирать подрядчика?

Признаки хорошего подрядчика

• На сайте и в договоре — явная локализация данных в РФ.
• Готовы подписать договор поручения обработки ПДн по вашей форме или предложить свою, соответствующую закону.
• Демонстрируют работу с согласиями как атрибутом: раздельные согласия по каналам, лог версий политики, автоматизация отписки.
• Имеют встроенные механизмы для re-permission и работы со «старой» базой.
• Показывают, как именно данные передаются между системами. Никакой «магии»: API, вебхуки, событийная модель — открыто.

Признаки плохого подрядчика

• «Мы всё храним в облаке, не переживайте» (без уточнения, где именно).
• «Согласия не нужны, у нас всё по договору» (нет, для маркетинга нужно согласие).
• «Мы сами соберём базу, а вы потом получите доступ» (это передача третьему лицу без основания).
• Не готовы показать, как реализована отписка.
• Не могут объяснить, как реализовано разделение по каналам.

Мини-чеклист для запуска единого профиля гостя

Чтобы вы могли сразу применить материал на практике, соберём компактный чек-лист. Используйте его как финальную проверку перед запуском.

Юридическая часть

• [ ] Политика обработки ПДн актуальна и опубликована.
• [ ] Согласие на маркетинг существует как отдельный документ.
• [ ] Согласие разделено по каналам (SMS, e-mail, push).
• [ ] Уведомление Роскомнадзора актуально.
• [ ] Реестр обработчиков ПДн актуален.
• [ ] Договоры поручения обработки со всеми обработчиками.

Техническая часть

• [ ] CRM поддерживает атрибуты согласия по каналам.
• [ ] Идентификаторы нормализованы (телефон в едином формате).
• [ ] Точки сбора (QR, формы, бронь, доставка) проверены.
• [ ] Согласие — отдельный шаг, не «в нагрузку».
• [ ] Логи согласий хранятся отдельно, с версией политики и метаданными.
• [ ] Автоматизация отписки работает по всем каналам.
• [ ] Срок хранения и обезличивание/удаление настроены.

Продуктовая часть

• [ ] Гость понимает, за что отдаёт данные.
• [ ] Ценность за контакт очевидна и быстрая.
• [ ] Отказ от маркетинга не мешает базовому сервису.
• [ ] Каналы коммуникации согласованы с предпочтениями гостя.
• [ ] Re-permission кампания для старой базы запланирована.

Команда и процессы

• [ ] Ответственный за обработку ПДн назначен.
• [ ] Персонал обучен сценарию отписки.
• [ ] Регламент обработки согласий задокументирован.
• [ ] Внутренний аудит проводится минимум раз в квартал.

Частые вопросы от ресторанов

Нужно ли получать согласие, если гость сам оставил отзыв на карте?

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

Можно ли использовать телефон из брони для рассылки?

Нет. Согласие на обработку в рамках брони (исполнение договора) не равно согласию на маркетинг. Для рассылки нужно отдельное согласие.

Что делать с e-mail, который гость оставил в комментарии к заказу?

Не использовать для маркетинга, пока нет явного согласия. Запустить re-permission кампанию: «Подтвердите, что хотите получать наши новости».

Можно ли использовать WhatsApp для рассылок?

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

Как часто проверять актуальность согласий?

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

Что делать с базой, которая собрана «до всех этих законов»?

Не использовать для маркетинга. Запустить re-permission. Если процент подтвердивших ниже 30% — признать базу неактивной, не платить за рассылку по ней, хранить в обезличенном виде.

Что в итоге

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

Если вы строите эту связку осознанно:

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

Именно в этом и состоит смысл «единого профиля гостя» в 2026 году: не максимум данных, а максимум доверия при минимуме риска.

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

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