Тема выпуска и знакомство с докладчиком

Народ, всем привет! Сегодня у нас 4 выпуск рубрики «Открытый микрофон», где каждый желающий подписчик нашего телеграм-канала может прийти в прямой эфир и зачитать свою презентацию, которая основана на какой-то практике, которую он получил, проекте, либо новых полученных знаниях. Сегодня у нас в качестве спикера ведущий аналитик Sportmaster Lab Ваня Хахарев. О чем будешь нам сегодня рассказывать?

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

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

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

Служба поддержки. Кто это? Что это? Зачем это?

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

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

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

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

Начало работы службы поддержки и как появляются типовые инциденты

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

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

Что происходит дальше? В какой-то момент ты достаточно быстро набираешь эту информацию, за месяц точно. А дальше твой стартовый запрос начинает делиться на «О, это что-то новенькое» или «я это уже где-то видел». Соответственно, «что-то новенькое» - все понятно, решаем, учимся, копаемся, раскручиваем. А «я это уже где-то видел» - хочется структурировать. Поначалу я себе в блокноте записывал ответы, составлял наряды, подписывал в каком наряде что решалось подобное, анализировал.

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

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

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

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

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

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

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

Старые привычки и F.A.Q.

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

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

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

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

Родилась идея попробовать сделать FAQ, но для поддержки. Мы сделали такого аккордеонного формата плагин, который делался на стандартных конфлюенсовских плагинах UI Expand. И каждый Expand мы называли определенным вопросом. Внутрь него вкладывали либо такой же экспанд, либо в результате какой-то типовой инцидент, прям вот отдельный кусочек. Таким образом удавалось добираться до конкретного типового инцидента, максимум двух.

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

Получилось, конечно, не сразу у нас с этим FAQ. Что мы имеем на текущий момент? У нас служба поддержки из трех линий. Первая - парсер входящих писем, вторая поддержка – РФ с горячей линией, с приоритетом на наш продукт. Третья - аналитики системы.

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

Первые полезные отчетности

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

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

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

Почему так долго что-то висело? Время активной работы наших пользователей было с 4:00 утра до 14:00 по Москве. А время работы наших линий было с 9:00 до 18:00 и с 10:00 до 19:00.

Мы явно не перекрывали раннее утро. Что делать с этим? Мы попросили нам сделать вторую линию со стороны Китая, и пошли в умное назначение и переназначение. Таким образом,  на входе у нас появилась функция назначения и две вторые линии, которые внутри себя еще имеют переназначение. Когда приходила заявка, у нас теперь был выбор. У нас есть китайская линия, которая работает с 4:00 до 14:00. От горячей линии нам была предоставлена и российская линия. Мы видели, какие у нас есть временные промежутки.

Но мы же понимаем, что промежутки 9:00-18:00 и 4:00-14:00 явно имеют пересечение. Функция назначения начинала проверять страну отправителя.

Всё вычислили, всё перегрузили, всё перезавели и всем назначили страну. У нас был справочник всех наших пользователей с правильной страной, где они находятся: РФ/не РФ и Китай/не Китай. Сначала проверяешь, от кого пришёл запрос, допустим, от китайского пользователя. Если ты видишь, что китайская служба поддержки еще работает во второй линии, супер. И после этого мы еще и проверяли, нет ли праздников в стране. И если праздников нет, то мы назначали сюда. Если праздник есть, то уж извините, подождет полдня, но когда выйдет вторая линия, она разберется. Это как бы меньшее из зол.

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

Представьте, что у нас есть наряд на китайскую линию, который создался в 5:00. Он создал вложенный наряд на третью линию, а заканчиваем решать наряд в 15:30. Были пользователи, которые работали допоздна. Но я напоминаю, что мы-то закроем свой наряд, эта информация уйдет во второй, и только он будет общаться с пользователем, закрывать свою часть и отправлять ее пользователю как решение. Но эти ребята закончили работать, они придут только завтра в 4 утра, а нам бы хорошо пользователям ответить раньше.

Определение дубликатов и статистика по не типовым инцидентам

В данном случае по триггеру закрытие третьего наряда запускалась функция переназначения, и если для инцидента назначенной должна становиться та же группа, которая сейчас есть, все оставалось как есть. Если другая, то он переназначал. И просто перекидывал группу внутри наряда, назначал на другой, и сбрасывал исполнителя, чтобы он подсветился как новый. Достаточно быстро себе ускорили работу с обратной коммуникацией. И мы ответили пользователя не на следующий день, а в этот. С дубликатами мы пошли очень просто. Мы просили сделать нам функцию проверки в нескольких параметрах. Отправитель сообщения тот же/не тот же, тема сообщения, из которой вырезаны все префиксы re, fv.

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

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

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

Переназначение в разы ускорило процесс закрытия. Отлов дубликатов снял нагрузку со второй линии прилично, 15%. Вторая линия со стороны Китая покрыла нам временно линии. Также мы могли работать оперативно по всему промежутку времени работы с пользователями.

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

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

Про коммуникацию с пользователем

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

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

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

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

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

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

Бонусы от созданной службы поддержки

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

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

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

Вот здесь как раз мы уже выгрузили счетчики, детализация уже была не нужна. А вот счетчики – это было интересно. Посмотрели на счетчики, а там - один из типовых инцидентов 184 раза стрелял в месяц. Ну, с этим явно нужно было что-то делать. Мы сели командой, собрали все проблемы, структурировали все, что мы получили в этом BI-отчете, и разделили их на три группы: бизнес-проблема, техническое решение или исправим за счет UX/UI.

Это всё просто в разы улучшило качество реинжиниринга, который мы сделали. Половину проблем мы четко решили за счет просто качественного UX/UI. Локализация на трех языках, которую мы добавили, в частности решала часть из них, потому что подсказки стали правильными, понятными, локализованными, и люди вообще понимали, что пошло не так, и что им надо сделать.

Технические решения мы тоже их пересмотрели совместно с UX/UI, то есть мы какие-то функционалы просто переделали полностью. Далее – бизнес-проблема. Приведу пример. У нас было до 180 действительных заявок о том, что просто поменяйте мне маршрут, нажмите на кнопку. Но было ограничение, пользователь не может это делать сам. И только потом до нас дошло, что мы на самом деле ни разу не преподнесли бизнес-заказчику правильное решение, как это может быть исправлено по-другому вообще, как это сделать хорошо. Помимо этого будет решена еще большая нагрузка с поддержкой. Мы пришли с хорошим UX-решением – дополнительной кнопкой. Никакого свободного решения у пользователей не будет. Все будет также работать через внешнюю систему, через внешние данные, но просто кнопка будет ему доступна. Решение всем понравилось, мы ее внедрили. У нас ушло 184 обращения типовых инцидентов в месяц со второй линии. Мы сняли эту нагрузку просто за счет качественной службы поддержки, качественного BI-отчета и последующей аналитики. Еще раз хочу показать вам схему и наверное сказать, что вот что у нас получилось в конце. Мы решали конкретную задачу.

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

Вопросы от ведущего и зрителей

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

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

Откуда изначально был запрос? У вас есть пользователь со средним уровнем владения ПК, а может быть и даже пониже. Ему дают сайт и потом с ним на английском языке 3 часа проводят лекцию, как на этом сайте работают. Вы думаете, сколько вы запомните из этой лекции? Я запомнил, как зайти на сайт и пару кнопок. А когда через 3 дня мне надо было что-то в нем сделать, я не помнил ничего. То есть, как минимум, изначально это живая инструкция, пока ее нет. Очень часто, когда пилот запускается быстро, и нужно понять, взлетит или не взлетит, никто не пишет инструкции. Вот там был огромный томник, 85 страниц, который не осилил практически никто.  

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

Тогда я к большинству вещей не был готов. А еще я хочу отметить, что я недавно пришел в команду. У нас был такой случай, как мы сделали автоответ на спам, а у ящика пользователя стояла рассылка при входе. Знаешь, как вот это «I'm out of office, если мне сюда пишете». И он нам писал, мы ему ответили в автоответ, что «твой наряд закрыт». Он нам писал «с Новым годом! Я на отдыхе». Мы ему снова пишем «знаешь, твой наряд закрыт, не пиши нам», а он снова пишет «я на отдыхе». И у нас пошел такой цикл, количество тикетов было большое. Автоответ вот так сработал.

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

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

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

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

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

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

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

Чем чаще ты отвечаешь на вопросы, тем больше ты понимаешь принцип, как пользователь работает, как сделана система, чтобы он в ней работал. Мы начали делать инструкции, FAQ раздел. Но в инструкцию мы хотели впилить схему бизнес-процесса для поставщика. Как он должен вообще здесь работать. То есть он заходит в инструкцию, ему сразу такая плашка, вот смотри, с учетом твоих возможностей, которые тебе выданы на сайте, ты делаешь вот эти вещи, делаешь их вот в такой последовательности, заходишь туда и туда. То же самое, соответственно, видела и вторая линия. Мы проводили регулярное обучение, рассказывали, почему они делают, чем это делают все эти бизнес-процессы. Это как бы must-have. Вот именно в нашей системе по-другому не работает. Просто сидеть и как бы по пунктикам что-то делать вообще плохо для показателей, плохо для понимания и вероятность ошибки велика.

А какие у вас сейчас метрики? Что вы измеряете? Ну, не конкретные слова, да, а вот именно срезы. На что вы смотрите сегодня?

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

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

До четвертой линии, до нас доходило вообще копейки, это нормально, это рабочая история с учетом, что выкатывали обновления. Если было очень много типовых - почему, какие? Смотрим детализацию. Оказывается, что там и дубликаты снова стреляли, либо спам какой-то пролез, снова его надо почистить. Либо была какая-то проблема, которую почему-то решили на второй линии, но она добралась до третьей только на пятый раз. Постоянно отвечали неправильно. Мы ее потом починили, но потом разбирали. И был, конечно, разбор полетов.

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

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

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

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

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

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

В презентации инцидент рассматривается как некая сущность в системе тикетов, а не как определение события. В нашей практике техническая поддержка занимается не только решением инцидентов, но и выполняет запросы на облуживание/доступ. Важно отметить, что все эти события имеют разный SLA: инцидент – условное «тушение пожара», в то время как запрос на обслуживание/доступ может пройти различные этапы верификации (обоснование, согласование и т.д.). Далеко не каждое обращение можно категоризировать как инцидент, а приведение всех обращений к единой категории (инцидент) может привести к проблемам, связанным с приоритезацией решений этих самых запросов: например, когда явный инцидент будет решаться в порядке очереди после «скрытого» запроса на обслуживание. В том числе и поэтому по большей части информационных систем функцию первой линий технической поддержки выполняют операторы, которые на своём уровне занимаются категоризацией, маршрутизацией обращений, проверкой на дубликаты, запросом дополнительной информации у пользователей, а в случае наличия необходимых компетенций – консультацией пользователя и закрытия обращения на своей стороне (что, как минимум, снижает нагрузку на вторую линию).

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

Несколько вопросов по презентации, которые остались открытыми после её просмотра:

1. В ходе презентации было явно сказано, что большая часть пользователей находится в Китае и имеет другой часовой пояс, в отличие от РФ. Почему изначально не была включена вторая линия на стороне Китая при условии установленного SLA в 1 час?

2. Почему в презентации вторая линия указана как RU и CH, а третья как РФ?

В целом, все хорошо получилось выстроить, особенно если это b2c. Я имела отношение только к b2b поддержке, поэтому некоторые моменты мне показались сомнительными или неприменимыми к моей практике, но, вероятно, это как раз из-за разных сегментов. Например, мы организовывали прием обращений не через почту, а создавали преднастроенную форму в таск-трекере и выдавали доступ на ее заполнение 3-5 ответственным участникам со стороны каждого заказчика (в зависимости от количества пользователей).

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

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

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

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

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

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

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

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

Всё, о чём говорит спикер, применимо в реальной практике.

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

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

В качестве базы о донесении текстовой информации до клиента чётко и ёмко порекомендовал бы книгу «Пиши, сокращай».