Когда эффективнее автоматизировать 70% вместо 90%, или Почему финтех-боту иногда лучше замолчать?

Этот текст завершает первую и вторую части трилогии о внедрении LLM в клиентские сервисы. Если раньше мы обсуждали ИИ-агентов и базовую архитектуру, то третья статья получилась самая «бизнесовая» в цикле.

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

Миф о «мгновенном интеллекте» и реальные точки ценности

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

Наибольшую бизнес-пользу в голосовом финтехе обычно дают не «футуристические» сценарии, а очень земные: 

• забрать звонок при перегрузке очереди, 

• назвать статус платежа, 

• зафиксировать удобное время связи, 

• коротко объяснить процедуру оплаты/погашения 

• и вовремя передать разговор человеку. 

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

• перераспределить входящий поток, 

• взять звонок в нерабочее время, 

• быстро уточнить статус, 

• проверить факт в системе 

• и либо закончить разговор на месте, либо передать его сотруднику без лишнего трения. 

Хороший голосовой AI — это чаще не шоу-кейс, а нормальный слой операционной разгрузки.

Пять живых бизнес-сценариев: от разгрузки до эскалации

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

Почему мы не отказываемся от сценариев и правил

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

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

Качественный handoff — признак зрелости системы

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

Где автоматизация обычно работает лучше всего? 

Там, где вопрос короткий и предметный: 

• проверка статуса, 

• подтверждение, что платёж ещё в обработке, 

• назначение удобного времени связи, 

• озвучивание следующего шага по известному регламенту, 

• спокойная навигация по типовым вопросам. 

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

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

• статус платежа, 

• статус заявки, 

• подтверждение операции, 

• назначение времени связи, 

• навигация по процессу («что делать дальше?») 

• и перевод на нужного специалиста. 

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

Что интересно, дальнейшее расширение покрытия давало значительно меньший эффект. Первые 20–30% автоматизированных сценариев обеспечивали более 70% итоговой экономии операционного времени (очередное подтверждение работы принципа Парето 🙂).

Где лучше сразу включать человека?

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

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

Персональные данные в голосе и реальные KPI голосового AI 

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

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

Неожиданный эффект: иногда LLM делает сервис хуже

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

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

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

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

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

Вывод

Один из самых неожиданных выводов эксплуатации оказался довольно простым. В начале проекта мы считали успехом любой сценарий, который можно автоматизировать. Через год критерий изменился: успешным считался уже не сценарий, который бот смог завершить самостоятельно, а сценарий, который завершился правильно. В результате часть диалогов сознательно вернули на сотрудников, а доля автоматизации даже немного снизилась. Зато количество повторных обращений уменьшилось примерно на 14%, а уровень клиентских жалоб — почти на 20%.

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