Как создать службу технической поддержки на сайте и организовать её работу

Как создать службу технической поддержки на сайте и организовать её работу

Подтверждают, что заявка получена

Вы бы удивились, узнав, насколько непонятными были некоторые подтверждения о получении заявки. Такое сообщение, как «ваша заявка была отправлена» о многом не говорит. Означает ли оно, что кто-то рассмотрит проблему? Своевременно ли доставляются заявки?

Конкретный пример: платёжный сервис Stripe.

В уведомлении о подтверждении получения заявки не нужно давать лишнюю информацию. Сразу приступайте к сути. Отличным примером является уведомление от сервиса Stripe. Как вы видите, всё просто, понятно и по делу.

Спасибо, что обратились к нам.

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

Ваш Stripe

Что (не) может (знать) спрашивать банк?

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

Итак, что знает банк, вернее сотрудник его клиентского отдела? ФИО клиента, паспортные данные, номер карты (счета), данные об операциях по ним, кодовое слово для блокирования карты, логин (но не пароль!) от приложения клиент-банк, контактную информацию, которая была сообщена клиентом. Последнее важно: если вы не сообщали банку номер мобильного, вероятность звонка на него из банка стремится к нулю.

Чего банк не знает и, соответственно, чего не может спрашивать его сотрудник?

PIN – 4 или более цифр, вручаемых банком вместе с картой в непрозрачном конверте. Служит для авторизации карты при пользовании банкоматом или платежным терминалом, т.е. используется только в реале!

CVV2 (Visa) или CVC2 (MasterCard) – обычно это 3 цифры на обратной стороне карточки (бывает и 4 цифры, и на лицевой, и называются по-другому – зависит от платежной системы и типа карты). Служат для совершения платежей картой в Интернете и больше нигде!

«Одноразовый» пароль – бессмысленный набор букв и/или цифр. Посылается банком в SMS или выдается в виде набора распечатанных паролей под защитным слоем или генерируется специальным девайсом, выдаваемым банком. Требуется для авторизации операции по карте или счету через клиент-банк. (На самом деле эти пароли иногда могут спрашивать при личном визите в офис банка для совершения там определенных операций).

Пароль от клиент-банка – придуманный вами набор знаков, для авторизации на сайте Интернет-банка, банковского приложения на смартфоне и т.п.

Трудно поверить, но это так: ничего из перечисленного сотрудники банка не знают. Что банк не может спрашивать у клиента в принципе – разобрались, а вот что может – зависит от того, кто кому звонит.

Вариант 1: банк звонит клиенту. На самом деле относительно редкий случай, потому что «вас много, а я один», да к тому же юридически значимые действия по телефонному звонку – как-то не. Обычно спрашивают лишь, является ли собеседник тем самым клиентом, чей телефон есть у банка, и верят на слово.

То есть ситуация: Дорогой клиент, у вас подозрительные операции по карте и мы ее заблокируем, если срочно (!!!!!) не подтвердите, что они не подозрительные, а потом еще придется перевыпускать карту за 100500 рублей – возможен, только звонка не будет, банк ее молча заблокирует, а звонить и выяснять чтозанах придется клиенту. Это нормально ©

Другая ситуация: Здрасьте, Марьиванна, это Ваш банк, нам надо уточнить Вашу фамилию – 100% звонят мошенники. Банк фамилию Марьиванны прекрасно знает и ничего ему «уточнять» не надо, тем более по телефону. В крайнем случае – пригласят зайти с паспортом в отделение, а до тех пор заблокируют счета. Потому что у банка над душой стоит Центробанк и прочие контрольно-надзорные вплоть до ФСБ, которым объяснение: Нам же тетка по телефону сказала, что она по мужу не Завгаева, в Сирии никогда не была и в ООО «ИГИЛ» ничего не перечисляла – не объяснение от слова совсем.

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

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

Золотое правило: никаких ВАЖНО, СРОЧНО ВОТПРЯМЩАЗНАДО по телефону у банков не бывает от слова совсем. Если срочно – они уже все сделали сами, не спрашивая клиента, если не сделали – значит не срочно.

Вариант 2: клиент звонит банку (по заведомо подлинному телефону оного). Вот тут клиенту предстоит доказать банку, что звонящий – это именно он, а не Вася Пупкин в шутливом настроении, и спросить его могут буквально все, при условии, что банк сам знает эту информацию (см. выше).

Т.е. вопрос: Какие последние операции по карте Вы помните? – нормальный вопрос и скрытничать тут не стоит, в этот момент перед сотрудником банка открыт список всех транзакций по вашей карте. А вот вопрос: Что именно Вы оплачивали 10.02.2020 г. в ООО «Интим» за 3262 рубля 14 копеек? – уже никак не может послужить идентификации клиента и вообще из серии вторжения в личную жизнь, а потому не требует ответа, даже если ООО называется «Все для рыбалки» и покупали вы там скромные поплавки.

Вариант 3: банк (допустим) звонит не клиенту и чего-то от него хочет. Например: У нас тут записано, что Вы брали кредит, если это не так, уточните свои паспортные данные. Единственный вариант ответа: Прогуляйтесь в Перу, на гору Ñahui, или слетайте в Китай, порыбачить на озере Hui. GPS координаты этих природных объектов можете смело сообщать звонящему – они и так общеизвестны.

Резюме: PIN, CVV2/CVC2 и пароль от клиент-банка никто живой у вас спрашивать не может, только бездушная железка – банкомат, платежный терминал, сайт банка/банковское приложение. «Одноразовый» пароль вживую могут спросить только в офисе банка, развернув к вам монитор и демонстрируя, куда этот пароль вводится и зачем (после ввода должно придти обычное уведомление, что за операция была совершена с этим паролем).

11 условных автоматических ответов

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

13 уведомлений о недоставленных сообщениях

Жаль. Хотелось бы, чтобы клиенты этих компаний не сталкивались с подобной проблемой.

Сообщают, от кого и когда клиент может ожидать ответа

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

Конкретный пример: компании Zenefits и Postmates.

Некоторые компании предусмотрительно включают в свои автоматические ответы информацию о сроке рассмотрения заявок клиентов. Отличными примерами служат сообщения компаний Postmates и Zenefits.

Здравствуйте, вы обратились в службу поддержки компании Postmates.

Решение ваших проблем и поиск ответов на ваши вопросы являются нашими главными задачами. Для решения срочных проблем специалисты службы поддержки свяжутся с вами в течение 20-30 минут, в остальных случаях – в течение 24 часов.

Всего вам доброго

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

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

Хотелось бы объединить все запросы поддержки в одну большую категорию: заявки (тикеты). Ведь заявка есть заявка, не так ли? К сожалению, это не так. Одни заявки требуют немедленного рассмотрения, а другие могут подождать пару дней. Вы можете оказаться в затруднительном положении, если станете рассматривать все заявки в порядке их поступления – некоторые проблемы нужно решать вне очереди.

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

Конкретный пример: компания JustFab.

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

Сейчас ищут техподдержку:  Служба поддержки Госуслуг: телефон и другие способы связи

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

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

Конкретный пример: Flipagram.

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

Одна строчка Торну особенно понравилась: «Вашу заявку рассматривают обычные жители Лос-Анджелеса, которые любят пользоваться Flipagram. Мы рады пообщаться с Вами».

Текст этого письма слишком велик, чтобы уместить его в одно изображение. Перейдите по ссылке, чтобы прочитать его полностью (на английском).

63 автоматических ответа

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

9 компаний никак не отреагировали

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

Анализируйте работу

Без своевременного анализа качества работы сотрудников трудно сказать, в правильном ли направлении двигается отдел. Поэтому «разбор полётов» нужно делать регулярно. Есть два основных подхода: 

А) Анализ количественных метрик: сколько заявок, звонков и сообщений обработал каждый сотрудник за определённое время. Некоторые тикет-системы и сервисы IP-телефонии обладают встроенной функциональностью для сбора подобных данных. 

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

А ещё постоянно проводите переаттестации сотрудников, чтобы узнать их уровень подготовки и оценить профессиональные навыки. 

⌘⌘⌘

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

Аргумент против использования автоматических сообщений службой поддержки (или аргумент в пользу условных автоматических сообщений)

Команда StatusPage решила выяснить, какие типы компаний устанавливают автоответчик, а какие – нет. Результат удивил. Углубившись в изучение этого вопроса, исследователи обнаружили закономерность: чем крупнее компания, тем большая вероятность, что ответы рассылаются автоматически.

От Airbnb, например, было получено такое сообщение.

Здравствуйте,

Спасибо, что обратились к нам.

Меня зовут Эдриан, я являюсь экспертом сообщества airbnb и хозяином жилья в статусе Superhost, г. Ванкувер, Канада. Я могу проконсультировать вас по этому вопросу.

К сожалению, у нас нет автоответчика – здесь работают только люди!

Если у вас есть дополнительные вопросы по этой теме, я с радостью отвечу на них.

Всего наилучшего,

Эдриан

Бонус: добавьте юмора

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

Отличным примером является сообщение компании Tilt.

Спасибо за ваше обращение!

Нам не терпится оказать Вам помощь, и мы свяжемся с Вами быстрее, чем Канье Уэст добегает до сцены за наградой Грэмми.

Обычно мы работаем с 9 до 16 ТСВ с понедельника по пятницу, но вы можете прочитать ответы на часто задаваемые вопросы в разделе Центр Поддержки.

Удачи,

Команда счастья Tilter

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

А в письме от службы поддержки компании Imgur вы увидите ссылку на фотографию милого щенка.

Спасибо, что обратились в Imgur, ваша заявка под номером […] была получена. Служба поддержки Imgur работает с 10.00-19.00 ТСВ с понедельника по пятницу. Мы ответим на ваш вопрос в кратчайшие сроки.

Выберите каналы для работы

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

Доля заявок, закрытых в ходе первого обращения — first contact resolution rate

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

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

Доля решенных заявок — resolution rate

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

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

Дополнительное чтение

Если вы хотите копнуть глубже, Торн также советует ознакомиться с другими полезными материалами на эту тему:

Индекс лояльности — net promoter score

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

  • насколько вероятно, что клиент порекомендует компанию окружающим (оценка от 0 до 10);
  • почему?

Считается, что клиенты, давшие оценку от 0 до 6, упоминая компанию, скорее будут отзываться о ней негативно; с оценкой 7 — 8 будут действовать пассивно, а те, кто дают оценку 9 и 10 могут стать промоутерами вашего бизнеса.

Важно:

  • что у этой стандартизованной метрики есть целевые значения для разных отраслей, полученные на основании данных сотен компаний по всему миру

(примечание: у нас в Okdesk этой метрике тоже уделяется особое внимание. Подробнее о результатах по ссылке)

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

Количество просроченных заявок — number of ticket backlog

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

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

Help Desk система для автоматизации техподдержки со встроенными отчетами и дашбордами. Бесплатное тестирование!

Лучшие специалисты — top agents

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

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

Между первой и второй линиями технической поддержки

Как часто вы встречали прикладных админов которые любят заниматься решением инцидентов?

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

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

О том, как мы это делали и с какими трудностями столкнулись, мы расскажем вам в этой статье.

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

Сейчас ищут техподдержку:  Билайн техподдержка живой оператор

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

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

image
рис.1 Схема организации процесса сопровождения (было)

Запрос проходил через первую, вторую и третью линии поддержки, распределялась между ними в следующих пропорциях: 15:75:10.

Первая линия — Service Desk — прием, обработка, маршрутизация обращений с использованием следующих каналов коммуникации:

  • телефон — 8% от всего количества обращений
    портал самообслуживания — 83% от всего количества обращений
    электронная почта — 4% от всего количества обращений
    чат-бот в Viber и Telegram — 5 % от всего количества

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

ссылка здесь

Вторая линия — команды сопровождения прикладного ПО инфраструктура DBA …,

Третья линия — это команды разработки.

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

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

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

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

В целях минимизации времени решения инцидентов, как пилотный проект, мы решили создать кроссфункциональную объединенную команду из сотрудников первой и второй линии для решения инцидентов в фронт системах Банка – интернет-банк, мобильный банк, сервисы отправки сообщений (sms и push) основная фронт — офисная система Банка.

Эта команда является промежуточной между первой и второй линиями — полуторная линия поддержки, которую мы назвали “Frontline”.

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

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

Местом локации «Frontline» стал ИТ-Центр Банка в городе Обнинск.

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

  • два сотрудника первой линии поддержки
  • два сотрудника группы сопровождения фронт-офисной системы
  • два сотрудника группы сопровождения Интернет-банка и мобильного банка
  • один сотрудник группы сопровождения сервисов информирования клиентов (sms & push)

Основной фокус команды был сконцентрирован на 3-х показателях:

  • СКОРОСТЬ — 70% запросов, поступающих в команду, необходимо решать не более чем за 8 рабочих часов
  • КОЛИЧЕСТВО — команда может маршрутизировать на вторую линию поддержки не более 20% запросов
  • КАЧЕСТВО — доля переоткрытых пользователями инцидентов не должна быть более 3%

image
рис. 2 Процесс обработки инцидентов с участием Frontline

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

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

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

Зачем?

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

Сделали необходимые учетные записи, предоставили достпы к логам приложений и баз данных, и вперед! 🙂

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

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

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

image
рис.3 Дашборд эффективности Frontline

Здесь нужно сказать отдельное «спасибо» руководителю команды сопровождения фронт-офисной системы Банка, который взял на себя функции лидера и культивировал развитие командны изнутри — Алексей, спасибо! 🙂

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

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

image
рис.4 Пилотный проект Frontline, первые показатели

Очень скоро стало понятно, что пилот успешно “взлетел”, и целесообразно проект масштабировать.

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

Постепенно мы перешли к «Т — кроссфункциональности», когда за каждым участником закреплены одна основная система и две смежные.

image
рис. 4 Сравнительная статистика за 2020 год по времени решения запросов между Frontline и командами сопровождения второй линии

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

Для второй линии поддержки «Frontline» сегодня — это надежный «щит», который значительно снижает поток обращений приходящий к ним.

image
рис.5 Количество и доля инцидентов решенных во «Frontline» (на рис. — Team1) по отношению к инцидентам, решенным на второй линии по всем системам Банка

Сегодня все участники «Frontline» — это сотрудники из Service Desk, которые решают инциденты по основным фронт системам Банка, выдерживая заданные целевые показатели.

Так же «Frontline» — это следующая ступень для сотрудников Service Desk в нашей карьерной лестнице, перед переходом на вторую линию поддержки.

Наберите надёжную команду

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

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

Общее количество заявок — number of support tickets

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

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

Определитесь, нужно ли вам это

Если у вашей компании появилась мысль о собственном отделе технической поддержки, то прежде чем переходить к действиям, задайте себе вопрос: «Это действительно нужно?». Если вы работаете с небольшим количеством клиентов и на общение с их представителями уходит не более 30% времени одного сотрудника, то техподдержка в классическом её понимании вам не нужна: только зря потратите ресурсы.

Сейчас ищут техподдержку:  Горячая линия Сбербанк бизнес

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

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

Отбор компаний

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

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

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

Оценка удовлетворенности клиентов — customer satisfaction score (csat)

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

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

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

Другие полезные статьи по данной теме:

Okdesk —  лидирующая Help Desk система (опыт более 5000 компаний) для автоматизации техподдержки. Множество встроенных отчетов и дашбордов.

Признаки хорошего автоматического ответа от службы поддержки

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

Процесс

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

Составление заявки

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

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

Вот, что получилось:

Тема: Это тест

Здравствуйте!

Сразу перейду к делу и предупрежу, что это сообщение не является настоящим запросом поддержки. За это я прошу прощения. Меня зовут Блейк, я работаю в компании StatusPage.io.

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

Если в вашей компании не установлен автоответчик – не беспокойтесь, я не стану упрекать Вас в этом.

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

Если Вы захотите связаться со мной напрямую, чтобы подробнее рассказать о своем автоответчике, буду Вам очень признателен. Ответы присылайте на адрес blake@statuspage.io (этот email я отправил с аккаунта, созданного специально для этого проекта).

Спасибо и удачи в вашей работе!

Блейк Торн, StatusPage.io

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

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

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

Прочие наблюдения

Составьте план действий

Итак, вы решили — служба нужна. Теперь важно продумать план. Он индивидуален для каждой компании, но некоторые пункты будут общими для всех: 

А) Выбор каналов общения. Это может быть телефон, профили в социальных сетях и тикет-система. Для начала достаточно одного канала. Самый доступный вариант — помогать клиентам в социальных сетях. 

Б) Команда и её обучение. Определите, каких сотрудников брать, а каких — нет. Кто и как будет их обучать.

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

Г) График работы и его формирование. Не запускайте сразу поддержку 24/7, если к вам ночью обращается меньше 5% клиентов. Это будет дорого и преждевременно. Также учитывайте, что чем стандартнее график работы, тем меньше людей требуется в отдел.

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

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

Это основные этапы. На выборе каналов для общения и команды мы остановимся подробнее в следующих пунктах. 

Среднее время обработки заявки — average handle time

Этот показатель позволяет количественно оценить эффективность повседневной работы поддержки.Важно:

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

Среднее время ответа — average reply time (art)

В отличие от AFRT, эта метрика показывает, как быстро решаются вопросы клиентов.

Важно:

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

Среднее время первого ответа — average first response time (afrt)

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

1 Звезда2 Звезды3 Звезды4 Звезды5 Звезд (1 оценок, среднее: 5,00 из 5)
Загрузка...

Оставьте комментарий

Adblock
detector