Оказалось, что когда пользователи вас любят, они творят меньше дичи.
Точнее, даже не так. Сначала они начинают рассказывать вам, что их парит. И это помогает заранее убирать целые, как образно выражаются некоторые специалисты со стажем, «clusterfuck-проблемы».
Мы сервисдеск банка, и у нас типовые задачи: где-то ночью в Петропавловске-Камчатском зажевало бумагу в принтере, где-то бухгалтерия сделала «ой, оно само», где-то надо присвоить или забрать права в систему и так далее.
Началось с того, что мы как-то сели и решили делать генеральную уборку и автоматизировать то, что легко автоматизируется. Тогда это казалось задачей на пару недель (ну ладно, на месяц). Плюс была гипотеза, что если начать разговаривать с пользователями как-то более системно, то они расскажут что-то интересное. Одним из шагов стало то, что мы развернули прямо пиар-работу. Выяснилось, что если рассказывать внутри компании о работе поддержки, то её начинают больше любить и понимать. И есть прямая связь между силами, потраченными на хорошие отношения с публикой, и количеством и качеством тикетов.
Можете называть это проактивным подходом.
Короче, рекомендую.
Сама задача
По сути, задач было две: автоматизация рутины и через это — улучшение отношений с пользователем. У нас много метрик, и там часть — про само решение проблемы, а часть — про сервис. Если вы отлично решаете проблему, но издеваетесь над конечным пользователем, то это ему почему-то не нравится, и он считает такую работу очень плохой. Короче, надо было быть хорошими или хотя бы нормальными в сервисе тоже.
Чтобы вы понимали, что такое «нормальный сервис», просто отмечу, что если вы конченый отморозок, то KPI по норме регистрации обращений можно очень сильно поднять, если делать так:
— А у меня процессор не работает!
— О, отлично! Сейчас я вам расскажу, какой запрос куда написать. Значит, заходите в…
То есть обращение создаётся, показатель растёт, а дальше пользователь пишет тикет уже письменный, KPI соблюдается, всё в шоколаде. Только это не шоколад.
Нужно было быть реально полезными, а не хакать KPI. И мы пришли к осознанию того, что нам нужно работать над увеличением FCR (количество проблем, решённых прямо во время первого обращения, например, во время первого звонка). Оно будет определяться степенью автоматизации и уровнем загруженности поддержки, то есть очередью. Сейчас мы стремимся к тому, чтобы была нулевая очередь. Когда в очереди — 10 обращений, все новые решаются быстро: за полтора-два часа.
Чтобы улучшить сервис, нужна автоматизация. Чтобы меньше работать, тоже нужна автоматизация. Идеальное состояние сотрудника поддержки — сон в ожидании обращений. Мы чертовски ленивые, поэтому всё же пришлось собраться и поработать над автоматизацией.
ЦУП
Для начала сделали сервис «Карточка пользователя», или Центр Управления Полётами (ЦУП) — место, куда собирается вся информация про пользователя, чтобы при каждом звонке не выяснять, что там за операционка, сколько у него памяти, что это за пользователь и т. п. Заодно надо смотреть, есть ли сейчас массовые проблемы и так далее. Собрали в одно место всё это:
1 — это поиск пользователя в AD. 2 — если есть массовая ошибка, то информацию из нашей ITSM мы выводим сюда. 3 — выводим историю обращений пользователя за последнюю пару месяцев, чтобы сразу понимать, с чем и когда он к нам недавно приходил, и не задавать глупых вопросов.
Вот данные о его компьютере (судя по всему, это тонкий клиент одного из отделений):
Как использовать? Вот, например, позвонил пользователь. Мы спросили у него фамилию, далее смотрим, не истёк ли пароль, когда он менялся в последний раз, говорим: «%username%, у вас такой-то компьютер, верно?» — смотрим характеристики ПК, пробегаем глазами по списку его последних обращений.
Как правило, с помощью данных действий можно сразу отсечь львиную долю дополнительных вопросов и ряд потенциальных проблем, например, со свободным местом на жёстком диске. Видим, что пользователь подключён из VPN и жалуется, что не открывается определённый ресурс. Понимаем, что, скорее всего, проблема в том, что закрыт доступ к ресурсу из VPN, и далее отрабатываем эту гипотезу. Если другая проблема — можем скинуть инструкцию. Если после описания проблемы мы понимаем, что пользователь в состоянии решить свой вопрос самостоятельно, то договариваемся с ним и отправляем инструкцию.
Собственно, в разделе «Инструкции» есть таковые на все случаи жизни. Мы же всё равно всё описываем, так что всё это можно нарезать на кусочки и отправлять пользователю на почту.
Вот так это выглядит:
А вот и сама вики пользователей, откуда мы подтягиваем инструкции.
Вот главная страница пользовательской вики:
Главное в такой вики — нормальный поиск и нормальная навигация. Сейчас в ней около 100 человек в день. Я хочу верить, что это около 100 проактивно решённых тикетов.
Работа дальше
Обычные действия в таких ситуациях — это шаблонизация всего что только можно. Пример — те же роли сотрудников. Когда кто-то выходит на вакансию, ему накатывается всё нужное ему ПО по его ролевой модели. Есть магазин приложений: приходит в него человек, наклацал, что ему нужно из доступного под его роль, — поставилось. Причём всё это делается, не создавая обращения. Всё это заняло чуточку больше времени, чем мы хотели бы, но получилось очень удобно.
Потом надо идти за пользователями. Мы тут живём по SAFe (это один из аджайл-фреймворков), а аджайл — это что-то такое про близость к бизнесу. Для себя мы это поняли так: надо приходить за пользователем, чтобы было удобно ему, а не нам. Точнее, нам будет удобно за счёт интеграции, а ему — за счёт того, что мы общаемся там, где удобно. Создаём новые каналы связи, присутствуем в мессенджерах — получаем открытость и всё такое.
Оттуда же пришла история с кросс-функциональными командами и центрами компетенций. Предполагается, что лучшая организация — это самоорганизация, поэтому внутри саппорта мы создали центр компетенций, клубы по интересам. Есть направления автоматизации, веб-разработки, разработки на Питоне. Они объединяются по интересам, и дальше мы мотивируем на изучение материалов и разработку в основном в свободное время. Это классические гильдии.
Потом — проблем-менеджмент. Это когда вы лечите не симптомы, а корневую проблему. Мы уделяем внимание проблем-менеджменту, опираясь на инцидент-менеджмент. Выявляем паттерны, повторяющиеся инциденты, работаем с обратной связью, чтобы выяснить проблему и устранить её. Вот, например, раз в два дня в Комсомольске-на-Амуре пользователь ставит тикет на то, что у него не работает принтер. Мы это уже видим в ЦУПе, тикет повторяющийся. Начинаем разбираться. У нас есть техспециалисты на местах, мы работаем со всей Россией. Приезжает такой выездной админ, вытащит бумажку, запустит принтер, уйдёт. Потом — опять. Может быть, ролики кривые. Но его руководитель может быть не в курсе, система ещё долго способна на автопилоте решать отдельные тикеты. В итоге мы видим инцидент, ищем проблему, дальше подключаем всех участников процесса и пытаемся понять. Потом проблема уходит, а с ней уходят ещё десятки возможных обращений.
Или вот есть процесс, связанный с выдачей неименных карт. Смотрим инциденты по данным картам за определённые периоды, замечаем повторяющиеся ошибки. Сходили к сопровождению системы, выяснили, почему они могут возникать, сходили в бизнес, посмотрели, каким образом что предшествует, какая модель поведения при этом в ПО. В большинстве случаев проблема — из-за некорректного поведения в системе. Написали большую инструкцию, провели обучение. Передали в бэк-офис функционал по сопровождению таких инцидентов.
В общем, мы всеми силами предупреждаем возникновение других таких инцидентов.
Дальше нужна ещё роботизация рутинных операций — это когда всё то, что не поддаётся автоматизации классической, закрывается записанным скриптом, эмулирующим действия живого пользователя. То есть со всеми заходами в разные системы, вводом пароля из восьми звёздочек, копипаста и так далее.
И так мы постепенно подобрались к пиару
Лояльность пользователей важна. Но при этом PR в саппорте — это крайне противоестественно. Тем не менее мы всё же запилили «Клуб друзей ТП». Там состоит много руководителей. По сути, это что-то вроде новостного канала, где можно посмотреть сообщения об изменениях в наших процессах. Мы там рассказываем, что и как происходит, а пользователи, которые это всё читают, несут дальше в бизнес информацию, которую мы передаём.
Проще говоря, когда про вас ничего не знают — это хорошо. Особенно в банке. Но когда про вас знают и рассказывают нужные вещи — это ещё лучше.
В общем, наш бложек внутри компании вдруг стал важным инструментом, и прямо заметно, как он работает. Тоже рекомендую.
Следующая пиарная штука — опросники. Оказывается, что можно отправлять раз в квартал всей компании опросник, всё ли в порядке, ничего ли не беспокоит. Это что-то вроде расширенного сбора обратной связи в целом, а не по конкретным вопросам. Дальше главное — возвращаться по всем странностям и разбираться. И в наш клуб писать тоже, что там нашлось. Когда люди видят, что мы реагируем, это всех радует, и они дальше стараются нам помогать. Из интересного недавнего, например, была жалоба на то, что условно по 12-м числам пользователь ночью не может подключиться к своему компьютеру. Стали копать, и оказалось, что есть некий нюанс с принудительной установкой обновлений и перезагрузкой. Поправили групповые политики, и проблема ушла. Страдал в итоге не один человек, а сразу сотня, но сказать решил только один, для остальных это был такой закон природы.
Кстати, про неформальность. Как я уже писал выше, мы пришли туда, где удобно пользователям. В какой-то момент оказалось, что пользователям удобнее всего не заходить в корпоративные системы, а писать в «Телеграм» кому-то о своей проблеме. В итоге сделали даже двух чат-ботов с интеграциями, и они в человеческой форме выспрашивают всё нужное для тикета. Инцидент создаётся почти как в чате с человеком, только это не человек. Но пользователям явно удобнее, чем в ITSM.
Очень важно оставаться вежливыми и добрыми. У вежливости есть две формы: когда вас выслушали, поблагодарили по скрипту и вежливо, но послали. Или когда реально попытались понять, что действительно болит у пользователя, не были формалистами. Здесь, например, важно на отслушивании разговоров (а мы слушаем диалоги для контроля) оценивать стремление не просто отделаться от пользователя, а решить корневую причину. То есть понять проблематику, докопаться до сути и устранить причину.
Из метрик просто отмечу, что FCR увеличили в 10 честных раз, сейчас это около 30 %. Тикет создаётся во время обращения и тут же закрывается. Это решение болей на лету, тут помогают и ЦУП, и то, что мы заранее снимаем кучу повторяющихся проблем, и то, что у нас есть скрипты на типовые действия, и много чего ещё. Один разработчик нам даже написал, что мы самый быстрый сервисдеск. Ему всего за 1 час 15 минут решили крупный инцидент, а такого в банках он до этого не видел. В целом у нас тикет на первой линии закрывается за три с половиной часа с момента регистрации. Причём медиана там где-то в районе полутора-двух часов, потому что на среднее очень влияют противные длинные тикеты, которых меньшинство.
Что сделали ещё раз:
- Собрали инструкции и выложили в вики, чтобы всё было покрыто.
- Собрали все источники данных в один интерфейс (ЦУП), чтобы нам было удобно быстро диагностировать.
- Автоматизировали все повторяющиеся действия.
- Автоматизировали по RPA всё то, что не автоматизировалось в лоб. Ну пусть не совсем всё: мы с роботизацией ещё в начале пути, и у нас много чего впереди.
- Пришли в каналы к пользователям и слушаем их там, чтобы им было удобно.
- От решения проблем перешли к профилактике.
- А чтобы делать хорошую профилактику, занялись пиаром внутри компании.
Вот примерно так логичные причинно-следственные связи привели к тому, что мы теперь тоже своего рода пиарщики.
