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

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

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

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

Зачем ресторану офлайн-карта гостя и чем она отличается от «базы в Excel»

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

Что даёт офлайн-карта и чего не даёт «список телефонов»

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

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

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

Где ресторан обычно спотыкается

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

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

Юридический фундамент: что считается персональными данными в ресторане

Прежде чем обсуждать QR-сценарий, CRM и согласия, нужно честно зафиксировать, с какими данными ресторан работает. Это влияет и на форму согласий, и на архитектуру хранения.

Какие данные ресторан собирает на самом деле

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

К этому нужно относиться спокойно. Это не повод не работать с данными. Это повод делать это корректно: с понятной целью, минимально необходимым набором, согласием субъекта и грамотным хранением.

Какие законы и подзаконные акты действуют

Базовый закон — № 152-ФЗ «О персональных данных». Для ресторана важны несколько принципов: обработка только по конкретной, заранее определённой цели; согласие на обработку — однозначное и информированное; минимизация — нельзя собирать лишнее; хранение — не дольше, чем требует цель. Отдельное направление — маркетинговые коммуникации: рекламные рассылки и звонки требуют отдельного согласия, причём отдельного от согласия на обработку данных в рамках программы лояльности.

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

Штрафы: реальные суммы и реальные риски

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

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

Как спроектировать QR-сценарий так, чтобы он работал и не нарушал закон

QR-код — это не волшебная кнопка. Это интерфейс между офлайном и онлайном, и от того, как он спроектирован, зависит и конверсия, и юридическая корректность.

Принципы корректного QR-сценария

Хороший QR-сценарий строится по четырём принципам. Первый — минимально необходимые поля. Гость не должен заполнять анкету на 12 пунктов ради бонуса. В идеале — телефон или email и короткое согласие, всё остальное собирается позже, по мере взаимодействия. Второй — прозрачная выгода. Гость видит, что именно он получит за контакт: бонус на первый заказ, бесплатный напиток, участие в розыгрыше, приоритетная бронь. Третий — управляемость согласия. Гость сам выбирает, на что подписывается: на бонусную программу, на новости, на персональные предложения. Четвёртый — техническая корректность: ссылка ведёт на защищённое соединение, формы работают, согласия сохраняются с датой и временем.

Структура страницы, на которую ведёт QR

Страница должна быть короткой и последовательной. Логика обычно такая: приветствие, выгода, поле для контакта, чекбоксы согласий, кнопка подтверждения, экран благодарности с бонусом или предложением. Каждый экран — отдельный шаг, чтобы снизить отток. На каждом шаге — короткое объяснение, что происходит с данными.

Разделение согласий

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

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

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

Какой QR куда ставить

QR-коды отличаются по сценарию. На столе уместен один QR — на бонусную карту и обратную связь. На чеке — другой: на оценку визита и подписку на программу. На выносе — на программу лояльности и доставку. На папке-меню — на обратную связь и бронирование. У каждого QR — своя страница, своя цель и, соответственно, свой набор согласий. Не нужно собирать всё со всех точек одной анкетой — это и с точки зрения UX плохо, и с точки зрения юридической логики некорректно.

CRM как центр офлайн-карты: где её границы

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

Какая CRM нужна ресторану в 2026 году

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

В ресторанном сегменте популярны интеграции с iiko и R-keeper, потому что именно эти системы генерируют событийный поток. Подробный разбор конкретных решений — за рамками этой статьи, но при выборе важно смотреть не на маркетинг, а на то, как конкретная CRM хранит согласия и работает с правами субъекта.

Какие данные хранить в CRM, а какие — рядом

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

Связка CRM с другими системами

Офлайн-карта гостя не живёт в одной системе. Она — результат работы связки: POS (заказы, оплаты, чеки), платформа лояльности (бонусы, уровни, акции), система бронирования (визиты по брони), сервис рассылок (коммуникации), форма обратной связи (оценки, отзывы). CRM становится «клеем», который собирает события и даёт целостную картину. Без такой связки ресторан получает «лоскутную автоматизацию», в которой каждый сервис знает о госте только своё.

Пример связки для сети кофеен: гость сканирует QR на столе, попадает на страницу бонусной программы, даёт согласие на обработку и согласие на маркетинг, попадает в платформу лояльности и в CRM. На кассе официант видит в POS идентификатор гостя, привязывает заказ. После визита CRM получает событие, сегментирует гостя, через сервис рассылок отправляет персональное предложение с возможностью отписки. Если гость просит удалить данные — CRM и платформа лояльности удаляют идентификатор по цепочке.

Программа лояльности и согласия: где проходит граница

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

Лояльность без маркетинга — это нормально

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

Что должно быть в правилах программы лояльности

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

Сегментация: что можно делать без дополнительного согласия

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

Сбор данных офлайн: где ресторан теряет согласия

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

Типичные ошибки на кассе и в зале

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

Что делать сотрудникам и что писать в регламентах

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

Где должны быть формы согласия

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

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

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

Шаг 1. Единый идентификатор гостя

Все системы — POS, CRM, платформа лояльности, сервис рассылок — должны оперировать одним идентификатором гостя. Это может быть клиентский номер, хэш от контакта или иной токен. Главное — чтобы при заказе на кассе и при отправке рассылки речь шла об одном и том же человеке.

Шаг 2. Источник согласия

Каждое согласие должно фиксироваться с указанием источника: откуда оно пришло (QR на столе, форма бронирования, касса), когда, на какую версию документа. Это позволяет при проверке предъявить доказательную базу и при запросе гостя корректно отозвать согласие по всем системам.

Шаг 3. Передача событий, а не «слияние баз»

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

Шаг 4. Управление правами субъекта

Гость имеет право знать, какие данные о нём хранятся, требовать их уточнения и удаления. Технически это означает наличие процедуры: внутренний запрос, поиск по идентификатору во всех системах, формирование ответа, удаление или анонимизация. Это не разовая задача, это процесс, который должен работать постоянно.

Что должно быть в политике обработки персональных данных ресторана

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

Минимальный набор разделов

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

Что часто упускают

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

Актуализация

Политика не пишется один раз. Она должна обновляться при изменении процессов, при появлении новых систем, при изменении целей обработки. В 2026 году рестораны, у которых политика лежит «как была написана в 2019 году», находятся в зоне повышенного риска.

Практический чек-лист запуска офлайн-карты

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

Этап 1. Цели и границы

Прежде чем выбирать CRM и рисовать страницу для QR, нужно определить цели. Зачем вам офлайн-карта? Ради повторных визитов? Ради сегментации? Ради отзывов? Ради среднего чека? От целей зависит и набор данных, и набор согласий. Если целей нет — офлайн-карта превращается в «склад контактов» без смысла.

Также нужно определить границы. Какие данные вы принципиально не собираете? Какие каналы коммуникации не используете? Какие категории гостей вы исключаете (например, несовершеннолетних, если у вас бар).

Этап 2. Карта данных

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

Этап 3. Дизайн QR-сценариев

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

Этап 4. Интеграции

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

Этап 5. Регламенты для персонала

Напишите короткие инструкции: что говорить гостю, как действовать при отказе, как фиксировать согласия, куда обращаться при вопросах. Обучите персонал. Проведите внутреннюю проверку.

Этап 6. Публичные документы

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

Этап 7. Запуск и мониторинг

Запускайте сценарий поэтапно: сначала на одной точке, потом в пилотной сети, потом масштабируйте. На каждом этапе отслеживайте конверсию, отказы, отписки, ошибки. Корректируйте сценарий на основе реальных данных.

Этап 8. Управление правами субъекта

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

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

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

«Мы же просто чек отправили»

Отправка электронного чека на email или SMS — это обработка персональных данных. Она требует правового основания. Если гость дал согласие на получение чека — пожалуйста. Если вы отправляете чек на контакт, полученный «по умолчанию» или из открытых источников, — это нарушение. В 2026 году регулятор относится к этому серьёзно.

«Мы в ресторане, а не в банке»

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

«Мы спросили устно, этого достаточно»

Для большинства целей обработки устного согласия недостаточно. Нужна письменная форма или электронная фиксация с указанием даты, субъекта, цели, документа. Без этого согласия нет.

«Мы просто используем контакт для программы лояльности»

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

«Мы передали данные подрядчику, он виноват»

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

«Мы получили согласие один раз и забыли»

Согласия имеют срок действия, зависящий от цели обработки. Отозванное согласие нужно прекратить использовать немедленно. Игнорирование отписок и запросов на удаление — самостоятельное нарушение.

Как минимизировать данные и снизить риски

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

Не собирать лишнего

Если для участия в программе лояльности достаточно номера телефона, не нужно собирать email. Если для брони достаточно имени, не нужно собирать дату рождения. Любое дополнительное поле — это дополнительная ответственность и дополнительная точка риска.

Не хранить лишнего

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

Анонимизация и псевдонимизация

Для аналитики можно использовать псевдонимизированные данные: вместо «Иванов Иван, телефон +7...» — «гость id 2841, сегмент А». Это снижает риски и упрощает работу с большими объёмами данных.

Регулярные аудиты

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

Что делать, если проверка всё-таки пришла

Это не теоретический вопрос. Проверки приходят, и ресторан должен быть готов.

Первые шаги

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

Что показывать регулятору

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

Превентивные меры

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

Как измерять эффект офлайн-карты гостя

Офлайн-карта — это инвестиция, и владелец хочет видеть результат. Метрики делятся на операционные и маркетинговые.

Операционные метрики

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

Маркетинговые метрики

• повторные визиты участников программы vs. не участников;
• средний чек участников программы;
• отклик на персональные коммуникации;
• стоимость привлечения и удержания.

Как читать метрики

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

Отдельные сценарии: кофейня, фаст-кэжуал, семейный ресторан

Разные форматы требуют разных акцентов. Ниже — три коротких сценария, которые показывают, как принципы выше применяются на практике.

Кофейня

Гость приходит часто, средний чек небольшой, важна скорость обслуживания. Офлайн-карта — это идентификация по QR, бонус за каждый визит, короткая коммуникация по push или email с возможностью отписки. Согласия — на программу и на новости, разделённые. Минимум данных: телефон, имя (необязательно), история заказов.

Фаст-кэжуал

Гость приходит регулярно, но не ежедневно. Офлайн-карта — это бонусы, комбо-предложения, обратная связь. QR — на упаковке и на чеке. Согласия — на программу и на маркетинг (отдельно). Дополнительно — возможность получить персональное предложение в «тихие» часы.

Семейный ресторан

Гость приходит реже, средний чек выше, важен опыт. Офлайн-карта — это бронь, история визитов, предпочтения, аллергены (с отдельным согласием), поздравления с праздниками. QR — на папке-меню и на чеке. Согласия — на программу, на бронирование, на маркетинг, на обработку данных о здоровье (если собираете аллергены). Коммуникации — мягкие, с уважением к приватности.

Типовые вопросы владельцев и практические ответы

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

Только если в форме бронирования было получено отдельное согласие на маркетинговые коммуникации. Само по себе согласие на бронирование не покрывает рассылку.

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

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

Можно ли хранить данные гостей, которые перестали приходить?

Да, если есть основание и соблюдается срок хранения. Если гость отозвал согласие — данные нужно удалить или обезличить.

Как правильно оформить «спасибо за визит» через QR?

QR ведёт на страницу, где гость по желанию оставляет контакт для участия в программе, соглашается на обработку и на коммуникации (отдельно), получает бонус. Без обязательного ввода контакта, но с понятной выгодой.

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

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

Что делать прямо сейчас: первые шаги

Этот блок — для тех, кто хочет начать в ближайшие недели, а не «когда-нибудь».

Неделя 1. Аудит

Провести инвентаризацию: какие данные собираются, где хранятся, на каком основании, как используются. Составить список «что мы делаем» и сравнить с тем, «что написано в политике».

Неделя 2. Дизайн согласий

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

Неделя 3. Дизайн QR-сценариев

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

Неделя 4. Интеграции

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

Неделя 5. Регламенты

Написать короткие инструкции для персонала, провести обучение, провести внутреннюю проверку.

Неделя 6. Запуск пилота

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

Неделя 7. Документы

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

Неделя 8. Масштабирование

Распространить сценарий на остальные точки, поддерживая единые правила.

Как выбрать подрядчика и платформу

Выбор подрядчика — это не только вопрос цены и функций, но и вопрос ответственности.

Критерии выбора CRM

• поддержка событийной модели и интеграций с POS;
• фиксация согласий с датой и источником;
• управление правами субъекта (доступ, удаление, отзыв);
• локализация данных в РФ, если это требуется;
• история работы с ресторанным сегментом.

Критерии выбора платформы лояльности

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

Критерии выбора сервиса рассылок

• возможность добавить ссылку отписки в каждое сообщение;
• сегментация по событиям, а не только по базе;
• соответствие требованиям закона о рекламе;
• поддержка каналов, которые использует ресторан (email, SMS, push).

Юридическая проверка

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

Что делать с уже существующей «серой» базой

У многих ресторанов есть база, собранная без корректных согласий. Это реальность, и её нужно решать.

Оценка рисков

Определите, какие контакты были собраны без надлежащего согласия, какие использовались для маркетинга, какие хранятся дольше нужного срока. Это поможет приоритизировать действия.

«Легализация»

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

«Очистка»

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

Превентивные меры

Чтобы не повторять ошибку — внедрить процессы, описанные выше. Это инвестиция, которая окупается за счёт снижения рисков и повышения эффективности маркетинга.

Итог: офлайн-карта гостя как система, а не проект

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

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

Где искать решения для связки QR, CRM и согласий

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

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

Для ресторанов, которые опираются на конкретную экосистему автоматизации, разумно посмотреть на сервисы лояльности и CRM в связке с POS — так проще оценить совместимость с уже работающими системами.

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

Краткий план на следующие 30 дней

Чтобы не утонуть в деталях — план на месяц.

1. Провести аудит текущих данных и согласий.
2. Подготовить раздельные согласия и обновить политику.
3. Спроектировать QR-сценарии для ключевых точек контакта.
4. Согласовать архитектуру интеграций с подрядчиками.
5. Запустить пилот на одной точке.
6. Обучить персонал и собрать обратную связь.
7. Скорректировать сценарий и масштабировать.

Этого достаточно, чтобы за месяц перейти от «как-то работаем» к «работаем корректно». Остальное — итерации, метрики, оптимизация.