Как остановить промо после обращения клиента в поддержку

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

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

Определите, какие обращения влияют на рекламу

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

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

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

Задайте область паузы

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

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

Храните причины, а не один переключатель

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

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

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

Условный пример: закрыли не то обращение

У клиента открыты два тикета: задержка заказа и неполный возврат. Первый закрыли после доставки. Интеграция отправила support_open=false и вернула клиента в акции, хотя второй вопрос остался.

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

Для правильного решения также важна связь обращения с клиентом. Совпадение email не всегда достаточное доказательство: общим адресом может пользоваться семья или несколько сотрудников компании.

Проверяйте состояние ближе к отправке

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

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

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

Как возвращать клиента в обычные сценарии

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

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

Чем проверить качество решения

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

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

Источники

Zendesk. Ticket Fields. Zendesk Developer API Reference. Проверено 22.09.2026.