Сценарные уведомления в WhatsApp и Telegram: как возвращать гостя, не превращаясь в спам

Сценарные уведомления в WhatsApp и Telegram: как возвращать гостя, не превращаясь в спам

Рынок доставки и ресторанного маркетинга в России в 2026 году окончательно разделился на две неравные части: тех, кто выжимает из базы гостей максимум через массовые рассылки, и тех, кто строит коммуникацию точечно — по событиям, состояниям и микросценариям. Первые всё чаще получают жалобы в ФАС, попадают под маркировку рекламы и теряют канал: номер телефона уходит в бан WhatsApp Business API, аккаунт Telegram рискует получить ограничения. Вторые делают меньше отправок, но каждое сообщение попадает в нужный момент — и гость возвращается не потому, что ему «напомнили», а потому что ресторан встроился в его сценарий жизни.

Эта статья — про вторую историю. Про то, как сценарные уведомления в WhatsApp и Telegram работают как триггерная автоматизация, а не как очередной email-канал в телефоне. Мы разберём, где заканчивается «информация о брони, заказе и программе лояльности» и начинается реклама по смыслу закона, какие технические сценарии реально работают в ресторане, и как собрать цепочку так, чтобы гость воспринимал сообщения как сервис, а не как навязчивое приглашение.

Зачем ресторану вообще WhatsApp и Telegram в 2026 году

Если пять лет назад главным каналом обратной связи был звонок на ресепшен, а главным маркетинговым — email и SMS, то сегодня посетитель чаще открывает мессенджер, чем почту. По данным отраслевых обзоров рынка HoReCa в России, доля гостей, которые предпочитают получать уведомления от ресторана именно в мессенджере, стабильно растёт: WhatsApp занимает лидирующую позицию в большинстве регионов, Telegram сильнее в Москве, Петербурге, Казани и городах-миллионниках, где у аудитории сформирована привычка к боту. При этом доля SMS-рассылок, которые когда-то были основой ресторанного маркетинга, устойчиво снижается: сообщения часто не читают, открываемость падает, доставка дорожает.

Для ресторана это означает несколько практических вещей:

• Гость уже живёт в мессенджере. Не надо его никуда «переводить» — достаточно попросить номер один раз при бронировании или оплате и дальше общаться там, где он и так находится.
• Мессенджер — единственный канал с двусторонней связью без задержек. Email асинхронен, SMS почти никогда не предполагает ответа, звонок — это всегда отвлечение внимания. В WhatsApp и Telegram гость может ответить в своём темпе: уточнить адрес, попросить чек, перенести бронь.
• Стоимость контакта в мессенджере ощутимо ниже, чем в других цифровых каналах. Технически сообщение через WhatsApp Business API стоит дороже, чем email, но конверсия в целевое действие (визит, повторный заказ, отзыв) — в разы выше, поэтому совокупная стоимость возврата гостя оказывается выгоднее.
• Мессенджер позволяет собирать событийную историю. Бот или CRM фиксирует, на какое сообщение гость отреагировал, когда был последний заказ, как менялся средний чек. Это превращает канал из «рассылки» в источник данных для сценариев.

Но у мессенджера есть и ограничения, которые нужно учитывать заранее:

• Жёсткая модерация WhatsApp. Каждое массовое сообщение, отправленное через неофициальные клиенты, рискует блокировкой номера. WhatsApp различает сервисные шаблоны (utility, authentication) и маркетинговые (marketing) — и применяет к ним разные правила, тарифы и лимиты.
• Закон о рекламе в РФ. Сообщение с предложением товара или услуги, отправленное через мессенджер, может быть признано рекламой. А значит — требовать маркировки, учёта и токена. Если ресторан этого не делает, рискует получить штраф и предписание ФАС.
• Согласие на коммуникацию. Без явного согласия гостя отправлять ему маркетинговые сообщения нельзя, а сервисные — можно, но в строго ограниченных сценариях.

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

Что такое «сценарные уведомления» и чем они отличаются от рассылки

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

Разница между сценарным уведомлением и рассылкой — не в количестве сообщений, а в логике:

Сценарное уведомление — это сервис. Рассылка — это маркетинг. Ресторан, который строит канал вокруг сценариев, делает три принципиальные вещи:

1. Экономит внимание гостя. Сообщение приходит, когда гость ждёт информацию или она ему полезна.
2. Снимает юридические риски. Чем больше канал построен вокруг сервисных сценариев, тем меньше шансов, что ФАС признает сообщение рекламой.
3. Увеличивает LTV без роста бюджета. Гость возвращается не из-за скидки, а из-за удобства.

Какие сценарии считаются сервисными, а какие — рекламными

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

К сервисным (информационным) сценариям относятся:

• Подтверждение бронирования и напоминание о брони.
• Изменение статуса заказа (принят, готовится, доставляется, доставлен).
• Чек и фискальный документ по запросу.
• Уведомления по программе лояльности (начисление, списание, изменение уровня).
• Реакция на обращение гостя: «спасибо за отзыв», «мы передали ваш вопрос шефу».
• Сообщения о сбоях в работе заведения: «у нас сегодня не работает кондиционер», «доставка задерживается на 30 минут».
• Подтверждение подписки, смена настроек.

К рекламным (маркетинговым) сценариям относятся:

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

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

Где заканчивается «информация» и начинается «реклама»

На практике граница смещается в зависимости от формулировок. Несколько примеров:

• «Ваш заказ №1234 доставлен. Спасибо, что выбрали нас» — сервис.
• «Ваш заказ №1234 доставлен. Закажите повторно со скидкой 15%» — реклама.
• «Ваш столик на 19:30 ждёт вас» — сервис.
• «Ваш столик на 19:30 ждёт вас. При заказе от 3000 ₽ — комплимент от шефа» — реклама.
• «Вам начислено 120 бонусов» — сервис.
• «У вас 120 бонусов, которые сгорят через 7 дней — используйте на новый десерт» — реклама.

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

Юридическая рамка: что нужно знать ресторану в 2026 году

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

Закон о рекламе (38-ФЗ) и поправки 2024–2026

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

• Любое рекламное сообщение должно быть промаркировано и учтено в ОРД.
• На сообщении должна быть пометка «реклама» и информация о рекламодателе.
• Креативы и отчёты хранятся и передаются в ЕРИР.
• За нарушения — штрафы для юридических лиц от 30 000 до 500 000 ₽ в зависимости от характера нарушения.

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

Закон о персональных данных (152-ФЗ) и согласие на коммуникацию

Чтобы отправлять сообщения гостю, ресторан должен иметь одно из оснований:

• Договорные отношения. Гость сделал заказ, забронировал столик, оплатил — это договор. В рамках исполнения договора ресторан вправе отправлять сервисные сообщения. Это не требует отдельного согласия, но требует прозрачности: гость должен знать, что сообщения будут приходить.
• Согласие на маркетинговые коммуникации. Если ресторан хочет отправлять рекламу, нужно отдельное согласие, оформленное в соответствии с требованиями 152-ФЗ: в свободной форме, с указанием канала, цели, способа отзыва.

На практике рестораны делают так:

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

Согласие на WhatsApp и Telegram отдельно

WhatsApp Business API требует, чтобы у компании был согласованный opt-in: гость должен явно подтвердить, что хочет получать сообщения. Это может быть:

• Галочка при оформлении заказа.
• Сообщение, отправленное гостем первым («Хочу получать уведомления о заказе»).
• Подтверждение по SMS-коду, отправленному на тот же номер.

Telegram менее формализован: бот может начать диалог, если гость сам его запустил. Но с точки зрения закона РФ это не отменяет требования получать согласие на маркетинговые сообщения.

Что считается нарушением и какие штрафы

За 2024–2026 годы ФАС и Роскомнадзор провели несколько показательных проверок именно в сегменте HoReCa и доставки еды. Типичные нарушения:

• Рассылка без согласия. Штраф по 152-ФЗ — до 100 000 ₽ за повторное нарушение.
• Отсутствие маркировки рекламы. Штраф по 38-ФЗ — до 500 000 ₽.
• Использование WhatsApp через «серые» шлюзы. Блокировка номера без возможности восстановления.
• Рассылка сообщений с рекламной составляющей без токена ОРД. Штраф + требование удалить публикацию.

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

Архитектура сценарных уведомлений: из чего состоит система

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

Слой 1. Источники событий

Чтобы сценарий сработал, нужно, чтобы в системе появилось событие. Источниками могут быть:

• POS-система или система автоматизации ресторана (например, iiko, R-Keeper, Poster, Jowi). Здесь возникают события: заказ создан, оплачен, доставлен, отменён; гость сделал заказ на определённую сумму; гость впервые за 60 дней.
• CRM или CDP (Customer Data Platform). Здесь агрегируется профиль гостя: имя, история заказов, сегменты, предпочтения, канал коммуникации.
• Система бронирования. События — бронь создана, изменена, отменена, гость не пришёл.
• Сайт или мобильное приложение ресторана. События — регистрация, добавление в корзину, оформление заказа.
• Программа лояльности. События — регистрация в программе, достижение уровня, начисление и списание бонусов.
• Платёжный шлюз. События — оплата прошла, возврат, ошибка.
• Внешние источники. Например, сервис отзывов — гость оставил отзыв, и в CRM появляется триггер.

Ключевая задача ресторана — собрать события в одном месте. Если события «разбросаны» по POS, CRM и Google-таблице, сценарии строить невозможно: они не будут срабатывать вовремя.

Слой 2. Сегментация и условия

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

• Фильтры по атрибутам гостя. Например, событие «заказ создан» произошло, но сообщение получат только гости из сегмента «постоянные» или «с высоким средним чеком».
• Условия на время и контекст. Например, «не отправлять сообщения в ночное время», «отправлять только если гость не заказывал последние 14 дней».
• Анти-спам правила. «Не больше одного сообщения в 7 дней», «не отправлять два триггера в один канал подряд».
• Приоритеты сценариев. Если несколько сценариев сработали одновременно, выбирается наиболее релевантный, остальные подавляются.

В малых ресторанах эта логика может быть реализована в CRM или даже в настройках WhatsApp Business. В сетях и крупных проектах — это отдельный слой customer engagement platform (CEP) или marketing automation.

Слой 3. Канал доставки

Сами каналы — WhatsApp Business API, Telegram-бот, реже — RCS, реже — комбинация с email. У каждого канала свои технические ограничения:

• WhatsApp Business API требует подтверждённого бизнес-аккаунта, верификации Facebook (Meta), использования только одобренных шаблонов для инициирующих сообщений. Стоимость — за шаблонные и сессионные сообщения, тариф зависит от страны и типа шаблона.
• Telegram Bot API проще в запуске, но требует более аккуратной работы с согласием: бот не может писать гостю первым, если гость сам не начал диалог. Поэтому основная модель — гость запускает бота через ссылку, после чего бот может отправлять сообщения в рамках согласованной логики.

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

Слой 4. Шаблоны и тексты

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

Тексты в сценарных уведомлениях должны быть:

• Короткими. 2–4 строки. Гость не читает «простыни» в мессенджере.
• Конкретными. Что произошло, что нужно сделать.
• Человечными. Без корпоративного «уважаемый клиент», без канцелярита.
• С явным CTA или без него. Если сообщение сервисное и не требует действия — CTA не нужен. Если требует — кнопка или короткая ссылка.

Слой 5. Аналитика и обратная связь

Последний слой — это аналитика. Без неё сценарии работают «вслепую»:

• Открываемость и кликабельность. Сколько гостей прочитали, сколько нажали.
• Реакция. Сколько ответили, сколько отписались, сколько пожаловались.
• Влияние на бизнес-метрики. Сколько из получивших сценарий вернулись в течение 7/14/30 дней, как изменился средний чек.
• Жалобы и блокировки. Каждое сообщение, на которое пожаловались, — это сигнал о том, что сценарий надо пересматривать.

Практические сценарии: что реально работает в ресторане

Ниже — набор сценариев, которые проверены на практике и работают без риска превращения в спам. Они сгруппированы по жизненному циклу гостя.

Сценарии до визита

Гость ещё не пришёл, но ресторан уже с ним взаимодействует. Здесь важно: сервисные сообщения должны помогать гостю, а не подталкивать его к покупке.

Подтверждение бронирования. Гость оставил заявку на бронь — система отправляет сообщение: «Бронирование подтверждено. Столик №3, 19:30, на имя Алексей. Если нужно перенести — ответьте на это сообщение». Это сервисное сообщение, потому что помогает гостю завершить начатое (подтверждает договорённость).

Напоминание о брони за 2–4 часа. Гость забывает про бронь — ресторан снижает no-show. Сообщение: «Через 2 часа ждём вас на ужин. Столик №3 на 19:30, по адресу ул. Лесная, 14. Если планы изменились — дайте знать, мы отменим или перенесём». Чистый сервис.

Предзаказ по меню. Если ресторан предлагает заранее выбрать блюда — гость получает ссылку на меню и возможность сделать предзаказ. Сервис, потому что помогает гостю спланировать визит.

Предоплата или депозит. Гость вносит депозит для брони — получает подтверждение и чек. Сервис.

Сценарии во время визита

Гость в ресторане или только что сделал заказ. Здесь мессенджер становится инструментом сопровождения.

Подтверждение заказа. Гость сделал заказ на сайте или в приложении — сообщение с номером заказа, составом, временем приготовления. Сервис.

Изменение статуса заказа. Готовится, готов, ожидает курьера, в пути, доставлен. Каждое изменение — отдельное сообщение. Сервис.

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

Запрос отзыва о доставке. Через 30–60 минут после доставки: «Доставка прошла хорошо? Если что-то не так — напишите, мы решим». Пограничный сценарий: по форме это сервис, по сути — инструмент работы с обратной связью. Главное — не превращать его в приглашение к следующему заказу со скидкой.

Сценарии после визита

Гость ушёл. Здесь ресторан чаще всего скатывается в рассылки. Но можно строить сценарии иначе.

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

Запрос оценки. Через 24–48 часов: «Оцените визит, пожалуйста. Это занимает 30 секунд и помогает нам становиться лучше». Ссылка на короткую форму или кнопка «оценить» в Telegram. Сервис — это инструмент улучшения качества.

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

Начисление бонусов по программе лояльности. Гость получил бонусы за визит — сообщение: «За визит вчера вам начислено 250 бонусов. Баланс — 1 240. Использовать можно при следующем заказе». Пограничный сценарий. Само по себе начисление — сервис (отражение состояния программы лояльности). Но формулировка «использовать можно» в сочетании с предложением спецпредложения превращает сообщение в рекламу. Чтобы остаться в сервисной зоне, текст должен сообщать о факте, а не продавать.

Предупреждение о сгорании бонусов. «Через 14 дней у вас сгорят 200 бонусов. Если хотите использовать — дайте знать». Это уже на грани. По форме — информация, по сути — стимуляция транзакции. Если ресторан хочет остаться в безопасной зоне, лучше сообщать о сгорании без CTA на немедленное использование.

Сценарии возврата: когда гость давно не приходил

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

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

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

Возврат через событие. У гостя скоро день рождения. Ресторан знает дату (из анкеты при регистрации) и отправляет: «Скоро у вас день рождения. Если планируете отметить — мы можем помочь с отдельным залом и меню». Это реклама, потому что продвигает услугу банкета. Подлежит маркировке и согласию.

Сценарии в критических ситуациях

Гость должен получить сообщение, даже если ресторан не продаёт ничего.

Сбой в работе. «Здравствуйте! Сегодня у нас не работает кондиционер. Если вам важно — мы предложим перенести бронь или пересадим в другой зал. Извините за неудобства». Сервис.

Задержка заказа. «Ваш заказ задерживается на 20 минут — шеф готовит десерт в подарок. Спасибо за ожидание». Сервис, плюс компенсация.

Отзыв с низкой оценкой. «Спасибо за отзыв. Нам важно разобраться — свяжемся с вами в ближайший час». Сервис.

Возврат платежа. «Возврат по заказу №1234 прошёл, деньги поступят в течение 3 рабочих дней». Сервис.

Эти сценарии формируют репутацию ресторана сильнее, чем любая акция. Гость запоминает, как с ним обошлись в проблемной ситуации, и именно это влияет на возврат.

Как собрать сценарную цепочку на практике: пошаговый подход

Ниже — пошаговый алгоритм, который ресторан может использовать как чек-лист при внедрении.

Шаг 1. Опишите жизненный цикл гостя

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

1. Первый контакт (зашёл на сайт, увидел рекламу, нашёл на карте).
2. Первое бронирование или первый заказ.
3. Получение сервисных уведомлений.
4. Визит.
5. Оценка и обратная связь.
6. Повторный визит или заказ.
7. Превращение в постоянного гостя (программа лояльности, подписка на обновления).

На каждом этапе — свои задачи и свои сценарии. Опишите их в таблице: этап → задача → сообщение → канал → триггер.

Шаг 2. Определите ключевые события

Не все события одинаково полезны. Выделите те, которые точно стоит отслеживать:

• Бронь создана / изменена / отменена / гость не пришёл.
• Заказ создан / оплачен / доставлен / отменён.
• Гость зарегистрировался в программе лояльности.
• Гость получил новый уровень.
• Гость оставил отзыв.
• Гость не заказывал N дней.
• Гость в зоне риска (снижение частоты визитов).
• Гость на конкретном этапе дня рождения.

Шаг 3. Разделите сценарии на сервисные и рекламные

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

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

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

Шаг 4. Пропишите анти-спам правила

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

• Не больше 1 сервисного сообщения в сутки (исключение — статусные уведомления по заказу).
• Не больше 1 рекламного сообщения в неделю.
• Тихие часы — не отправлять с 22:00 до 09:00 по местному времени гостя.
• Возможность отписаться в один клик.
• Учёт предпочтений: если гость отписался от новостей — не отправлять новости даже в рамках «комбо».

Шаг 5. Соберите тексты

По каждому сценарию пропишите 1–3 варианта текста. Лучше — один основной и один резервный. Главные принципы:

• Без корпоративного языка.
• Имя гостя, если есть.
• Чёткое указание на действие или его отсутствие.
• Никаких эмодзи-стен.
• Никаких CAPS LOCK.

Пример плохого текста: «УВАЖАЕМЫЙ ГОСТЬ! 🎉🎉🎉 ТОЛЬКО СЕГОДНЯ СКИДКА 50% НА ВСЁ МЕНЮ!!! 🔥🔥🔥».

Пример хорошего текста: «Алексей, через час ваш столик будет ждать вас. Адрес: ул. Лесная, 14».

Шаг 6. Подключите каналы

Если ресторан использует iiko, R-Keeper или другую POS-систему — настройте интеграцию с WhatsApp Business API и/или Telegram-ботом. Если используется внешний сервис автоматизации (например, Mindbox, Sendsay, Altkraft, Unisender, собственная CDP) — настройте webhook и передачу событий.

На этом шаге важно протестировать: отправить тестовые сообщения, проверить шаблоны WhatsApp на модерации, убедиться, что Telegram-бот корректно подтверждает согласие.

Шаг 7. Запустите пилот

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

Шаг 8. Расширяйте постепенно

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

Что делать с WhatsApp Business API: технические нюансы

WhatsApp — закрытая экосистема с жёсткими правилами. Ресторану нужно понимать несколько ключевых моментов.

Типы сообщений и тарифы

Meta делит сообщения на:

• Сервисные (utility) — подтверждение транзакции, обновление заказа, уведомления о брони. Низкий тариф.
• Аутентификационные (authentication) — OTP-коды, подтверждения входа. Обычно бесплатно для отправителя.
• Маркетинговые (marketing) — продвижение, акции, предложения, ретаргетинг. Самый высокий тариф.

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

Сессионные окна

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

Верификация бизнеса

Для работы с WhatsApp Business API нужно:

• Зарегистрировать бизнес в Meta Business Manager.
• Пройти верификацию компании (для отправки маркетинговых сообщений — обязательно).
• Согласовать отправителя (номер телефона) — он закрепляется за бизнесом.
• Использовать одобренного провайдера (BSP), который обеспечивает API и инфраструктуру.

Анти-бан логика

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

• Отправлять только тем, кто дал явное согласие.
• Использовать только одобренные шаблоны.
• Не превышать разумную частоту сообщений.
• Мониторить метрики качества (quality rating) в Meta Business Manager.
• Реагировать на жалобы: если гость жмёт «спам» или блокирует — убирать его из базы немедленно.

Telegram как канал: в чём отличие от WhatsApp

Telegram менее формализован, но имеет свои особенности.

Бот vs. канал

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

Бот может:

• Отправлять сообщения гостю в рамках диалога.
• Принимать команды и обрабатывать их.
• Показывать меню, кнопки, формы.
• Вести гостя по сценарию.

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

Ограничения и риски

Telegram не имеет такой жёсткой модерации, как WhatsApp. Это и плюс, и минус:

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

По закону РФ использование Telegram-бота для маркетинговых рассылок подчиняется тем же правилам: нужен opt-in, нужна маркировка рекламы, нужна возможность отписки.

Когда выбрать Telegram

• Если аудитория ресторана — Telegram-активные пользователи: молодёжь, IT, диджитал-профессии.
• Если важно дать гостю «интерактив»: заказ через бот, выбор времени, оплата.
• Если нужны сложные сценарии с ветвлениями, кнопками, формами.
• Если ресторан уже ведёт активный Telegram-канал и есть аудитория.

Когда выбрать WhatsApp

• Если аудитория широкая, в том числе возрастная.
• Если важна доверительность: WhatsApp исторически воспринимается как «личный» канал.
• Если нужна интеграция с существующей POS и CRM: большинство решений в HoReCa «заточены» именно под WhatsApp.
• Если ресторан работает с доставкой и важно подтверждение по статусу заказа.

Комбинация каналов

Лучшие результаты даёт комбинация: WhatsApp — для сервисных уведомлений (статус заказа, бронь), Telegram — для интерактива (заказ, оплата, программа лояльности). Но такая схема требует более сложной архитектуры и более аккуратной работы с согласием.

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

Типичные ошибки ресторанов при работе с мессенджерами

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

Ошибка 1. Слишком частые сообщения

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

Как избежать: жёсткое ограничение частоты, приоритизация сценариев, анти-спам правила.

Ошибка 2. Сообщения без персонализации

«Уважаемый клиент! Только сегодня скидка 20% на всё меню!» — одинаково для всех. Гость понимает, что это массовая рассылка, и реагирует соответственно.

Как избежать: использовать имя, историю заказов, контекст визита.

Ошибка 3. Игнорирование тихих часов

Сообщение в 23:00 или в 7:00 утра — верный способ попасть в «спам» в восприятии гостя.

Как избежать: настройка «окна отправки» в соответствии с часовым поясом гостя.

Ошибка 4. Отсутствие возможности отписки

В каждом рекламном сообщении должна быть ссылка или команда для отписки. Если её нет — гость чувствует себя в ловушке и либо блокирует, либо жалуется в ФАС.

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

Ошибка 5. Маскировка рекламы под сервис

Это попытка сэкономить на маркировке и обойти требования закона. Работает короткое время, потом аудитория всё равно перестаёт реагировать, а проверяющие — находят нарушения.

Как избежать: честно разделять сервисные и маркетинговые сценарии, регистрировать рекламу через ОРД.

Ошибка 6. Отправка без согласия

Гость оставил номер при оплате картой — ресторан начинает писать ему акции. Формально согласия на маркетинг не было.

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

Ошибка 7. Одинаковый канал для всего

WhatsApp — для сервиса, Telegram — для акций, email — для новостей. Если ресторан валит всё в один канал, гость не понимает, что и когда ожидать.

Как избежать: распределить типы сообщений по каналам в зависимости от их природы.

Ошибка 8. Отсутствие реакции на отписку и жалобы

Гость отписался — а ресторан продолжает писать через другой канал или после повторной подписки без явного действия.

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

Как измерять эффективность сценарных уведомлений

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

Метрики доставки и вовлечения

• Open rate. Доля доставленных сообщений, которые были прочитаны. Для WhatsApp — около 70–85% в первые минуты, для Telegram — 50–70%.
• Click-through rate. Доля тех, кто нажал на ссылку или кнопку. Зависит от сценария: для сервисных — 30–50%, для рекламных — 5–15%.
• Response rate. Доля тех, кто ответил. Для сервисных — высокая (гость уточняет детали), для рекламных — низкая.

Метрики реакции гостя

• Unsubscribe rate. Доля тех, кто отписался после конкретного сообщения. Если выше 2–3% — сообщение раздражает.
• Block rate. Доля тех, кто заблокировал. Критичный показатель: если есть хоть один — повод пересмотреть сценарий.
• Complaint rate. Доля жалоб. Должен стремиться к нулю.

Бизнес-метрики

• Return rate. Доля гостей, получивших сценарий, которые вернулись в течение 7/14/30 дней.
• Incremental revenue. Дополнительная выручка, атрибутированная к сценарию.
• Retention. Изменение удержания гостей в когорте, получающей сценарии, по сравнению с контрольной.
• LTV. Изменение пожизненной ценности гостя.

Как свести метрики в дашборд

Идеальный вариант — единый дашборд, где видно:

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

Если такого дашборда нет — хотя бы таблица в Google Sheets, обновляемая раз в неделю.

Чек-лист внедрения сценарных уведомлений

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

1. Подготовительный этап

• [ ] Описать жизненный цикл гостя.
• [ ] Определить ключевые события и триггеры.
• [ ] Составить карту сценариев: сервисные и рекламные.
• [ ] Согласовать юридическую рамку: согласия, политика конфиденциальности, маркировка.
• [ ] Выбрать каналы: WhatsApp, Telegram, оба.
• [ ] Подключить провайдера WhatsApp Business API.
• [ ] Создать Telegram-бота.

2. Контент и шаблоны

• [ ] Написать тексты для сервисных сценариев.
• [ ] Написать тексты для рекламных сценариев.
• [ ] Согласовать шаблоны WhatsApp с Meta.
• [ ] Утвердить анти-спам правила.
• [ ] Подготовить тексты отписки и настроек.

3. Техническая интеграция

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

4. Запуск пилота

• [ ] Выбрать 3–4 базовых сценария.
• [ ] Запустить на ограниченной аудитории (1–2 недели).
• [ ] Собрать обратную связь от гостей.
• [ ] Проанализировать метрики доставки и реакции.
• [ ] Отладить тексты и условия.

5. Расширение

• [ ] Добавить новые сценарии (возврат, лояльность, отзывы).
• [ ] Зарегистрировать рекламные сценарии через ОРД.
• [ ] Настроить аналитику и дашборд.
• [ ] Запустить сценарные цепочки на всю аудиторию.
• [ ] Регулярно пересматривать эффективность.

6. Поддержка

• [ ] Мониторинг жалоб и блокировок.
• [ ] Обновление согласий при изменении политики.
• [ ] Регулярный аудит сценариев: что работает, что нет.
• [ ] Обновление шаблонов WhatsApp при изменении меню, услуг, процессов.

Особые случаи: что делать, если ресторан работает в нескольких городах или форматах

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

Сетевой ресторан

• Единая CRM или несколько? Чем больше точек, тем важнее единый профиль гостя. Если гость посетил два ресторана сети — он не должен получать одно и то же приглашение дважды.
• Локальные сценарии vs. федеральные. Акция сети работает на федеральном уровне. Локальное событие — на уровне города. Сценарии должны различаться.
• Маркировка рекламы. В каждом городе нужно учитывать рекламные креативы в ОРД.

Франшиза

• Кто управляет базой? Центральный офис или точка? Обычно — центральный, но с локальными правами.
• Кто согласовывает сценарии? Если в точке хотят запустить локальную акцию — её нужно согласовать с центральным маркетингом, чтобы не нарушить общую политику.
• Кто оплачивает WhatsApp API? Обычно центральный офис, иначе затраты размазываются по точкам и сложно контролировать качество.

Ресторан + доставка + кейтеринг

• Разные гости — разные сценарии. Гость, который заказывает доставку, и гость, который бронирует банкет, — разные сегменты. Сценарии для них должны быть разными.
• Разные циклы. Доставка — быстрый цикл (заказ каждый день). Кейтеринг — длинный (заказ раз в несколько месяцев).
• Разные каналы. Доставка — WhatsApp. Кейтеринг — может быть и Telegram, и звонок.

Что меняется в 2026 году: тренды, которые нужно учитывать

Рынок мессенджер-коммуникаций в ресторанном сегменте продолжает меняться. Несколько трендов, на которые стоит обратить внимание.

Рост стоимости WhatsApp-сообщений

Meta регулярно пересматривает тарифы. В 2025–2026 годах тарифы на маркетинговые сообщения выросли, на сервисные — остались относительно стабильными. Это ещё один аргумент в пользу того, чтобы строить канал вокруг сервисных сценариев и не злоупотреблять маркетинговыми.

Усиление регулирования

ФАС, Роскомнадзор и отраслевые ассоциации всё внимательнее следят за мессенджер-маркетингом. В 2025 году появилось несколько показательных дел именно против ресторанных сетей. Тренд — регулирование будет ужесточаться, и ресторанам, которые строят коммуникацию «на серых схемах», придётся либо перестроиться, либо уйти с канала.

Рост ожиданий гостей

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

Интеграция с AI

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

Омниканальность

Гость не живёт в одном канале. Он может начать в WhatsApp, перейти в Telegram, вернуться в email. Ресторан должен видеть всю историю взаимодействия, независимо от канала. Это требует единого профиля в CDP или CRM.

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

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

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

• Опыт работы с HoReCa. Ресторанная специфика — сложная, и общие маркетинговые платформы часто не учитывают её.
• Интеграция с вашей POS. iiko, R-Keeper, Poster — у каждого свои возможности интеграции.
• Поддержка WhatsApp Business API. Желательно через официального провайдера Meta.
• Возможность работы с Telegram. Не все платформы имеют полноценную поддержку Telegram.
• Управление согласиями. Возможность вести базу согласий, отписок, сегментов.
• Аналитика. Открываемость, реакция, возвраты.
• Юридическая поддержка. Шаблоны сообщений, соответствующие требованиям 152-ФЗ и 38-ФЗ.
• Стоимость. Не только подписка, но и стоимость сообщений, настройки, поддержки.

Типы подрядчиков

• Customer engagement платформы — полноценные системы автоматизации, которые закрывают email, SMS, мессенджеры, push.
• CRM-системы с поддержкой мессенджеров — если ресторан уже использует CRM, и в ней есть модуль мессенджеров.
• Специализированные сервисы для HoReCa — узкие решения, «заточенные» под рестораны.
• Интеграторы — компании, которые собирают решение из нескольких сервисов.

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

Кейсы: как это работает в реальных ресторанах

Несколько примеров из практики ресторанов России.

Кейс 1. Сеть кофеен в Москве

Сеть из 12 кофеен внедрила сценарные уведомления через WhatsApp Business API. Использовались три сценария:

• Подтверждение заказа и статус готовности.
• Напоминание о брони (если гость бронирует столик в приложении).
• Реактивный возврат: если гость не заказывал 30 дней — сообщение «давно вас не видели, всё в порядке? Если хотите отключить уведомления — дайте знать».

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

Кейс 2. Ресторан высокой кухни в Петербурге

Использовали комбинацию WhatsApp + Telegram. WhatsApp — для сервисных уведомлений (бронь, статус заказа). Telegram — для интерактива (заказ столика, выбор меню, оплата).

Сложность: аудитория возрастная, WhatsApp заходил лучше, чем Telegram. Telegram использовали в основном для иностранных гостей и молодёжи.

Результат: сокращение no-show на 30%, рост среднего чека за счёт предзаказа блюд.

Кейс 3. Сеть доставки еды

Сценарии полностью построены вокруг доставки.

• Подтверждение заказа.
• Статус готовности.
• Статус доставки.
• Запрос оценки через 30 минут после доставки.
• Реактивный возврат: если гость перестал заказывать — сообщение с предложением попробовать новое блюдо.

Главное достижение — рост повторных заказов на 22% без увеличения рекламного бюджета. Ключевой фактор — каждое сообщение попадало в нужный момент.

Частые вопросы владельцев ресторанов

Нужен ли отдельный юрист, чтобы запустить мессенджер-маркетинг?

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

Сколько стоит запуск?

Зависит от масштаба. Базовый запуск (WhatsApp API + пара сценариев) — от 30 000 до 100 000 ₽ на настройку плюс ежемесячная плата за сообщения. Крупные проекты — от 300 000 ₽ и выше.

Можно ли обойтись только Telegram?

Если аудитория — молодёжь и Telegram-активные пользователи — да. Но для широкой аудитории лучше WhatsApp. Оптимально — оба.

Что делать, если гость пожаловался в ФАС?

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

Как понять, что сценарий работает?

Смотреть на бизнес-метрики: возврат гостей, средний чек, частоту визитов. Если после запуска сценария возвращаемость растёт — сценарий работает.

Можно ли использовать WhatsApp через личный аккаунт?

Технически — да, но это запрещено правилами Meta и грозит блокировкой. Для бизнеса — только WhatsApp Business API через провайдера.

Что делать с Telegram-ботом, если гость не отвечает?

Не дублировать сообщения. Один сценарий — одно сообщение. Если гость не отвечает — следующий триггер отправится по своему событию, не догоняя старый.

Что сделать на этой неделе: практический план запуска

Если ресторан хочет начать внедрение сценарных уведомлений уже сейчас — вот минимальный план на 7 дней.

День 1. Опишите 5 ключевых сценариев гостя: бронь, статус заказа, благодарность, оценка, возврат. Для каждого определите: триггер, текст, канал, частоту.

День 2. Согласуйте юридическую рамку: проверьте политику конфиденциальности, добавьте согласие на мессенджер-коммуникации, опишите отписку.

День 3. Выберите канал: WhatsApp, Telegram или оба. Если ресторан уже использует iiko или R-Keeper — проверьте, есть ли встроенная поддержка мессенджеров.

День 4. Подключите провайдера WhatsApp Business API или создайте Telegram-бота. Согласуйте шаблоны WhatsApp.

День 5. Настройте 2–3 базовых сценария в тестовом режиме. Проверьте доставку, шаблоны, тексты.

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

День 7. Соберите обратную связь, проверьте метрики, отладьте тексты. Решите, какие сценарии масштабировать.

Итог: почему сценарные уведомления — это не маркетинговый тренд, а операционная необходимость

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

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

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