CX-automation ломается не в триггере, а на стыке контекста и исключений

CX-automation ломается не в триггере, а на стыке контекста и исключений

Если агент отвечает за support, retention или follow-up, проверьте три слоя: 1) входной контекст из CRM/тикета, 2) правила эскалации, 3) память между итерациями. Чаще всего пайплайн работает только на «чистом» кейсе, а дальше начинает терять статус клиента, тему обращения и уже отправленные ответы.

Типовые поломки:
— агент не видит, что клиент уже в активной переписке;
— шаблон ответа подмешивает устаревший оффер;
— classification step ошибается на коротких и шумных запросах;
— после 8–12 шагов теряется цель цепочки и агент начинает пересказывать себя.

Чтобы это не расползалось, делайте явный state schema: что агент обязан хранить, что может перезаписать, а что только читать. Для долгих цепочек держите checkpoint после каждого критичного шага: резолв тикета, обновление CRM, отправка письма, смена статуса. И отдельно логируйте причины fallback, иначе debug превращается в гадание.

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