Привет! Это моя первая статья на Хабре, а к ее созданию меня подтолкнуло решение кейсов для отбора на стажировку от Т-Банка - я проделывал большой объем работ, но фидбека по кейсу не получал, лишь сухое "Спасибо за участие! К сожалению..." и т.д. Подобная фраза никак не помогала мне прогрессировать, находить точки роста и выявлять ошибки в моем решении, поэтому я решил выложить результат работы здесь в надежде на обратную связь от читателей - было бы очень приятно и познавательно услышать, что можно улучшить или доработать. Приятного чтения!

Задача кейса

Представь, что ты ML-продакт в Т-Банке. В твоей зоне ответственности — чат-бот, задача которого автоматизировать поддержку. Сейчас доля автоматизации чатов (время, когда бот справляется без участия оператора) составляет 30%, а цель бизнеса — увеличить её до 60% за 2 года, при этом качество ответов и клиентский опыт не должны ухудшиться.

Вопросы

1. Почему автоматизация чатов — не идеальная метрика? Что не так?

   Само количество автоматизированных чатов не отражает качество предоставленных ответов и количество успешно решенных вопросов. Что касается автоматизации чатов в целом - она относится к бизнес-цели, эффектвность решения

2. Какие метрики качества реально важно отслеживать? В чём их плюсы и минусы?

3. Какие причины неавтоматизации надо решать в первую очередь? Почему?

4. Выдели 3 самых важных причины и объясни свой выбор.

5. Придумай, как решать каждую причину (особенно интересен ML-подход, если нужен):

   1. Как бы ты проверял гипотезы? В каком порядке, какие итерации?

   2. Какие тесты бы делал, на что смотрела в метриках (онлайн/оффлайн)?

6. Как бы боролся с тем, что клиент сразу зовёт оператора? Какие исследования тут нужны?

7. Как можно увеличить доверие к боту?

Решение

Пре-подготовка

Изначально хочу составить план решения кейса:

1. Мы составляем краткое саммари по задаче, определяем цели и зависимости.

2. Приступаем к ответам на вопросы, которые помогут углубиться в предметную область и сформировать решение

3. Итеративно добавляем информацию из полученных ответов и дополняем решение

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

Некоторые данные будут браться для удобства вычислений или наглядности - такие данные будут выделяться курсивом и/или дополнительно подсвечиваться

Саммари по задаче

Цели

• Увеличить долю диалогов, полностью обработанных ботом без участия оператора, с 30% до 60% для снижения нагрузки на операторов и роста эффективности обслуживания, что достижимо при наличии выделенной ML-команды и бюджете на обучение моделей к 10 ноября 2027 года (2 года)

• Не ухудшить средний Customer Satisfaction Score (CSAT) по диалогам, обслуженным ботом, **с показателя в (допустим, 4.5), за счёт улучшения UX и точности распознавания, что достижимо, исходя из показателей предыдущих лет, к 10 ноября 2027 года (2 года)

• Не ухудшить средний показатель First Contact Resolution (FCR) для автоматизированных диалогов (допустим, в 70%), что достижимо, исходя из показателей предыдущих лет, к 10 ноября 2027 года (2 года)

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

Зависимости

• У банка есть сегмент пользователей (клиенты с особыми привилегиями, VIP-клиенты, должники и т.д.), которые не должны быть включены в общую выборку для объективизации результатов, ведь для них предусмотрено, что они будут сразу подключены к оператору

• Важно определить главных заинтересованных лиц и учитывать интересы каждых на любом этапе задачи. С иерархией стейкхолдеров в Т-Банке по этой задаче не знаком, поэтому можем предположить:

  • Руководитель службы клиентского обслуживания

  • Руководитель автоматизации/чат-ботов

  • Руководитель отдела разработки/поддержки бота

  • Руководитель ML-команды

  • Руководитель команды QA

• Срок выполнения - 24 месяца

• Ресурсы:

  • ML-команда

  • Продакт-менеджер

  • Внутренние ML-ресурсы

Также на данном этапе составим наглядную таблицу в формате AS IS/TO BE с показателями, чтобы можно было легко возвращаться и сверяться с основными метриками и показателями.

*Для метрик, выделенных курсивом и обозначенным - данных нет, но перед решением задачи нужно определить эти метрики в количественном формате и обозначить за ориентир (если есть информация - взять текущие, если нет - получить путем вычислений или исследований)

Здесь мы добавили еще несколько контрольных метрик - NPS и Retention разных дней (не удалось найти в открытом доступе количество и частоту обращений в поддержку Т-Банка, поэтому дни возврата не указаны - их можно конкретизировать после появления соответствующей информации). Эти метрики помогут нам следить за внедрением решения более масштабно, контролировать процесс и вовремя вносить изменения.

Однако, можем вычислить примерное количество обращений в год для пользователя:

• На основании ресурса, более 50 млн человек являются клиентами Т-Банка, из которых ~33 млн - активные пользователи. Вероятнее всего, именно активные пользователи чаще всего обращаются в поддержку

• В среднем, ~10% активных клиентов обращаются в поддержку

• У каждого обратившегося может быть 1 и более обращений в месяц, ~1-2 (1.5)

• Количество обращений в месяц = 33 млн 10% 1.5 обращения = 4,95 млн обращений в месяц

Эта цифра позволяет нам оценить, какой Retention стоить взять (R15, R30, R60) и на какое количество чатов нужна автоматизация (можем применить в дальнейшем в расчетах) - при текущих объемах это примерно 2,97 млн автоматизированных чатов в месяц

---

Почему автоматизация чатов — не идеальная метрика? Что не так?

Само количество автоматизированных чатов не отражает качество предоставленных ответов и количество успешно решенных вопросов. Поэтому в разрезе решения задачи с развитием ML стоит обозначить метрики precision и recall, которые добавят объективности (и прийти к PR-AUC). Но это метрики оценки самой модели.

Для бота могут возникнуть ситуации - например, он просто переводит больше обращений к оператору на поздней стадии, либо оставляет клиента в подвешенном состоянии, что приводит к росту автоматизации, но падении CSAT

Из-за этих недостатков нужно выделить метрики качества, поэтому мы плавно переходим к следующему вопросу.

Какие метрики качества реально важно отслеживать? В чём их плюсы и минусы?

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

Основные метрики

Мы включили % автоматизации в основные метрики, потому что в сочетании с другими метриками качества отслеживание данного показателя будет целесообразным и объективным

Вспомогательные метрики

Далее определим из списка, какие причины неавтоматизации надо решать в первую очередь.

---

Какие причины неавтоматизации надо решать в первую очередь? В чём их плюсы и минусы?

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

Где Impact = насколько сильно устранение этой причины повысит % автоматизации и/или CSAT (допустим, 0.25 = низко, 0.5 = средне, 1 = высоко, 1,5 = очень высоко), Confidence = уверенность в оценках (от 0 до 1), Effort = оценка трудозатрат (1 = легко, 2 = средне, 3 = сложно). Умножаем на 100, т.к. Reach измеряется в процентах, а не в конкретном количестве.

*В таблице проведены не все расчеты, но по данным заметно, что они явно проигрывают

Таким образом, мы получили топ проблем для неавтоматизации, которые нужно решать в первую очередь, основываясь на фреймворке RICE:

1. Бот не смог продолжить решение проблемы клиента, не хватает ветки - самая массовая и технически простая категория. Покрытие веток напрямую повышает FCR и снижает обращаемость к оператору

2. Бот интент понял, но ответа в интенте нет - высокий эффект при низкой трудоёмкости. Можно быстро закрыть с помощью обновления контента

3. Не новый вопрос, продолжение предыдущего диалога - требует ML-работ, но обеспечивает рост охвата интентов и общий прирост автоматизации

4. Бот не знает такого намерения

5. Клиент зовет оператора

Выиграли они за счет большего охвата по сравнению с другими вариантами и будут иметь больший эффект от внедрения.

---

Как решать каждую причину?

Данный раздел имеет два подраздела:

• Как бы ты проверял гипотезы? В каком порядке, какие итерации?

• Какие тесты бы делал, на что смотрел в метриках (онлайн/оффлайн)?

Постараемся ответить на них последовательно. Разберем топ-1 причину: Бот не смог продолжить решение проблемы клиента, не хватает ветки. На основании данных из источника от 2025 года, банки используют следующие примеры решения задачи:

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

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

На основании данной информации можно создать гипотезу:

Гипотеза №1: Если мы внедрим механизм предугадывания запросов и персонализированных ответов за счёт интеграции чат-бота с пользовательским профилем и историей действий (например, через контекстный RAG и модель предсказания интентов), то это приведёт к повышению релевантности ответов и сокращению числа обращений, где бот не смог продолжить решение проблемы из-за отсутствия ветки или контекста, что улучшит метрику FCR (First Contact Resolution) на +3–5 п.п. при сохранении CSAT не ниже 4,5

Однако стоит учитывать, что эта гипотеза потребует долгой разработки и внедрения, поэтому нужно составить несколько простых к реализации гипотез (Составить небольшое MVP решения внутри продукта), чтобы уже сейчас начать собирать данные.

Из предложений:

• При наступлении этапа, при котором бот дальше не может предложить решение, он будет предлагать другие ветки решения проблемы, которые ему знакомы и наиболее коррелируют с текущей проблемой

Гипотеза №2: Если мы при наступлении этапа, когда бот не может продолжить решение проблемы, добавим механизм предложений альтернативных веток - т.е. бот будет подбирать и предлагать пользователю наиболее релевантные сценарии, коррелирующие с текущим запросом (на основе intent similarity и истории решения похожих кейсов), то это приведёт к снижению количества переводов на оператора и росту доли успешно завершённых автоматизированных диалогов, что улучшит метрику FCR (First Contact Resolution) на+2–3 п.п. при сохранении CSAT не ниже 4,5

• Добавление контекстных динамических подсказок в виде “Хочу уточнить”, “Не помогло, попробуем по-другому?” и т.д. для увеличения вариативности решения

Гипотеза №3: Если мы добавим контекстные динамические подсказки (например, “Хочу уточнить”, “Не помогло, попробуем по-другому?”, “Хочу объяснить подробнее”) в ключевых точках сценария, то это приведёт к увеличению вовлечённости пользователей в диалог с ботом и росту вероятности корректного уточнения интента при первой попытке, что улучшит метрику precision модели классификации интентов и в итоге повысит FCR на +1–2 п.п. , сохранив CSAT на уровне ≥4,5

Итак, мы составили большую гипотезу (которую отправим в разработку) и 2 небольших (которые запустим практически сразу), чтобы собирать информацию и использовать в реализации большой гипотезы. После получения инсайтов от гипотез №2,3 мы составим еще несколько, которые будем тестировать до момента полного внедрения гипотезы №1. Таким образом, мы составили план на развитие чат-ботов на ближайшее время (3-6 месяцев). Аналогичным образом мы поступим с остальными проблемами - составил бы основную главную гипотезу и разбил бы ее на несколько небольших, чтобы тестировать постепенно и корректировать основную при необходимости.

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

Оффлайн:

Тест №1: Прогнать исторические диалоги по новой логике (с успешным решением задач и без).

Цель: Понять, какие альтернативы система бы предложила и как часто они приводят к решению в исторических данных

Метрики:

• PR-AUC ≥ база +0.05

• CPAD

• CPRI

• Time to resolution

Тест №2: Смоделировать диалог на основе реальных веток и оценить с QA командой

Цель: Оценить релевантность решения сотрудниками QA

Метрики:

• Релевантность ответа (где 0 - нерелевантно, 1 - максимально релевантно)

Онлайн:

Тест №1: Запуск АБ теста с двумя вариантами - без новой системы и с ней

Цель: Понять, есть ли существенная разница между двумя вариантами

Метрики

• FCR

• CSAT

• Escalation Rate

• Time to resolution

• Intent accuracy

• PR-AUC ≥ база +0.05

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

• Бот интент понял, но ответа в интенте нет

  • Создать корпоративную базу данных и использовать RAG для обращения к ней при отсутствии ответа

  • Предоставление аналогичных ответов на вопрос в виде динамических окон

• Не новый вопрос, продолжение предыдущего диалога

  • Уточняющий вопрос от чата “Мы обсуждали [тема], продолжим?”, чтобы получить нужный контекст, а не загружать все - экономия токенов, увеличение точности и сокращение времени работы

  • Выделение в динамичные блоки основных тем, которые обсуждались ранее в чате. Пользователь выбирает тот, который наиболее релевантен

---

Как бы боролись с тем, что клиент сразу зовёт оператора? Какие исследования тут нужны?

Для борьбы с моментальным вызовом оператора я бы провел следующие исследования:

• Провести глубинное и проблемное интервью с клиентами, которые запросили оператора сразу. Можно также сделать отдельное интервью с теми, кто успешно решил проблемы через чат-бота, получим сравнение инсайтов и сможем получить более объективный вариант (или же сгенерировать еще больше гипотез).

• Добавить форму обратной связи с вопросами после любого опыта использования бота (позитивного, негативного)

• Провести JTBD-интервью для выявления дополнительных инсайтов (возможен пересмотр логики чат-бота)

• Добавить UX исследования c добавлением сценариев или элементами, вызывающими доверие у пользователя. Например, как usability-тестирование с клиентами

• Добавить ощущение экономии времени через описание фактов для пользователей. Например: клиент запрашивает оператора, но бот отвечает “Конечно, я могу подключить оператора. Но время ожидания на линии до подключения оператора сейчас составляет 5 минут, я же, в среднем, решаю вопрос за 2 минуты”

Если говорим об ML-исследованиях, то я бы сделал следующее:

• Модель раннего предсказания эскалации: бинарный классификатор, который по первым 2-3 сообщениям оценивает, с высокой вероятностью ли пользователь попросит оператора

• Адаптивное обращение с пользователем: за счет классификации настроения пользователя мы подбираем один из паттернов общения с клиентом. MVP - с наивным байесовским классификатором (к какому классу вероятнее всего принадлежит слово пользователя), далее - более сложные модели.

---

Как можно увеличить доверие к боту?

Проанализировав несколько источников, было найдено пару инсайтов и реальных примеров для увеличения доверия к боту. Перечислим их:

• Создание эффекта “постоянного помощника”. Для пользователей, которые обращаются к боту изредка и только в случае возникновения проблем, он является чем-то необычным и незнакомым, что влияет на Churn и Excalation Rate. Если же мы внедрим его в повседневную жизнь пользователя (оповещения о платежах и прочие уведомления, которые встречаются часто в жизни пользователях), доверие к нему увеличится. Однако стоит не переусердствовать (чтобы не быть назойливым), а выделить те уведомления, которые будут максимально полезны (необычные списания, важные платежи и т.д.). Пример: Эрика (Bank of America), Ино (Capital One)

• То, что указывал ранее - добавить ощущение экономии времени через описание фактов для пользователей.

• Адаптация под тон и настроение пользователя

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

• Клиент - “Очень хочу купить вещь за 5000 рублей, как думаешь, стоит?”

• Бот - “Давай посчитаем, насколько целесообразна будет данная покупка: твои среднемесячные пополнения за 6 месяцев = Х руб, а среднее кол-во денег на карте ****1111 = Y руб. У тебя есть постоянные платежи - ЖКХ = Z руб, кредит на обучение = A руб. С учетом всех трат, я бы посоветовал тебе взять эту вещь - порадуй себя!”

---

Выводы по проделанной работе

1. Разобрались с проблемой метрики % автоматизации чатов

Количество ≠ Качество. Для объективной оценки нужно использовать метрики качества в совокупности с количественными и поведенческими: CSAT, FCR, NPS, Retention и т.д.

2. Выделены метрики качества, необходимые для решения задачи

• Основные: : CSAT, FCR, NPS, Retention, % автоматизации, CPAD, CPRI

• Вспомогательные: Intent accuracy, Time to resolution, Escalation rate, Precision, Recall, PR-AUC

3. Определены главные причины неавтоматизации и выделены топ-3 из них

Наибольший потенциал роста кроется не в технических сбоях, а в сценарных и контекстных разрывах:

• отсутствие веток (6,7%),

• интент понят, но ответа нет (3,3%),

• продолжение старого диалога (5,4%).

Вместе они дают около 15% всех провалов автоматизации и высокий ROI исправления (низкая сложность - высокая отдача).

4. Сформированы алгоритмы решения проблемы

Составлены гипотезы, варианты тестов и исследований, ключевые метрики и порядок тестирования по каждой из проблем - как в стандартном, так и в ML-подходе

5. Составлены варианты исследований для решения проблемы моментального вызова оператора

Среди которых:

• Провести глубинное и проблемное интервью с клиентами

• Провести JTBD-интервью

• Добавить UX исследования

• и т.д.

6. Определены этапы и способы повышения доверия к боту

Основная идея - внедрение бота в повседневную жизнь пользователя для закрепления ассоциации о “знакомом и полезном”