Возможно и то, и другое

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

«В конце концов, вы можете почувствовать себя роботом, что вполне понятно, поскольку вы написали один и тот же ответ 17 раз».

Позже автор предупреждает:

«Когда вы получаете похожие запросы, возникает соблазн создать шаблонные ответы. НЕ ДЕЛАЙТЕ ЭТО ".

База знаний в виде макросов

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

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

Предлагаемые ответы

Одно дело, конечно, написать в компанию вопрос, не описанный в их справочном центре, и получить готовый ответ, который не только не отвечает на ваш вопрос, но и не учитывает ваше время или инвестиции как пользователя. Но как насчет того, когда готовые ответы («макросы») работают?

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

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

Предлагаемые действия

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

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

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

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

Итак, сколько сочувствия требуется, чтобы ответить на такой билет:

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

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

Сортировка и анализ

Если бы мы применили стандартную обработку естественного языка (NLP) и машинное обучение (ML) ко всем входящим билетам, то первым делом было бы применить оценки достоверности к билетам и отсортировать их по стопкам или сегментам (сортировка) на основе вероятных путь к разрешению.

В одной корзине у вас будут заявки, например, с показателем достоверности 80% + с помощью анализа NLP / ML, который можно решить, просто сославшись на существующую информацию - будь то из справочного центра или из макроса. Я называю это простыми решениями. Они закрываются в одно касание и полностью отвечают потребностям пользователя. Агент просто просматривает их, проверяет, уместен ли предложенный ответ, исправляет его, если нет, и при необходимости персонализирует. Каждый раз, когда они это делают, алгоритм будет обучать алгоритм лучше и увереннее отвечать на следующий набор аналогичных вопросов.

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

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

Но что, если бы мы пошли дальше?

Более детальный анализ заявок

По большей части я отказался от использования полных автономных макросов, за исключением тех случаев, когда они идеально подходят для ситуации. (Их действительно надоедает применять снова и снова, я признаю) Вместо этого я обычно смешиваю пользовательский текст с использованием сокращателя текста, в данном случае программы под названием Atext, чтобы быстро вводить общие фразы и предложения. обычно с помощью трехбуквенных комбинаций клавиш. Когда программа обнаруживает эти нажатия клавиш, она заменяет их моей полной строкой текста. Примеры, которые я использую каждый день, включают загадочные коды, такие как hix или sorx, pax, fex или chx.

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

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

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

В описанном выше варианте использования у нас есть 100% -ная степень уверенности в том, что это первый ответ агента в заданном потоке заявки. Нажатие кнопки «Привет, спасибо, что связались с нами» немедленно добавляет этот текстовый блок к ответу агента. И так далее на «Мне жаль это слышать» и «Чем я могу помочь сегодня?» Опять же, каждое включение предложенного текста способствует обучению и совершенствованию алгоритма машинного обучения в следующий раз.

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

Мультисенсорные билеты и процедуры поиска и устранения неисправностей

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

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

Например:

  • На каком браузере, ОС и устройстве возникла проблема?

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

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

I see you're having a problem with [__________]. To better solve your help request, please respond with the following information:
- Your operating system
- Your browser & version
- Your device model
- Are you using any Adblockers? 
- Does the problem persist if you switch browsers?

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

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

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

Вывод

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