Проблемы техподдержки, и как их решают Service Desk-системы

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

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

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

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

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

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

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

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

1. Создание корпоративной базы знаний

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

2. Автоматизация стандартных HR-процессов 

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

3. Единая точка коммуникаций для экономии рабочего времени

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

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

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

4. Подключение корпоративного чат-бота

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

Проблема 2. Несоблюдение сроков ответа на обращение: как выявить и устранить узкие места в техподдержке

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

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

К сожалению, многие техподдержки до сих пор работают в духе: «Вот наш почтовый ящик, напишите. Срок обработки обращения – 10 дней». Через десять дней клиенту, возможно, ответят, а, может, и нет. И ему дальше придется пробираться сквозь непробиваемую стену, писать запросы в неизвестность и ожидать отклика. Такая картина наблюдается у разных компаний и проявляется в связи с рядом проблем. Например, банально из-за низких стандартов сервиса и отсутствия сервисной культуры в компании, или же из-за проблем с коммуникациями, которые не всегда определяются инструментами аналитики внутри внедренных help desk или service desk систем.

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

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

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

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

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

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

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

Проблема 3. Медленный доступ операторов к информации: как интерактивные подсказки помогают искать ответ на нестандартные вопросы

Рано или поздно сотрудник технической поддержки становится некой базой знаний и на любой запрос уже сам дает типовой ответ, потому что сталкивался с подобными обращениями сотни раз и с первого взгляда понимает, в чем беда у клиента и что с этим делать. Но чтобы быстро обработать запрос, с которым оператор еще не сталкивался, ему нужно где-то найти информацию о том, как его обработать. Например, клиент говорит: «У меня проблема», – сотруднику нужно уточнить что-то, задать вопросы, чтобы однозначно идентифицировать, в каком месте у клиента болит. Этот стандартный набор вопросов и гипотезы о том, что это может быть, где-то нужно быстро найти. В компаниях с низким уровнем автоматизации таким источником информации будет в лучшем случае Вики, в худшем — документ или системная папка, в которую сотрудники поддержки заходят и осуществляют поиск по ключевому слову. Проблема кроется в том, что операторы, которые работают в компании не 20 лет, а второй месяц, будут тратить на поиски крайне много времени, а показатели решения обращений сильно падать. 

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

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

Проблема 4. Плохое информирование клиентов о недоступности услуги: как проактивно работать с проблемами

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

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

Проблема 5. Низкая лояльность клиентов к техподдержке: как настроить клиентский портал, чат-ботов и оповещения

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

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

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

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

Выбор Service Desk-системы

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

Автор: Наталия Долженкова, product owner ELMA365 Service