Русский
Русский
English
Статистика
Реклама

Служба поддержки

Найти 15 инженеров за две недели карантина

01.10.2020 12:15:50 | Автор: admin
Привет, Хабр!

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

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

Сегодня расскажу, как мы с коллегой Александрой искали лучших инженеров на расстоянии и, самое главное, нашли.



Что было до: групповой отбор, экскурсии, экзамен

Раньше все дежурные инженеры перед подписанием договора проходили отбор в 2 этапа: групповое собеседование и вводное обучение.

На групповое собеседование мы приглашали 1215 человек. Кандидаты знакомились с компанией и будущими коллегами, а потом решали несколько кейсов. В мире ИТ многие скептически относятся к таким собеседованиям. Но для нас формат полезен по трем причинам:
  • Мы быстрее находим нужное количество своих. Это стартовая позиция: набираем сразу по 510 человек среди студентов и выпускников технических вузов. Меньше смотрим на резюме с опытом работы, больше оцениваем мотивацию и интерес к нашей сфере.
  • На примере кейсов кандидаты примеряют роль на себя. Каждый получает ситуацию из жизни и проигрывает ее в группе. Сразу понятно: теряется человек или нет, комфортно ли ему взаимодействовать с разными людьми.
  • Из новичков формируется самостоятельная команда дежурных. Все знакомятся еще на отборе и быстрее адаптируются, появляется взаимная поддержка и дух соревнования.

Собеседование занимало 6 часов почти целый рабочий день. Но в результате сразу набиралась готовая группа на обучение.

Вводное обучение длилось 3 дня. Мы проводили экскурсию по дата-центру, знакомили с обязанностями дежурного инженера и давали практические задания, например, подключить оборудование. Будущие инженеры могли проявить себя в деле и проверить мое-не мое.
В конце кандидаты сдавали экзамен по теории и практике. Если результат не менее 70% от максимального количества баллов добро пожаловать на оплачиваемую стажировку. К обучению подключали руководителей отделов: так можно сразу найти интересных кандидатов в одну из смежных технических групп.

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

Какие сюрпризы принес 2020


Долгий режим ожидания

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

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

Индивидуальные собеседования мы не рассматривали: это бы в несколько раз увеличило объем работы у руководителей, специалистов HR-службы и преподавателей курса.

Первый онлайн-набор: неразбериха вместо кейсов

В июне мы объявили новый набор дежурных инженеров в онлайне. Собеседование запланировали в Cisco Webex: мы используем эту систему для удаленных совещаний внутри компании. Как это выглядело в нашей голове:
  1. Приглашаем от 20 до 30 человек на групповое собеседование. Всем кандидатам уходит письмо со ссылкой на виртуальную комнату Webex.
  2. Проводим презентацию компании и знакомимся с участниками.
  3. Просим кандидатов разделиться по виртуальным комнатам коллег и решаем кейсы в группах по 4-6 человек.

Реальность подвела. Знакомство с кандидатами в общей комнате затянулось. Чтобы выслушать 25 человек подряд со всеми техническими накладками потребовалось больше часа. К концу собеседования мы уже с трудом воспринимали информацию.

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

Хорошей находкой для таких оргмоментов стал Telegram. Мы заранее добавляли номера кандидатов в контакты для быстрой связи. Для кейсов мы вывесили в общий чат списки кандидатов по комнатам: Вы заходите по ссылке в комнату Екатерины, вы оставайтесь в комнате Александры. Но все равно люди путались, терялись, подключались не туда.

Чат пригодился и на вводном обучении. Преподаватель проводил занятие в Webex и отправлял в Telegram записи лекций и дополнительные материалы, отвечал на вопросы. Экскурсию по ЦОДу заменили на видеотур и сэкономили день обучения. Конечно, получилось не так живо, как на экскурсии. Зато можно перейти по ссылкам и посмотреть в удобное время.

Финальный экзамен проводили в Webex. Старший инженер площадки оставался в своей персональной комнате, а 15 человек подключались по очереди. Без накладок тоже не обошлось. У всех новичков была одна и та же ссылка если перепутаешь время, попадешь на чужой экзамен. Для экзаменатора нагрузка была высокой. В какой-то момент наш Антон даже стал радоваться прогульщикам.

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

Второй онлайн-набор: безличные квадратики

В июле мы проанализировали наш опыт и кое-что улучшили:
  • подключили к набору больше наших сотрудников, чтобы сделать несколько потоков на собеседовании и обучении.
  • сменили площадку и перешли на корпоративный аккаунт в Zoom. Там было удобнее одной кнопкой делить кандидатов на 4-5 сессионных залов.

Так мы сразу сократили время онлайн-собеседования с 4 часов до 2.

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

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

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

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

Во второй раз все прошло быстрее: мы объявили набор 10 июля, а уже 27 июля к нам на стажировку вышли пятеро инженеров. В третий набор за 2 недели удалось принять уже 15 дежурных инженеров.

Что из этого получилось


  1. Меньше времени на отбор. Время собеседования мы сократили с 6 часов в офлайне до 2 часов в Zoome. Сроки обучения уменьшились с 3 дней до 2.
  2. Формат удобнее для кандидатов. Не нужно тратить время на дорогу и освобождать несколько дней на прохождение всех этапов. Стало проще вписывать собеседования и занятия в расписание. Особенно были довольны те, кто уже работал и хотел перейти к нам.
  3. Больше людей доходят до конца обучения. Если раньше на курс приходило 13 человек из 20 приглашенных, то в онлайне не приходит всего пара человек. Даже если время обучения неудобное, можно посмотреть в записи, подготовиться за выходные и сдать экзамен.

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


Ответ на оффер от кандидата.

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

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

Из песочницы 12 заблуждений об игровом саппорте, которые вредят игрокам

21.11.2020 16:12:42 | Автор: admin
Привет, Хабр! Представляю вашему вниманию перевод статьи 12 Persistent and Harmful Misconceptions that Hurt the Player Experience автора Pascal Debroek.



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

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

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

1) Кто угодно может быть специалистом или руководителем службы поддержки игроков


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



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

2) Саппорта на английском языке достаточно


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

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

3) ИИ (скоро) заменит людей


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

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

4) Довольные игроки = Лояльные игроки


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

5) Мнения и отчеты важны только в больших цифрах


В какой момент вы предупреждаете команду об отрицательном отзыве или сообщениях о возможном ошибочном поведении? Жалуется только 1 из 26 недовольных клиентов. Остальные уходят. Отсутствие обратной связи не является признаком удовлетворения игрока. Безразличие убивает бизнес.

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

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



6) Радуйте игроков подарками


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

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

7) Улучшение сервиса за счет найма


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

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

8) Поддержка игроков должна быть максимально быстрой


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

9) Качество саппорта зависит от правил и политики компании


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

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



10) Саппорт практически не требует технических ресурсов


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

  • CRM-софт. Позволяет получать, классифицировать и отвечать на сообщения игроков. Современный CRM часто включает в себя автоматизированные функции, управление рабочим процессом, машинное обучение и функции аналитики (и это еще не все). Многие из них предлагают решения для поддержки в приложениях (интеграция через SDK), которые лучше всего подходят для мобильных игровых студий и интегрируются с различными каналами. Интеграция, новые функции и регулярное обслуживание требуют технических знаний.
  • Портал администрирования: они позволяют специалистам саппорта управлять или искать профилем игрока для решения запроса. Большинство из них представляют собой визуальное представление данных профиля с добавленным к ним слоем функций. Они позволят связывать учетные записи с идентификаторами, управлять счетами или внутриигровыми ресурсами, сбрасывать прогресс игрока и так далее. Здесь постоянно требуются технические знания, поскольку новые игровые фичи часто требуют новых административных функций. Ни при каких обстоятельствах вы не захотите, чтобы кто-либо напрямую управлял необработанным JSON-файлом.

В зависимости от ваших потребностей (и размера/ресурсов студии) существует множество дополнительных инструментов, которые вы можете использовать для улучшения саппорта. Если у вас есть внутриигровой чат, убедитесь, что у вас установлена программа для модерации. Программное обеспечение для управления проектами или работой часто требуется для отслеживания задач и проблем. А если вы хотите доказать окупаемость инвестиций (ROI) вашего отдела поддержки, то получите ресурсы для интеграции ваших данных с данными Business Intelligence.



11) Отзывы игроков это негатив и жалобы


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

  • Отзывы игроков: процесс получения мнения игрока о вашей студии, игре или конкретной функции. Это может быть как похвала, так и критика.
  • Жалобы игроков: процесс получения отчетов от игроков о нарушениях их взаимодействия с вашей студией, игрой или конкретной функцией. Это может быть что угодно: от позиции вашей компании до токсичного поведения или сообщений об ошибках.
  • Запросы поддержки игроков: процесс получения отчетов от игроков, которым требуется помощь по вопросам, связанным с вашей студией, игрой или функцией. Здесь вы найдете свои запросы GDPR, дела по восстановлению аккаунта, практические вопросы и многое другое.

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

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

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



12) Только саппорт несет ответственность за удовлетворенность игроков


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

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

Как роботизировать техподдержку с помощью машинного обучения

06.10.2020 10:05:04 | Автор: admin

Служба техподдержки в крупной компании обычно обслуживает целый зоопарк сервисов, например: пару виртуальных АТС, онлайн-магазин, умный дом и охранную систему в придачу. У ребят всегда есть работа тысячи звонков с сотнями проблем от подключения новых телефонных номеров, до отвалившихся IP-камер.

Чтобы упростить работу техподдержки, команда из нашего акселератора разработала автоматизированную систему на базе машинного обучения. Она запускается за 2 дня без подготовки и без помощи специалистов по data science.

Меня зовут Екатерина Мелькова, я тимлид группы продуктовых инноваций в КРОК. Сегодня мы с разработчиками расскажем, как AutoFAQ автоматизирует клиентскую и техническую поддержку.

Тысячи проблем и как их решить

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

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

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

Затем нужно интегрировать бота с helpdesk и корпоративными сервисами и надеяться, что все это будет хорошо работать.

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

Без обучения ты просто бесполезен!Без обучения ты просто бесполезен!

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

С этой мыслью мы разработали единую систему обработки обращений для совместной работы людей и алгоритмов. Она получила название AutoFAQ, потому что для запуска не нужны обучающие выборки и долгая подготовка, достаточно FAQ с сайта компании.

UI и почему это не главное

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

С виду AutoFAQ напоминает стандартный helpdesk со списком тикетов, разделением по тематикам вопросов, очередями и окном чата. Из этого же интерфейса доступна история переписки, дашборды, отчетность.

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

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

Возможности чат-бота

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

Классификатор намерений определяет, в чем состоит вопрос, к какой базе знаний обратиться, и какая запись в базе содержит подходящий ответ.

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

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

Допустим, клиент пишет: у меня интернет отваливается или камера барахлит, тогда бот вызывает соответствующий сценарий решения проблемы.

Через подключенные интеграции он идентифицирует пользователя и проверяет подключение к камере.

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

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

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

Сценарии и интеграции

C помощью AutoFAQ можно автоматизировать многоступенчатые сценарии решения проблем.

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

Сценарии могут взаимодействовать с REST и SOAP сервисами. Через них можно формировать SQL запросы. Из коробки поддерживаются MS SQL Server, PostrgreSQL, MySQL и MariaDB. Чтобы реализовать сложную логику, в сценарии можно встроить произвольный JavaScript-код.

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

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

Чат-бот и операторы

Конечно, наш бот не идеален и порой не понимает клиентов. Если он не уверен в ответе, и никакие уточняющие вопросы не помогают, система переводит запрос на оператора.

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

Чтобы в дело вступил бот, нужно кликнуть на подсказкуЧтобы в дело вступил бот, нужно кликнуть на подсказку

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

Под капотом

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

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

Чтобы система работала из коробки, мы использовали нейронную сеть, предобученную на наших исследовательских проектах. Она отвечает за общение с клиентами службы поддержки, пока AutoFAQ не соберет данные на практике.

Это позволяет запускать AutoFAQ в работу с минимальной подготовкой и сразу получать хорошее понимание вопросов. Благодаря предобученной сетке бот понимает вопросы, сформулированные совершенно иначе, чем в примерах. Поэтому он нетребователен к объему и качеству обучающей выборки.

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

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

Обучение на практике

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

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

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

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

Ответ оператора попадает в реестр рекомендаций. Затем администратор системы просматривает реестр, отбирает и группирует удачные рекомендации и нажатием одной кнопки вносит их в базу знаний.

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

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

Как только AutoFAQ накапливает достаточный объем данных, предобученный алгоритм отключается, пайплайн перестраивается, и в дело вступают модели, использующие обучение с учителем. Мы заранее не знаем, какой метод будет лучше справляться с данными клиента, поэтому встроили в AutoFAQ сразу несколько алгоритмов: от простых TF-IDF, до BERT и LASER.

Система проверяет объем и сбалансированность обучающей выборки. В зависимости от результатов формируется новый программный конвейер, подбираются алгоритмы и гиперпараметры.

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

На практике, в AutoFAQ часто строятся ансамбли из нескольких алгоритмов. Система постоянно сравнивает их результаты по внутренним метрикам и выдает на выход наиболее уверенные ответы.

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

Запуск AutoFAQ

Мы разбили AutoFAQ на микросервисы и упаковали в докер. Система не требует подключения к сторонним сервисам и работает в изолированной среде. Все ее компоненты дублируются. Они либо работают параллельно, либо запускаются по мере надобности.

Мы рассматривали Kubernetes, но оказалось, что для оркестрации нам хватает Docker Compose. Он упрощает процесс развертывания и не требует kubernetes-кластера.

В результате

AutoFAQ разворачивается за пару часов, подключается к практически любым текстовым каналам коммуникации от электронной почты до Slack и Skype for business. После этого система готова к работе понимает письменную речь, начинает обрабатывать запросы в службу поддержки и накапливать базы знаний.

Чем больше обращений поступает в службу поддержки, тем лучше система их понимает и тем больше задач берет на себя. За 12 месяца AutoFAQ наполняет базу знаний, и автоматизация запускается в полную силу. Как правило, AutoFAQ решает порядка 45% обращений без помощи людей.

Система не заменяет операторов, но избавляет их от большинства рутинных запросов. У сотрудников службы поддержки появляется время на тщательный разбор сложных обращений.

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

Все это хорошо отражается на качестве поддержки. Уровень удовлетворенности клиентов у наших заказчиков в среднем не падает ниже 4 из 5 баллов. Но это уже заслуга сотрудников поддержки. Они настраивают новые интеграции, пополняют базы ответами на редкие вопросы и редактируют формулировки. Мы лишь разработали для них новый инструмент.

P.S. Если у вас остались вопросы по AutoFAQ, оставляйте их в комментариях или пишите на почту: EMelkova@croc.ru.

Подробнее..

Категории

Последние комментарии

  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru