Как ограничить сообщения от разных ИИ сценариев одному клиенту

Утром клиент получает письмо о скидке. Через час бот напоминает о незавершённой заявке. После обеда менеджер уточняет решение, а вечером ИИ-помощник предлагает похожую услугу. Каждое сообщение отдельно выглядит уместным. Для получателя это четыре обращения одной компании за день. Настройка хороших текстов здесь не помогает: бизнесу нужен общий порядок, по которому разные сценарии получают право на очередной контакт.

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

Рассмотрим условную компанию, которая продаёт услуги для бизнеса. Маркетолог настроил подборку раз в неделю. Отдел продаж напоминает о коммерческом предложении через два дня. Сервисный бот просит оценить консультацию, а ИИ-сотрудник возвращается к разговору, который клиент начал вчера. У каждого сценария есть причина написать. Ни у одного нет полной картины.

Человек при этом не разделяет компанию на подразделения. Он видит одного отправителя, даже когда письма приходят с разных адресов. Фраза «это другая рассылка» ничего не объясняет клиенту, который уже третий раз закрывает уведомление.

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

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

Сначала посчитайте контакты глазами получателя

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

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

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

Эта проверка переводит спор из вкусовой плоскости в операционную. Вместо «нам кажется, что писем много» появляется конкретная последовательность. Именно её и предстоит изменить.

Определите единицу контакта

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

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

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

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

Общий лимит и лимит канала решают разные задачи

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

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

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

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

Расставьте приоритеты до запуска ИИ

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

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

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

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

Храните состояние человека а не только сценария

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

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

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

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

Проверяйте разрешение непосредственно перед отправкой

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

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

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

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

Используйте паузы с понятными причинами

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

Введите паузы, связанные с состоянием отношений: согласованное ожидание, открытая проблема, незавершённое уточнение, недавно отправленный материал. У каждой паузы должна быть причина и условие завершения. Иначе клиент навсегда выпадет из общения из-за старой отметки.

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

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

Объединяйте только совместимые сообщения

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

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

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

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

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

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

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

Twilio описывает передачу распознанного отказа в приложение через параметр OptOutType при включённом Advanced Opt-Out. Для проектирования собственной системы здесь полезен принцип: изменение предпочтения должно стать событием, которое получают все связанные сценарии. Это пример технического механизма, а не описание правил конкретного российского канала.

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

Не прячьте от команды причины отмены

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

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

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

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

Проверьте трудные сочетания заранее

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

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

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

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

Как проверить результат без красивых иллюзий

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

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

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

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