Всем привет! На связи Александр Грачев, заместитель директора сервисного центра компании Positive Technologies.
Наша работа — помогать пользователям получать максимальный профит от продуктов Positive Technologies и решать любые возникшие вопросы ?
Возможно, вы помните серию наших предыдущих статей (часть 1, часть 2, часть 3), в которых мы рассказывали о буднях специалистов техподдержки. Сегодня хочется поговорить не про технику, а в целом про подход.
Знаете, вокруг поддержки всегда крайне разные эмоции. Кто-то считает, что она нужна и важна, а кто-то, что в ней мало смысла. Но будем честны: какой бы стабильной ни была инфраструктура, всегда есть администраторы для ее поддержания ?
Вешать ярлыки и оценивать работу других — это не наш метод, расскажу про то, что происходит у нас, внутри Positive Technologies.
Начнем, наверное, с общепринятых подходов.
Мы все каждый день сталкиваемся с работой поддержки. Возьмем любой сервис предоставления услуг, например провайдеров интернета (ведь сложно представить жизнь без него). У них всегда есть несколько линий технической поддержки:
Первая или нулевая линия. Чаще всего эти люди помогают решить основные вопросы и те проблемы, с которыми сталкивается большая часть пользователей. Наверняка у каждого из нас когда-то пропадал интернет. Огоньки на сетевом оборудовании мигали все реже либо другими цветами. Вы перезагружали роутер (как же без классического правила ИТ: семь бед — один ресет!), но это не помогало, вы звонили провайдеру, первая рекомендация — перезагрузите роутер. Почему так? Все просто: сервис предоставляет услуги большому количеству людей, так сложилось исторически, что далеко не все знают, что такое роутер и как его перезагрузить. И именно поэтому так необходима первая линия технической поддержки. Хотя, как вы могли заметить, все чаще автоматизация проникает в нашу жизнь, появляется все больше голосовых или чат-ботов, что на самом деле хорошо, но порой раздражает, когда ты точно знаешь, что бот ничем не может помочь ?
Вторая линия. Вот здесь начинается самое интересное. Кто же эти герои, что не носят плащи? Это технические специалисты, которые могут проанализировать журналы и помочь с проблемой, а именно: запросить нужную информацию, изучить все данные, при необходимости воспроизвести ошибку и найти решение. Те самые технари, которые ковыряются во «внутренностях» оборудования, продуктов, решений и предлагают пути исправления возникшей неполадки.
Третья линия, или экспертная поддержка. Как вы поняли из названия, это высококвалифицированные специалисты, которые имеют узконаправленную и глубокую экспертизу в какой-то области, знают все тонкости и особенности.
Но вам же интересно узнать, что у нас, а не у других, не так ли? Поговорим о нас.
Мы в компании долгое время жили с пониманием, что, если что-то принято, значит, так правильно. Мы использовали классический подход, в котором обязательно должна быть первая линия саппорта. Так ли это хорошо на самом деле? Сложно сказать. Работает ли это так, как было задумано? Да. Приносит ли пользу? В какой-то мере. Но в определенный момент мы столкнулись с тем, что вреда от этого больше, чем пользы. Удивительно, но факт.
Почему же так произошло? Все и везде используют классический подход, у всех все работает, а тут приходим мы и говорим: работает, но не так, как хотелось бы. И здесь напрашивается логичный комментарий: значит, это вы что-то делаете не так. Возможно.
Как же мы пришли к этой, казалось бы, странной идее, что первая линия для наших заказчиков не несет столько пользы, сколько хотелось бы, и почему мы решились на изменения?
Итак, первая линия — это крутые и классные ребята, которые показывают результат и делают важную и нужную работу (по статистике, около половины запросов от наших пользователей решалось специалистами первой линии).
Если все так хорошо, зачем ломать то, что работает? В какой-то момент мы стали собирать обратную связь. Например, клиенты жаловались, что крайне сложно получить быстрое решение, что часто техподдержка запрашивает какие-то новые данные, не собрав сразу все, что нужно. В итоге такая коммуникация приносила больше вреда, чем пользы. Техническая поддержка — это специалисты, с которыми взаимодействует пользователь продукта, решения, услуги, и важно, чтобы первый контакт был комфортным для клиента. Но приведенные выше примеры с перезагрузкой роутера и сложной коммуникацией говорят о том, что такой подход, кажется, вызывает больше отторжения, чем радости. Проанализировав все это, мы решили пересмотреть наши методы и начинаем строить мир заново внедрять другой подход.
К чему мы планируем прийти и почему это важно
Кажется, что классическая первая линия — решение типовых вопросов и работа по скрипту — это не тот уровень, которого ожидают наши пользователи. Когда продукт нацелен на защиту инфраструктуры, нужно быстрое и качественное решение проблемы. В этот момент нет времени на классификацию заявки, неуместно предложение а-ля «перезагружать пробовали?», так как нужен анализ ситуации, а главное — помощь здесь и сейчас.
Так что же мы решили делать? Как часто бывает, решение было где-то рядом, но его было сложно найти. Мы решили изменить подход. Так как наши продукты служат для защиты инфраструктуры, то нужно максимально быстро, эффективно и точно локализовать проблему. А для этого нужно изучать журналы и искать решение (о том, как мы это делаем мы рассказывали ранее). Может ли это сделать первая линия? В классическом ее виде — нет, так как это задача второй линии. Как быть? Нужно обучать людей и делать так, чтобы технические специалисты, которые являются первой точкой контакта, сразу могли запросить нужные данные, изучить их и предложить решение. Иначе мы будем в той ситуации, в которой были не так давно… Первая линия запросила журналы, передала запрос на вторую линию, там специалист после изучения данных понял, что их не хватает, и все пошло по кругу — новый запрос, ожидание, анализ и так далее. Это точно не сокращает время решения — лишь увеличивает.
Мы пересмотрели классическую линейку техподдержки и решили уйти от скриптов, шаблонных ответов и всего того, что должна делать первая линия. Теперь при обращении пользователя специалист не просто соберет данные и передаст запрос дальше, а продолжит работу, будет анализировать журналы и предлагать варианты решения проблемы. То есть все это ведет к тому, что на передовой будут инженеры, которые смогут изучить вопрос и дать ответ, а при необходимости проконсультируются с экспертом, чтобы более глубоко разобраться в причинах возникновения трудности. Зачем все это? Все просто: это нужно для того, чтобы качество и скорость решения проблем росли, а время — сокращалось.
Почему мы это делаем? Когда у вас создана классическая многоуровневая линейка поддержки, что бы вы ни делали, все линии будут автономны. Первая линия выполняет свою работу, вторая — свою, третья — свою, и получается, что механизм работает, шестеренки крутятся, все функционирует. И это правда. Но, как мы видим на практике, не всегда этот механизм выполняет свою функциональность на все 100%. Каждая линия автономна, перекрестное обучение достаточно посредственное, а это может вызвать негатив. Например, ощущение, что на стороне поддержки не люди, которые хотят помочь решить проблему, а роботы, задача которых — дать хоть какой-то ответ, чтобы соблюсти SLA, собрать побольше данных, да и в целом есть ощущение хождения по кругу.
На самом деле во многих сферах классическое разделение на линии работает эффективно, и внедрение другого подхода может привести к проблемам. Например, в случае с провайдером услуг. Можете ли вы представить, чтобы при любом сбое сразу подключался опытный специалист, который пойдет изучать журналы сетевого оборудования, хотя проблема потерянного соединения может быть в обыкновенном отсутствии света? ?
Взаимодействуя с нашими клиентами, мы поняли, что классический подход не так эффективен, как хотелось бы. Ведь клиенты и партнеры получают все больше опыта и навыков внедрения и траблшутинга. При этом первая линия продолжает делать стандартный скрипт-запрос всей возможной информации для более полного изучения ошибки, хотя, возможно, требуется более простой и конкретный ответ.
Мы стираем границу между первой и второй линией, чтобы обеспечить высокий уровень сервиса и чтобы любая проблема решалась как можно быстрее.
Да, это неклассический подход, но мы уверены, что он работает. Тогда почему бы и не использовать его?
Примерно в июле мы начали внедрять новый подход, и, несмотря на то что количество обращений от месяца к месяцу все больше, нам удается сокращать время решения запросов. Да, пока результаты могут показаться незначительными, но мы ведь только начали ?
Будем пробовать развиваться в этом направлении, а именно — обогащать наш опыт взаимодействия с пользователями для максимально комфортного сотрудничества.
Спасибо за внимание!
Александр Грачев
Заместитель директора сервисного центра, Positive Technologies
Комментарии (7)
AndreyYu
21.11.2024 10:13Из текста так и не понятно чем л1 тогда отличается от л1 сейчас, ведь она до сих пор " продолжает делать стандартный скрипт-запрос".
В чем стерта грань между л1 и л2, т.к. не понятно что делала л2.
ptsecurity Автор
21.11.2024 10:13Спасибо за внимание к статье и вопрос. При изначальном подходе первая линия собирала данные, решала типовые проблемы, а в ином случае отдавала запрос дальше, где уже вторая линия начинала анализ, а это затягивало срок решения. Теперь инженер, который взял запрос, продолжает анализ, консультируясь (при необходимости) внутри команды и только в особо тяжелых случаях будет передавать запрос на эксперта внутри команды. Что должно сокращать время решения обращений и улучшать качество их обработки.
Duxlab
21.11.2024 10:13Штош. Не зря хвастаетесь. Первая линия многих бесит, особенно боты и совершенно неквалифицированные люди со скриптами.
Первая линия таки нужна, особенно если большинство пользователей абсолютно неквалифицированные и даже формулировать не умеют. НО нужна возможность быстрого перехода к специалисту.
> Каждая линия автономна
Это ключевая проблема. Порой слишком автономна.
Прмер из жизни. Первая линия просит инфу, я даю, меня переводят на вторую линию и она снова то же самое спрашивает.
После многократной(!) ругани уже с другими людьми эту проблему устранили.
Вторая проблема — старательность. Первая линия всегда стремится отработать и хуже всего, если это чатбот. Когда сходу я говорю что-то типа «здравствуйте, по вашему скрипту всё сделал, не помогло, дайте специалиста пожалуйста, в прошлый раз он помог, проблема скорее всего в …» — человек может сразу перевести куда надо. Бот же не поймёт и будет мурыжить. Лишь раз встречал бота, у которого вместо старательности была вшита однозначная реакция «ЯННП = зову человека».
Проблема третья. У техподдержки нет никакой пометки, кто есть кто, типа «этот номер — опытный пользователь, а вот этот — старушка, которой поговорить не с кем». Нет, не все равны, особенно если подтверждается пометка. Реальный пример. У человека лютое нарушение речи и поражённые суставы. Башка варит исправно. В начале разговора ему приходится включать запись, объясняющую всё это. Затем запись обращения. Очевидно, что техподдержка должна быть готова формулировать вопросы так, чтобы человек мог коротко ответить да/нет или набором типовых слов, которые под рукой в синтезаторе. И было бы неплохо пропустить вступление в духе «Здравствуйте, это Имярек? Мы помним о вашей проблеме, можете сразу начать с обращения».
В целом, в условиях современности, возможно сделать автоматизированную систему, которая отлично заменит первую линию. Но почти никто и никогда не делает: почему-то считают, что нужно упереться в однообразный продукт и этого хватит: строго нейрочатбот или обычное FAQ с оглавлением, даже без поиска блин или с поиском без синонимов/ассоциаций. Особенно какая-то нелепая вера во всесилие нейронок или попытка прокачать их так, чтобы прям всё заменяли.
На деле же без набора инструментов и грамотного дизайна поверх и увязывания компонентов воедино — не обойтись.
ED-209
21.11.2024 10:13Фундаментально всё зависит кого поддерживать. Юр лица или физ лица.
В первом случае: "Здравствуйте уважаемый господин сисадмин A, пишет Вам сисадмин B из компании C. Проблема такая-то, логи собрал, прикладываю к письму..."
А со вторым случаем лучше вообще не связываться.
il_l
Не совсем понимаю последний график. Что показывают проценты?
Duxlab
Среднее время решения вопроса. Начальное взяли за 100%, стало 82%
То есть скорость решения повысилась в 1,22 раза, ну или время решения сократилось на 18%
DevFx
«Грёбаное лассо» от Джонни Кэтсвилла.