Привет! Меня зовут Дима, и я почти два года работаю в Ozon. Я пришёл продакт-менеджером, а через год стал руководителем отдела, при этом продуктовая составляющая моей работы никуда не делась. Сейчас моя команда развивает платформу для создания чат-ботов, где наш флагман — это чат-бот клиентской поддержки внутри нашей WebCRM, где происходит вся магия общения с пользователями. 

Исторически сложилось, что в Ozon основной объём поддержки осуществляется через чат. В 2020 году бот закрывал 27% от общего числа обращений, а в 2022-м — уже 62%. Это сотни тысяч тикетов в день, при этом качество ответов не ухудшилось. Важность чат-бота выросла в разы.

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

В 2021 году агентство Markswebb в своём независимом исследовании чат-ботов поддержки поставило нас на первое место в ретейле и оставило тягаться с банками и телекомом. 

Зачем бизнесу нужен чат-бот?

Основная причина — экономия. Разберёмся, из чего состоит бюджет стандартного контакт-центра?

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

2. Зарплаты сотрудникам и налоги.

3. Риски. В контактных центрах обычно наблюдается текучка кадров, поэтому наём не прекращается практически никогда. 

4. Сезонность. Рост объёма заказов напрямую влияет на количество обращений в поддержку. В высокий сезон оно обычно увеличивается в два (а то и в три) раза, и этот поток надо встретить во всеоружии. При этом в Ozon, например, после каждого сезона объём заказов остаётся большим, то есть нагрузка на специалистов поддержки не снижается даже после окончания распродаж.

При таком объёме затрат бизнесу жизненно важно уменьшать операционные расходы — тогда на помощь приходит чат-бот.

Кто-то может возразить: «Сделайте нормальный интерфейс на сайте и в мобильном приложении — тогда вам и поддержка не нужна». Да, но давайте представим ситуацию. Вы заказали срочную доставку подарка маме на день рождения, курьер по какой-то причине задерживается, нервы на пределе. Пойдёте ли вы пользоваться селф-сервисом, чтобы понять, где же ваш заказ? Личный кабинет Ozon даёт ответы и позволяет осуществить все необходимые действия с вашим заказом в несколько кликов. Но причина, по которой люди идут в поддержку, связана с нашим восприятием: мы не доверяем бездушной машине, а хотим довериться человеку в решении вопроса. Именно поэтому до сих пор существуют такие профессии, как продавец-консультант и водитель такси.

Но не экономией единой! Процитирую коллегу @MikVolkov из статьи «Обеспечение качества чат-бота: разбираем на примере слоёного пирога»:

Кроме того, наши пользователи — это операторы, которым мы тоже помогаем в их работе:

— Уменьшаем рутину — снимаем с операторов однообразные вопросы. 

— Снижаем время обработки тикета: бот анкетирует клиента, и оператор, посмотрев на переписку, сразу понимает, в чём проблема, и даёт однозначный ответ. 

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

Отношение людей к ботам

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

На этом мы не остановились и спросили, что думают по поводу бота операторы.

Бот или не бот, вот в чём вопрос

Когда мы переходим к общению с клиентом, то задумываемся: стоит ли боту притворяться человеком или честно признаться, что он бот? У обоих подходов есть плюсы и минусы.

В итоге мы выбрали тот вариант, в котором бот представляется ботом, — по крайней мере до того момента, пока качество нашего распознавания не выйдет на уровень точности больше 90%. Это важно, так как мы хотим давать персонализированный ответ. С другой стороны, чтобы бот помогал оператору, он должен думать как оператор: к боту предъявляются те же требования в коммуникации с клиентом, и отслеживаются те же метрики, которые показывают успешность его работы как оператора. При этом стоит помнить, что бот поддержки — это не ассистент. Пользователи приходят к нам для того, чтобы решить свою проблему, поэтому бот должен быть дружелюбным, но серьёзным. 

Метрики

Ни один продукт не обходится без метрик. Более того, я глубоко убеждён, что любую фичу можно конвертировать в деньги. Но поскольку история про деньги — это в большинстве случаев NDA, то расскажу о том, как мы понимаем, что бот работает хорошо.

Продуктовые метрики

Наша North Star Metric (основная метрика) — это процент решённых ботом задач. Она же позволяет нам оценивать экономический эффект. Мы спрашиваем себя: «Сколько денег потратит компания без бота?» — и получаем размер экономии. Улучшить эту метрику несложно: можно заблокировать ввод текста и закрывать сразу 100% обращений. Это не наш путь — мы хотим, чтобы пользователю действительно помогли.

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

На втором уровне дерева метрик мы смотрим на то, как ведут себя элементы сценариев. Наш пользователь может общаться с ботом с помощью:

• виджетов,

• кнопок (быстрые ответы),

• интентов (текстовый ввод, который классифицируют ML-алгоритмы).

Все эти способы используются в сценариях бота. Сценарий — это путь, по которому пойдёт пользователь в зависимости от своего вопроса. Мы должны знать, какими путями пользователь ходит чаще, какими — реже и в каких из них происходит переключение на оператора, — это точки роста продукта.

Ещё один важный момент для экономии — уменьшение времени обработки тикета оператором. Если бот не справился, то оператор должен получить максимальное количество информации, чтобы дать единственно верный ответ, который решит проблему клиента. Для этого мы смотрим на Average Handling Time. Эта метрика выражается в минутах. Для её улучшения требуется анкетировать клиента на всём протяжении его общения с ботом. 

Технические метрики

Ozon состоит из микросервисов, которые написаны на Go. Поэтому мы тщательно следим за метриками в Grafana. Вот основные:

• процент gRPC-ошибок,

• процент ошибок в навыках,

• очереди пользователей.

На них же навешаны алерты, которые шлют нам информацию о том, что происходит, в каналы Mattermost. Так что, когда возникает проблема, мы узнаём о ней первыми.

Смешать, но не взбалтывать

Как технические, так и продуктовые метрики влияют на нашу North Star Metric — процент решённых ботом задач. Для отслеживания проблем и комбинаций технических и бизнесовых показателей мы придумали аварийный дашборд. Он показывает, как тот или иной показатель влияет на процент решённых задач. Таким образом, мы видим, что нам нужно исправить, если возникла проблема. При этом мы допускаем, что день ко дню метрика может колебаться в пределах одного-двух процентных пунктов.

Это история про ретроспективный анализ. А что делать с real-time аналитикой? Для отслеживания инцидентов мы в Ozon используем собственный аналог Opsgenie. В случае если наша North Star Metric упадёт ниже порогового значения, которое определяется экспериментальным путём, мы получим звонок другого бота об этом — и сделаем всё, чтобы наш бот снова ожил.

Команда

Кто вам понадобится, чтобы запустить крутого бота? Всё зависит от того, используете вы внешнее решение или делаете своё. Я расскажу, как устроена инхаус-разработка.

Состав

Язык бота — это то, что он говорит и как он это говорит. За это отвечают сценаристы. У нас это специальные люди, они не только рисуют схемы, но и продумывают логику работы сценариев. Их задача — предугадать, что спросит пользователь, как он может себя повести, и направить его по нужному сценарию. Кроме того, сценаристы придумывают, какими навыками должен обладать бот, и ставят задачи на разработку.

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

Сердце бота — это его способность понимать пользователя. За это отвечает команда дата-сайенса. На текущий момент для распознавания мы используем fastText, что приносит ряд болей: начиная сложностями работы с кучей интентов (сейчас их не менее 50, а должно быть более 200) и заканчивая ограничением масштабируемости решения на других ботов. Сейчас мы ведём активную работу по переезду на GPU-алгоритмы, и уже этим летом наш бот научится ещё лучше понимать клиентов.

Всё это поддерживает кровеносная система — тестирование, о котором уже подробно писали в статье «Обеспечение качества чат-бота: разбираем на примере слоёного пирога».

Процессы

Как у нас построены процессы:

1. Есть пул заказчиков, которые приходят к нам с идеями. Идея обязательно должна быть оценена в деньгах. Кроме того, заказчиками можем выступать мы сами. 

2. Сценаристы приступают к анализу: согласовывают логику работы и текст, который мы пишем, рисуют схему в Miro. 

3. После согласования происходит этап оценки объёмов работы и постановки задач. Сценаристы приходят к командам разработки и/или дата-сайенса и ставят задачи, которые помогут им реализовывать сценарии. В случае разработки это навыки бота, а в случае дата-сайенса — задачи из областей NLU и NER. 

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

Под капотом бота

Представим, что вы хотите узнать статус вашего заказа, заходите в чат поддержки (за него отвечает отдельная команда Ozon Messenger) и пишете: «Где мой заказ?». Через chat-api ваше сообщение попадает в очередь в Kafka, её читает наш сервис session-engine, который смотрит в нашу БД, где хранится информация о пользователе: чем закончился предыдущий диалог и метаинформация о его путешествии по нашему графу сценариев. Граф представляет собой большой JSON-файл (на момент написания статьи в нём ~80 000 строк), который имеет свою визуализацию в веб-интерфейсе, — мы называем это редактором сценариев. 

Далее боту нужно принять решение, что ответить пользователю. Для этого conversation-engine смотрит, по какому сценарию пошёл пользователь. Conversation-engine видит, что в рамках сценария бот должен определить интент с помощью определённой модели классификации. За это отвечает сервис nlp-engine, который исходя из установленного threshold’a для точности отдаёт интент order_where. 

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

Сформированный ответ conversation-engine отправит в session-engine, далее он попадёт в chat-api и окажется в Kafka, откуда фронт чатика возьмёт ответ бота и отобразит пользователю.

Генерация фич

Окей, команду собрали, архитектуру построили, бота запустили. А как придумать что-то новое?

В продуктах, которые не особо жалуют пользователи, непросто использовать кастдев-подход, поэтому мы опираемся на данные. Чаще всего идеи фич рождаются после детального просмотра сценариев, которые завершились переключением на оператора. Эту информацию мы смотрим в специальных отчётах Power BI, которые варят наши продуктовые аналитики.

Если у вас есть ресурсы на А/Б-тесты — не стесняйтесь проводить их. Например, у нас была фича, которая не давала сразу перейти на оператора, а пыталась заставить пользователя переформулировать вопрос. Ожидаемо, это повышало процент решённых ботом задач на несколько пунктов, но роняло фидбэк по качеству обслуживания на десятки процентов. В итоге мы используем её только в крайних случаях, например в сезон распродаж.

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

Дружите с компаниями, которые делают то же, что и вы. Например, мы дружим с ребятами из Тинькофф Банка и Lia: какие-то фичи мы позаимствовали у них, какие-то — они взяли у нас.

Посещайте профильные конференции — это универсальный способ быть в курсе трендов индустрии. Самая крупная конференция по разговорному искусственному интеллекту в России — Conversations. Обязательно берите с собой команду — так вы соберете максимальное количество инсайтов.

Easy to Learn, Difficult to Master

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

Наш подход позволил увеличить процент решённых ботом задач в два раза, при этом не потеряв в качестве обслуживания. Кроме того, на нашей платформе работают боты поддержки клиентов Ozon Travel, внутренней поддержки, поддержки пунктов выдачи заказов и поддержки продавцов. Наша чат-бот платформа продолжает развиваться, помогая компании экономить сотни миллионов рублей в год.

К слову, приглашаем на открытый Product Meetup — 28 июля, 18:00, онлайн и оффлайн. В программе сильный каст коллег из Ozon, Авито и Skyeng — регистрируйтесь и приходите.