Не кажется ли вам, что нормирование процента передачи на 2ю линию — зло? Ведь такая планка провоцирует фронтлайн применять быстрые сиюминутные меры, не доводя проблему до устранения корневой причины на 3L.
Соглашусь с тем, что нормирование может быть злом, если оно под собой не имеет предварительного анализа и оснований, планка в 20% задана на основе анализа запросов за пол года, она не высока, так как ее чаще всего сотрудники Frontline перевыполняют.
Для себя мы решили, что на вторую линию должны попадать инциденты, решение которых требует какой — либо настройки продуктива.
Когда сотрудник Frontline видит ошибку в работе системы, исправление которой потребует доработку — он заводит тикет в Jira, привязывает его к инциденту в BMC Remedy и запрос в Jira назначает на команду развития, а сам инцидент оставляет в очереди Frontline и мониторит его выполнение. После того, как команда развития подготовила патч с исправлением и вторая линия поддержки его установила на продуктив, сотрудник Frontline проверяет исправление ошибки и после этого закрывает инцидент в BMC Remedy.
Каждый сотрудник Frontline закреплен за каким то подразделением второй линии и в случае возникновения каких либо вопросов и сомнений может обратиться к коллегам.
А если в потоке тикетов так велика доля запросов, действительно не требующая вмешательства в код/конфиг, то это косвенно указывает на проблемы с продуктом в целом или с понятностью инструкций для пользователей.
Особенность фронт систем в том, что на них «вылезает» всё — и ошибки в работе самой системы, ошибки на бэк системах, ошибки бизнес логики, ошибки сотрудников в процессе оформления продукта, особенности настройки маркетинговых акций и тд.
Мы используем дополнительную классификацию второго уровня в системе BMC Remedy и при закрытии запроса проставляем причину ее возникновения, так выявляя рост ошибок со стороны пользователей, мы можем передать информацию бизнес подразделениям, чтобы они провели доп обучение сотрудников розницы, если увеличивается количество интеграционных ошибок — мы так же сигнализируем об этом необходимым командам и т.д. Задача Frontline не просто закрыть инцидент, а сделать так чтобы их становилось меньше, своего рода Problem Management.
Я правильно понимаю, что внутри первой линии и находятся эти рабочие группы (сообщества)?
Да, все верно.
Если так — я бы мерял не только время реакции на звонок (взятие трубки), но и количество футбола.
Для 1й линии измеряется более 20 различных показателей, но в KPI записаны те, которые мы считаем на текущий момент более значимыми.
Измеряем и долю обращений, которые вернули на 1ю линию после маршрутизации, но «футбол» обычно не характерен для 1й линии, этим чаще грешат на 2й линии и то, не по корыстной причине, а потому, что ошибка интеграционная и для ее решения необходимо подключать команды поддержки смежных систем.
Пишу не голословно, так как мы глубоко анализировали этот вопрос. И как основной инструмент для уменьшения количества итераций маршрутизации между командами 2й линии мы выбрали запуск 1,5 линии поддержки (Frontline).
Вообще на 1ю линию чаще возвращаются запросы маршрутизированные нашим сервисом «Виртуальный сотрудник», это порядка 7% от того что он смаршрутизировал, если больше — мы останавливаем работу сервиса и переобучаем модель (сервис построен на базе нейронных сетей с применением машинного обучения)
На мой взгляд рост по линиям поддержки как карьера ИТ-шника — так себе.
Зависит от компетенций и выбора направления развития сотрудника, да и не ограничивается карьерная лестница только веткой сопровождения. 60% текущих сотрудников поддержки, тестирования и разработки ИТ Центра Обнинск — это сотрудники 1й линии в прошлом.
Не в курсе как конкретно у вас, но обычно работа первой и третьей линии принципиально отличается. На третьей линии может работать условный глухонемой «человек дождя» и реально классно делать твою работу. Он нифига не умеет в общение, но задачу «снизить время отклика API для инстанса ABC на 10%» может выполнить не задумываясь.
Аналогично, согласен.
Реально круто, что так мало голосовых обращений. Не секрет ли как вы этого добиваетесь? На моей практике если у работника есть телефон, известен номер саппорта и звонок бесплатный — то обращающийся будет звонить.
Мы очень долго и итерационно к этому шли и идем по сей день:)
Но начинали мы с понимания того, что пользователь звонит по телефону в ServiceDesk не потому, что ему нравится разговаривать по телефону (хотя, возможно есть и такие), а потому что именно телефонный звонок ассоциируется у него с быстрым решением его проблемы, хотя в большинстве случаев это не так.
Мы создаем сервис, даже можно это назвать среду поддержки, в которой запрос решится быстрее если его завести на портале самообслуживания по определенному шаблону, и тогда он выполнится быстрее (потому что автоматически, минуя непосредственное участие сотрудника 1й линии). Например, это запросы на сбросы паролей, предоставление доступов в основные системы Банка, установки части ПО и тд.
Второе это добавление альтернативных каналов для подачи обращений, у нас это чат бот в Telegram и Viber (очень актуально для категории сотрудников, работающих в «полях» и не имеющих компьютера под рукой) — на часть вопросов отвечает он, так же в онлайне закрывает потребности по тому же сбросу пароля, предоставлению инфо по статусу обращения пользователя, находящегося в работе. Мы активно развиваем этот канал, сейчас пилотируем на 2х Дирекциях, после ролаута количество обращений по телефону прогнозируемо еще снизится.
Третье — это выявление точечных проблем по которым обращается конкретный пользователь. У нас для этого есть отдельный дашборд, на котором мы в онлайне видим пользователей, которые обращались за день/неделю/месяц чаще всего. Оперативно созваниваемся с ними, спрашиваем что не получается, помогаем.
И весь этот процесс у нас постоянен, далеко не все еще идеально и есть еще желание и возможности уменьшить количество обращений через канал «телефон».
Там тоже действуют SLA? Если не секрет, сколько времени выделяется на такой инцидент?
В Банке установлены общие SLA, которые зависят от приоритета инцидента, который в свою очередь варьируется от низкого до критического. Критериями выставления того или иного приоритета инциденту являются матрица критичности информационных систем Банка и влияние инцидента на бизнес процессы.
Вне зависимости от того, сколько команд или линий поддержки участвует в решении инцидента, решается он силами специалистов Банка или привлекается аутсорс, общий лимит времени отведенный на решение инцидента не меняется и составляет от 40 до 2х рабочих часов.
Вообще, по Вашей статье — спасибо! Варюсь в айти поддержке около 10 лет — из них 9 в американском новостном агентстве и год в немецком автоконцерне. И смею заметить ваша система — огонь! И по KPI тоже очень грамотно, и командная ответственность.
Наставники в командах, я так понимаю типа тимлидов.
Вроде того :)
Наставник это обычно самый опытный сотрудник, эксперт. Который помимо основной деятельности занимается развитием сотрудников входящих в его сообщество. Участвует в проведении оценки сотрудников своего сообщества и предоставлении им регулярной обратной связи. Этой активностью он занимается совместно с руководителем Service Desk.
Прямых рычагов управления людьми у него нет, он даже может быть в одной должности с некоторыми из специалистов своего сообщества. Наставник (координатор) — в нашем случае, это роль.
Еще вопрос позволю — пиковые нагрузки как преодолеваете при необходимости. Аутсорсеры могут прислать людей обычно своим командам в таких случаях, снять с других обьектов. А у вас штатная команда всё же.
Если говорить про Service Desk, то там пиковые нагрузки возникают в основном либо по причине массового технического сбоя (на этот случай у нас есть сервисы информирования пользователей для снижения обращений на 1ю линию — IVR, информационный баннер на портале самообслуживания и на портале для сотрудников розничного бизнеса, а так же мы можем отправлять информационные сообщения о сбое используя наш чат бот). Вторая причина возникновения массовых обращений — это запуск нового функционала или продукта, это прогнозируемая нагрузка, к которой мы предварительно готовимся, усиливая смены в такие дни.
Что касается регионов, то мы стараемся закрывать большую часть запросы удаленно, тем самым минимизировав выезды региональных администраторов, но работы конечно же и им хватает :)
Если проблему не удается или технически невозможно решить удаленно силами 1й линии поддержки, тогда запрос назначается на подразделение региональных системных администраторов и они выезжают в банковский офис для проведения технических работ.
Соглашусь с тем, что нормирование может быть злом, если оно под собой не имеет предварительного анализа и оснований, планка в 20% задана на основе анализа запросов за пол года, она не высока, так как ее чаще всего сотрудники Frontline перевыполняют.
Для себя мы решили, что на вторую линию должны попадать инциденты, решение которых требует какой — либо настройки продуктива.
Когда сотрудник Frontline видит ошибку в работе системы, исправление которой потребует доработку — он заводит тикет в Jira, привязывает его к инциденту в BMC Remedy и запрос в Jira назначает на команду развития, а сам инцидент оставляет в очереди Frontline и мониторит его выполнение. После того, как команда развития подготовила патч с исправлением и вторая линия поддержки его установила на продуктив, сотрудник Frontline проверяет исправление ошибки и после этого закрывает инцидент в BMC Remedy.
Каждый сотрудник Frontline закреплен за каким то подразделением второй линии и в случае возникновения каких либо вопросов и сомнений может обратиться к коллегам.
Особенность фронт систем в том, что на них «вылезает» всё — и ошибки в работе самой системы, ошибки на бэк системах, ошибки бизнес логики, ошибки сотрудников в процессе оформления продукта, особенности настройки маркетинговых акций и тд.
Мы используем дополнительную классификацию второго уровня в системе BMC Remedy и при закрытии запроса проставляем причину ее возникновения, так выявляя рост ошибок со стороны пользователей, мы можем передать информацию бизнес подразделениям, чтобы они провели доп обучение сотрудников розницы, если увеличивается количество интеграционных ошибок — мы так же сигнализируем об этом необходимым командам и т.д. Задача Frontline не просто закрыть инцидент, а сделать так чтобы их становилось меньше, своего рода Problem Management.
Да, все верно.
Для 1й линии измеряется более 20 различных показателей, но в KPI записаны те, которые мы считаем на текущий момент более значимыми.
Измеряем и долю обращений, которые вернули на 1ю линию после маршрутизации, но «футбол» обычно не характерен для 1й линии, этим чаще грешат на 2й линии и то, не по корыстной причине, а потому, что ошибка интеграционная и для ее решения необходимо подключать команды поддержки смежных систем.
Пишу не голословно, так как мы глубоко анализировали этот вопрос. И как основной инструмент для уменьшения количества итераций маршрутизации между командами 2й линии мы выбрали запуск 1,5 линии поддержки (Frontline).
Вообще на 1ю линию чаще возвращаются запросы маршрутизированные нашим сервисом «Виртуальный сотрудник», это порядка 7% от того что он смаршрутизировал, если больше — мы останавливаем работу сервиса и переобучаем модель (сервис построен на базе нейронных сетей с применением машинного обучения)
Зависит от компетенций и выбора направления развития сотрудника, да и не ограничивается карьерная лестница только веткой сопровождения. 60% текущих сотрудников поддержки, тестирования и разработки ИТ Центра Обнинск — это сотрудники 1й линии в прошлом.
Аналогично, согласен.
Мы очень долго и итерационно к этому шли и идем по сей день:)
Но начинали мы с понимания того, что пользователь звонит по телефону в ServiceDesk не потому, что ему нравится разговаривать по телефону (хотя, возможно есть и такие), а потому что именно телефонный звонок ассоциируется у него с быстрым решением его проблемы, хотя в большинстве случаев это не так.
Мы создаем сервис, даже можно это назвать среду поддержки, в которой запрос решится быстрее если его завести на портале самообслуживания по определенному шаблону, и тогда он выполнится быстрее (потому что автоматически, минуя непосредственное участие сотрудника 1й линии). Например, это запросы на сбросы паролей, предоставление доступов в основные системы Банка, установки части ПО и тд.
Второе это добавление альтернативных каналов для подачи обращений, у нас это чат бот в Telegram и Viber (очень актуально для категории сотрудников, работающих в «полях» и не имеющих компьютера под рукой) — на часть вопросов отвечает он, так же в онлайне закрывает потребности по тому же сбросу пароля, предоставлению инфо по статусу обращения пользователя, находящегося в работе. Мы активно развиваем этот канал, сейчас пилотируем на 2х Дирекциях, после ролаута количество обращений по телефону прогнозируемо еще снизится.
Третье — это выявление точечных проблем по которым обращается конкретный пользователь. У нас для этого есть отдельный дашборд, на котором мы в онлайне видим пользователей, которые обращались за день/неделю/месяц чаще всего. Оперативно созваниваемся с ними, спрашиваем что не получается, помогаем.
И весь этот процесс у нас постоянен, далеко не все еще идеально и есть еще желание и возможности уменьшить количество обращений через канал «телефон».
В Банке установлены общие SLA, которые зависят от приоритета инцидента, который в свою очередь варьируется от низкого до критического. Критериями выставления того или иного приоритета инциденту являются матрица критичности информационных систем Банка и влияние инцидента на бизнес процессы.
Вне зависимости от того, сколько команд или линий поддержки участвует в решении инцидента, решается он силами специалистов Банка или привлекается аутсорс, общий лимит времени отведенный на решение инцидента не меняется и составляет от 40 до 2х рабочих часов.
Вроде того :)
Наставник это обычно самый опытный сотрудник, эксперт. Который помимо основной деятельности занимается развитием сотрудников входящих в его сообщество. Участвует в проведении оценки сотрудников своего сообщества и предоставлении им регулярной обратной связи. Этой активностью он занимается совместно с руководителем Service Desk.
Прямых рычагов управления людьми у него нет, он даже может быть в одной должности с некоторыми из специалистов своего сообщества. Наставник (координатор) — в нашем случае, это роль.
Если говорить про Service Desk, то там пиковые нагрузки возникают в основном либо по причине массового технического сбоя (на этот случай у нас есть сервисы информирования пользователей для снижения обращений на 1ю линию — IVR, информационный баннер на портале самообслуживания и на портале для сотрудников розничного бизнеса, а так же мы можем отправлять информационные сообщения о сбое используя наш чат бот). Вторая причина возникновения массовых обращений — это запуск нового функционала или продукта, это прогнозируемая нагрузка, к которой мы предварительно готовимся, усиливая смены в такие дни.
Что касается регионов, то мы стараемся закрывать большую часть запросы удаленно, тем самым минимизировав выезды региональных администраторов, но работы конечно же и им хватает :)