Напоминания, которые переносятся вместе со встречей

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

Динамический фоллоу-ап устроен иначе. Он не отсчитывает время от отправки, а привязан к событию из диалога и меняется вместе с ним.

Чем это отличается от обычного напоминания, которое просто отправляется через время

Обычный фоллоу-ап — это таймер: агент написал, клиент молчит двадцать минут, уходит догоняющее сообщение. Момент отправки считается от последней реплики в переписке.

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

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

Какие условия решают, что напоминание сработает

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

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

Три даты одной записи: как собрать цепочку и не превысить лимит вызовов

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

Перенесли встречу в понедельник — что происходит с напоминанием

Разберём это на одном диалоге целиком.

Клиент записался на консультацию на пятницу. Агент вызвал действие «Установить фоллоу-ап» с тремя аргументами: напоминание сразу, за день и за два часа до визита. Первое ушло тут же, в момент записи: подтверждение с деталями.

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

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

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

Расписание, чтобы напоминание не ушло ночью

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

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

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

Что ломается, когда напоминание живёт отдельно от календаря

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

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

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

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

Зафиксируйте список: перенос записи, отмена, повторная запись после отмены — каждое из этих действий должно вызывать то же действие «Установить фоллоу-ап» с новыми аргументами, а не оставлять старые сообщения без присмотра.

Дальше решите, какой из двух способов отмены подходит вашему сценарию: автоматическая замена при активации шага для случаев с частыми переносами (запись к специалисту, бронирование стола) или отдельное действие «Отменить фоллоу-ап» для точечной отмены без немедленной новой записи. Если сомневаетесь, начните с одного напоминания за день до события и с проверки, есть ли отмена в этом диалоге, а вторую и третью дату добавляйте, когда первая заработает предсказуемо. Полный список настроек шага и условий срабатывания — в руководстве Савви.

Частые вопросы