Согласие на WhatsApp в 2026 году: что изменилось

Короткий ответ требует точности: отдельное согласие именно на WhatsApp теперь нужно не всегда, но предварительное разрешение по-прежнему обязательно. Номер в CRM, завершенный заказ или один начатый клиентом чат не дают бессрочного права отправлять любые будущие предложения.

Актуальная страница Meta, обновленная 16 июня 2026 года, поясняет, что после изменения политики в ноябре 2024 года общего согласия может быть достаточно. Человек должен предоставить мобильный номер и разрешить последующие сообщения или звонки от конкретной компании, а компания — соблюдать применимое право. Также должно быть понятно, кто соглашается и какая компания будет связываться (актуальное руководство Meta).

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

1. Прочитайте правило, не потеряв гарантии

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

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

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

2. Используйте двухуровневую проверку

Перед добавлением контакта в кампанию применяйте два шлюза.

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

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

Границы цели — собственный контроль компании, а не официальное поле Meta. Он превращает вывод в исполнимое правило. Сегмент может требовать permission_status = active и promotion_scope = true, а не расплывчатый флаг opted_in.

• Клиент просит статус заказа — Разрешение обработать сервисный запрос, не вся будущая реклама: Ответить по теме; отдельно получить рекламное разрешение
• Форма называет компанию и будущие предложения — Возможное согласие, если это поддерживают текст, доказательство и право: Сохранить версию и категорию
• В старой CRM есть только номер — Доказуемого разрешения нет: Исключить из исходящих кампаний
• Реклама открыла чат WhatsApp — Чат инициирован клиентом, но это не вечное рекламное согласие: Обслужить запрос и явно запросить дальнейшее разрешение
• Человек пишет «стоп» — Разрешение для соответствующей области отозвано: Немедленно исключить из нужных кампаний

3. Храните доказательство, выдерживающее жалобу

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

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

Не заменяйте старое «да» новым «нет». Добавляйте событие и вычисляйте текущий статус. Так сохраняется последовательность: что приняли, что изменилось и какие кампании были допустимы. Ограничивайте доступ и срок хранения по своей программе безопасности; аудит не оправдывает избыточный сбор.

Используйте стабильные причины: no_evidence, service_only, promotion_allowed, global_opt_out, category_opt_out, expired, manual_review. Свободная заметка дополняет контекст, но не должна быть единственным барьером отправки.

4. Отделите сервис от рекламы

Сервисное окно и область разрешения отвечают на разные вопросы. Документация Meta описывает скользящее 24-часовое окно после сообщения пользователя. Внутри него доступны свободные ответы, а исходящее сообщение компании вне окна требует одобренного шаблона (документация Meta по сообщениям).

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

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

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

5. Постройте процесс разрешений

Начинайте при привлечении, не при запуске кампании.

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

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

6. Пример: районная прачечная

Прачечная берет номер при приемке. Форма называет компанию и спрашивает, нужны ли уведомления о готовности. Это подтверждает сервисные обновления по заказу, но не ежемесячные скидки.

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

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

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

7. Реализуйте контроль в DripTell

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

Рабочая область кампаний поддерживает планирование, сегментацию, обработку доставки и статусы доставки, чтения и ответа по получателю. Стройте аудиторию по актуальным разрешениям и исключениям до планирования; доставка не доказывает согласие. Общий inbox дает назначения, заметки, статус и контекст, поэтому вопрос об отказе получает владельца.

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

8. Проверьте один путь за 30 минут

Возьмите реальный путь привлечения и кампанию. Ответьте по записям:

• Названы ли компания и разница между сервисом и рекламой?
• Можно ли получить точную версию текста, увиденную контактом?
• Надежно ли время и сохранен ли часовой пояс?
• Может ли сегмент требовать активную область конкретной цели?
• Останавливает ли отказ все связанные сегменты и очереди?
• Может ли сервис продолжиться без повторного включения в рекламу?
• Проверяется ли 24-часовое окно отдельно от разрешения?
• Назначен ли владелец каждому ответу и спору?
• Объяснимы ли включение одного контакта и исключение другого?
• Ограничен ли доступ к доказательству и определен ли срок хранения?

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

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