Как ИИ-агент дожимает сделки в CRM по регламенту

Почему ручной дожим не держится дольше недели

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

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

Как агент читает сделку и решает, что писать

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

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

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

Дожим как событие в сквозной аналитике

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

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

Где дожим превращается в спам

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

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

Для уведомлений менеджеру о результате дожима я использую MAX, а не Telegram: сообщение может содержать имя клиента и детали сделки, а MAX хранит переписку на серверах в России, что закрывает вопрос с 152-ФЗ там, где Telegram оставляет открытый вопрос о юрисдикции данных. Логика агента при этом крутится на моделях, совместимых с российским контуром, — YandexGPT, GigaChat или self-hosted вариант, — так что персональные данные из сделки не уходят за пределы страны на этапе генерации текста.

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