CX automation ломается не в LLM, а в точках передачи между системами

CX automation ломается не в LLM, а в точках передачи между системами

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

Чек-лист перед запуском:
— у каждого типа обращения есть жёсткий маршрут, а не «пусть модель решит»
— контекст подтягивается из CRM, ticketing и event-log, а не из одного prompt
— действия агента ограничены allowlist'ом: обновить статус, создать тикет, эскалировать
— после действия есть verification step: запись реально изменилась, письмо ушло, SLA не нарушен

Типовые поломки предсказуемы: агент пишет в CRM без idempotency и плодит дубликаты; теряет тему после нескольких уточнений; начинает «додумывать» причину обращения, если retrieval вернул слабый сигнал. Для таких кейсов лучше хранить короткую рабочую память отдельно от long-term history и сбрасывать её на границе сценария.

Если у вас CX-пайплайн строится только вокруг генерации текста, это не automation, а чат-обёртка. Надёжность появляется там, где у агента есть маршрут, ограничения и проверка факта выполнения.