CRM-аналитика
Согласия и предпочтения в банке: почему одного флага недостаточно
Время чтения: 5 мин
Уровень материала: Для экспертов
Содержание
Клиент отказался от рекламы в приложении, но продолжает получать предложения по SMS. В базе одного продукта стоит «нет», в общей CRM — «да», а контактный центр ориентируется на старую анкету. Найти единственного виновного трудно, потому что система хранит итоговые флаги без истории и назначения.
Для банка согласие — не универсальный пропуск ко всем коммуникациям. Нужно различать обработку данных, рекламу, обслуживание договора, канал связи и юридическое лицо, от имени которого происходит действие. Конкретные правовые основания утверждает ответственная функция; CRM должна точно выполнять эти решения.
Начните с назначения сообщения
Сервисное сообщение сопровождает конкретную операцию или обязательство. Рекламное предлагает продукт или стимулирует его приобретение. Название «транзакционное» в платформе само по себе не определяет правовую природу содержания.
Если в уведомление об операции добавили предложение нового продукта, его нужно повторно классифицировать. Нельзя считать рекламный блок разрешённым лишь потому, что основное уведомление обязательно.
Для каждого шаблона сохраняют цель, утверждённую классификацию, отправляющее юридическое лицо, состав данных, канал и условие допустимости. Это позволяет проверить конкретную отправку, а не спорить о всей категории «банковские письма».
Почему подписи одним кодом недостаточно для ясности
Банк России описывал проблему недостаточного информирования при подписании пакета документов простой электронной подписью: клиенту могло быть неясно, какие согласия и документы подтверждаются одним действием. Практический смысл разбора — обеспечить осознанность и доступность содержания, а не считать факт SMS-кода универсальным доказательством понимания.
Для реализации полезно связать действие человека с конкретной версией каждого применимого текста и предусмотренным способом выбора. Какие согласия оформляются отдельно и как именно, определяют по действующим требованиям к данному процессу. Не следует заменять правовую проверку общим правилом «добавим ещё одну галочку».
Храните события, а не только последнее значение
| Поле | Зачем нужно | Пример использования |
|---|---|---|
| Субъект и контакт | Определить, к кому относится разрешение | Не перенести его на новый номер автоматически |
| Цель и юридическое лицо | Ограничить применение | Не распространить выбор одного сервиса на всю группу |
| Канал и объём | Понять разрешённый способ контакта | Различать рекламные SMS и другие процессы |
| Версия текста | Восстановить содержание | Показать, что было доступно человеку |
| Событие и время | Восстановить последовательность | Сопоставить выдачу и отзыв |
| Источник и доказательство | Проверить происхождение | Связать форму, действие и журнал |
Итоговый статус рассчитывается из этой истории по утверждённым правилам. Если новый импорт принес старое «да», он не должен молча отменить более поздний отзыв.
Отзыв должен дойти до очереди отправки
Распространённая ошибка — обновить карточку, но оставить подготовленные сообщения в другой системе. Поэтому проверка разрешения нужна не только при входе в сегмент, но и непосредственно перед отправкой.
Определите допустимую задержку распространения, механизм отмены очереди и контроль подтверждений от каналов. Если состояние неизвестно, рекламную отправку останавливают по согласованной политике. Обязательные сообщения обрабатываются отдельно на своих основаниях и маршрутах.
Смена номера или адреса также требует пересмотра связи с разрешением. Разрешение не должно автоматически следовать за контактным значением, которое могло перейти другому человеку.
Условный пример технической ошибки
В 10:00 клиент отказался от рекламных SMS. В 10:02 событие поступило в центральный реестр, но система отправки обновляет аудиторию раз в час. Сообщение из подготовленной очереди ушло в 10:20.
Поле в CRM выглядит корректным, однако процесс отзыва не сработал для конкретного контакта. Исправление состоит не в переносе времени события на более раннее, а в проверке перед отправкой, отмене очереди и мониторинге задержки.
В отчёте нужны количество затронутых отправок, источник сбоя и фактическое восстановление маршрута. Нельзя исключать такие сообщения из статистики только потому, что они были подготовлены до отзыва: применимые правила оценивает ответственная команда, а журнал должен сохранять реальные времена.
Предпочтения дополняют разрешения
Даже при допустимой коммуникации клиент может хотеть только определённые темы или удобный канал. Это слой предпочтений: частота, интересы, формат. Он не заменяет правовое основание и не расширяет его.
Если человек выбрал «интересуют вклады», это не означает согласия передавать данные отдельному страховщику. Если разрешены письма, предпочтение «общаться реже» должно реально менять политику, а не оставаться полем, которое никто не использует.
Центр настроек полезен, когда изменения понятны: что отключится, что продолжит поступать по предусмотренным основаниям и где проверить выбор. Не заставляйте клиента изучать внутреннюю организационную структуру, чтобы прекратить обычную рекламу.
Как проверить систему до запуска
При объединении дублирующихся профилей разрешения не складываются по правилу «хотя бы одно да». Сначала подтверждают, что записи относятся к одному человеку, затем восстанавливают последовательность и содержание событий. Более новое значение из ненадёжного импорта не обязательно отменяет подтверждённый отзыв. Правила конфликта описываются отдельно для каждой категории разрешения.
В управленческом отчёте полезно показывать не только размер доступной аудитории, но и долю записей с восстановимым основанием, задержку распространения отзыва и число отменённых перед отправкой сообщений. Сокращение рекламной базы после исправления ошибок — не обязательно потеря CRM. Это может быть устранение аудитории, которой прежде писали без достаточного подтверждения.
Пройдите контрольные истории: новое разрешение, отзыв, повторное подтверждение, смена контакта, импорт старой записи, объединение профилей и отправка из уже собранной очереди. Для каждой восстановите, какой статус использовался и почему.
Проверьте доступ подрядчиков: им может требоваться возможность отправить согласованный шаблон без выгрузки всей истории и банковских сведений. В журнале должно быть достаточно информации для расследования, но не лишние копии чувствительных документов.
Результат этой работы — исполнимая политика. У банка появляется возможность объяснить конкретную отправку, применить изменение выбора во всех нужных системах и не путать обязанность обслуживать клиента с разрешением предлагать ему любой продукт.
Источники
Банк России. Недостаточное информирование клиентов при подписании документов простой электронной подписью. Практика поведенческого надзора, 23 апреля 2024.