Привет, Хабр! Я Юра Пчелин, руковожу командой корпоративной IT-поддержки в X5 Tech. В статье рассказываю о том, как наша служба поддержки реализовала масштабного чат-бота в помощь себе и коллегам.

Как мы пришли к идее создания чат-бота для внутреннего пользования

Одна из ключевых задач, которая стоит перед командой поддержки – это снижение количества входящих тикетов. У нас постоянно появляются новые системы, которые нужно поддерживать, поэтому важно не расширять поддержку, иначе в конечном результате она разрастётся до нереальных размеров. 

Отсюда и появилась идея создания чат-бота внутри компании, основная задача которого – помочь пользователю решить свои вопросы в моменте, не заморачиваясь чтением огромных инструкций на 10-30 страниц. В чат-боте есть возможность направить пользователя на нужный кусок этой инструкции, чтобы он мог за 2-3 минуты решить свой вопрос самостоятельно. 

Чтобы бизнес-процессы в компании не останавливались, поддержка через чат-бота происходит в режиме онлайн. С точки зрения клиента (как в магазине, так и в диджитале) при обращении в IT Support важно, чтобы не нужно было «стоять в очереди» и прерывать свою бизнес-операцию на время ожидания ответа. 

В какой-то момент мы столкнулись с конфликтом методов. С одной стороны – привычный ITIL-подход: тикетная система в саппорте отлажена, SLA настроен. С другой стороны – заявочная система удобна для исполнителя и при этом неудобна для клиента и сотрудника, если речь о внутреннем саппорте. В реальности люди хотят мгновенного решения своей проблемы. Это уже не только про техподдержку, это некий «лайфстайл» внутри бизнеса: ценность мгновенного доступа к сервису сегодня возрастает. ITIL-подход же вынуждает пользователя отложить операцию и ждать решения проблемы, переключаясь между задачами. 

Но если чат-бот не помог – а это случается, чат-боты не всегда справляются с такими объёмами задач – то мы даём возможность пользователю создать обращение в поддержку. 

Тем самым мы, в том числе, разгружаем первую линию поддержки, которая маршрутизирует неправильно назначенные обращения на нужные группы поддержки. Мы изначально знаем, что если сотрудник пришёл из системы Х, то его обращение должно быть назначено на группу поддержки Х, а не куда-то в другое место.

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

К чему мы стремимся

Мы проводим большую работу по дообучению чат-бота, чтобы он мог ответить на массу вопросов, с которыми сталкивается пользователь. В 95% случаев наш чат-бот уже понимает, о чём говорит пользователь (люди ведь по-разному формулируют свои запросы), но всё равно его нужно обучать, чтобы он попадал в точку с тем самым ответом, который ждёт пользователь. 

А ещё мы нативно интегрировали в JAICP – платформу чат-ботов от Just AI – технологию RPA Robin. В тех случаях, когда рутинных действий сотрудника поддержки не избежать (например, поддерживаемая система заморожена в развитии), RPA-бот в фоновом режиме за несколько минут выполняет операцию за специалиста поддержки и после этого результат отображается пользователю. 

Это большая работа, которой сейчас занимаются наши коллеги: те самые сотрудники поддержки, которые пытаются переквалифицироваться из поддержки пользователей в поддержку чат-бота и RPA. Мы мечтаем о том, что однажды пользовательской поддержкой будет всецело заниматься чат-бот, а сотрудники будут решать только какие-то сложные/нестандартные обращения, с которыми чат-бот явно не справится, и обучать того самого чат-бота всем этим запрограммированным командам. 

С чего мы начали и какие дилеммы решали

На старте проекта мы столкнулись с первой дилеммой – разрабатывать решение самим или смотреть платформы на рынке? В итоге родился третий вариант. Мы долго изучали платформы и вендоров диалоговых платформ на рынке (их оказалось достаточно много) и наш выбор пал на российскую компанию Just AI. Нам понравилось, что у этой компании уже была интеграция со смежной системой роботизации ROBIN RPA. А мы хотели, чтобы наш чат-бот был в связке RPA. 

Второй немаловажный момент: у платформы Just AI был встроенный визуальный no-code редактор J-Graph – интерфейс, с помощью которого можно создавать, просматривать и редактировать диалоговые сценарии. Чем он хорош: если ты не умеешь работать с JavaScript, то в J-Graph плиточками можно создавать дерево сценария. Следовательно, любой сотрудник может создать с помощью J-Graph чат-бота. Поэтому мы пошли по пути платформы самообслуживания – чтобы каждый желающий с помощью неё мог легко и просто создать своего чат-бота. 

То есть мы не хотим замыкать на себе процесс, не хотим разрабатывать за всех сценарии. Мы за то, чтобы каждый сотрудник, у которого появится желание и возможность создать себе чат-бота, мог посмотреть небольшое видеообучение, почитать краткий мануал и воспользоваться нашими наработками для создания своего продукта. Разумеется, все важные и сложные проекты делаем мы на своей стороне: интеграцию с ITSM-системой, сквозную аутентификацию – всё это можно спокойно использовать в других чат-ботах.

Дилемма вторая: жизнь бота внутри ИТ-контура. Умереть и делать интеграцию со всеми монолитными cистемами или делать RPA-сценарии? Решили, что наш бот будет окном входа и интерфейсом для RPA. Наш бот интегрирован с RPA, и это крайне удобно для взаимодействия с конечным пользователем (уточнение данных, вывод информации). 

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

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

Ответ: мы убедились, что no-code заметно ускоряет развитие ботов. 

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

Здесь мы смотрим, с чем бот не справился:

Здесь настраиваются фразы-синонимы:

Бот до обучения:

Бот после обучения:

Как мы подключаем наших чат-ботов

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

Бота можно наделить любым характером – всё зависит от человека, который его наполняет. Он может ему передать эмоции: язык бота может быть дерзким, он может шутить, а может быть сухим и рациональным. Это всё можно сделать на стороне платформы, придать ему свою изюминку, чтобы он немного отличался от других чат-ботов. 

Часто мы обрастаем какими-то новыми фишками, которые изначально не задумывали. Например, у нашего чат-бота теперь есть функция опросника. Мы можем очень быстро врезать в систему опрос, чтобы собрать обратную связь от пользователей по работе системы. Данные аккумулируются у нас в системе, после чего мы присылаем эти ответы в Excel. Вот такая очень быстрая обратная связь получается. 

Сейчас у нас есть три способа подключения чат-ботов. 

Первый: вставка на любой web-ресурс иконки по типу «Скрепки в MS Office» (олды такую помнят точно). Мы предоставляем коллегам  небольшой кусок JS и просим добавить его в body их фронта. Владелец web-ресурса сам прописывает нужные сценарии, и после этого он подгружается в чат-бота. Вуаля – действующий чат-бот появляется у нас в системе. К примеру, именно таким образом мы «врезались» в наш корпоративный инструмент планирования проектов Teamplanner (о нём мы писали здесь).

Второй способ: в такие монолитные системы, как, к примеру, SAP, очень сложно встроить чат-бота. С такими гигантами приходится играть в обходные игры: мы разворачиваем чат-боты на корпоративной системе подачи заявок. Пока сотрудник не пообщается с чат-ботом, он не сможет создать обращение. Чат-бот в большинстве случаев помогает решить проблему в онлайне, а если нет –  автоматически создаст тикет в поддержку.

Третий способ, который появился у нас недавно, – это возможность интеграции с Telegram. Мы проверяем, что пользователь является сотрудником компании и после этого допускаем его в мессенджер. В Telegram он может задать все интересующие его вопросы: там есть кнопки, на которых написано, по каким вопросам он может проконсультироваться у нашего чат-бота.

Кейсы: как используются чат-боты в X5

Алина – наша коллега из HR, очень загорелась идеей создания чат-бота для своего отдела и самостоятельно его сделала. Главное – желание. Вот что в итоге у неё получилось:

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

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

Самый полезный (и самый любимый) наш пример: это интеграция бота с системой, к которой он подключен. В любой крупной компании бывают периоды, когда одно старое ИТ-решение (обычно это монолитная система), заменяется на новое. Нет смысла развивать старое, но в нём могут быть баги или какие-то нелогичные операции. И вот тут бот может использовать API-данной системы или разработанные ранее RPA-сценарии. 

Бывают случаи, когда страдает UX/UI у монолитных систем, по которым нет дальнейшего развития. Пользователи нервничают – создают тикеты в саппорт. За пару дней сотрудники поддержки сами создали RPA-сценарий для того, чтобы выводить актуальные пройденные курсы в чат-бот. И это всё без доработок (регистрации и СМС):

Чем мы отличаемся от других?

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

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

В чём мы немного отстаём – это айдентика. Нам нужно ещё поработать над тем, чтобы чат-бот обрёл своё имя и внешность. Во всём остальном возможности нашего бота намного больше, чем у других. Например, у нас отличная система аналитики, мы можем выкрутить эту статистику в любом разрезе: по диалогам пользователей, по количеству сессий, по количеству созданных обращений в системе и пр. Это даёт нам всевозможные срезы для того, чтобы мы в моменте могли реагировать на те или иные события. 

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

Можно купить коробочное решение и дальше его уже переделывать под себя. Мы так и сделали – мы далеко ушли от той коробки, которая была изначально: например, мы добавили свой дизайн. Мы всегда пытаемся что-то изменить, улучшить, апгрейдить и допилить. 

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

Не без сложностей

Проблемы, конечно, у нас были всегда. Например, когда мы только запустились, самой большой сложностью была аутентификация пользователя через Active Directory (наш любимый логин/пароль при входе в Windows). Мы хотели получить красивую аватарку и знать о пользователе какие-то основные данные, чтобы не спрашивать у него лишний раз рабочую почту, табельный номер и т. д. Мы начали привлекать различных подрядчиков для решения этой задачи, но все крутили у виска и говорили, что это сделать невозможно. 

Но мы верили и в итоге через пару месяцев мы взяли и сделали это сами.

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