Comments 7
кирпич не конкретно к описанной команде, а в общем виденьи ситуации: иногда проблема бывает настолько витиевата, что первая линия её не понимает, ставит либо в ожидание, либо просит перезвонить… потом наконец кто-то начинает переключать на более квалифицированный уровень и вот тут то иногда либо специалисты сбрасывают (привет роботу РОМАНУ и подобным киберпопугайчикам) либо это другой специалист/старший специалист этого же уровня, не понимающий технической части вопроса (привет проводному… телекому) и в результате от продукта отказываются либо даже не приобретают… в некоторых случаяк бывает клиент получает возможность сразу проскочить 0-ой, 1-ый уровни при уде достаточном опыте общения, но подобное редкое исключение, которое иногда перестает работать при смене/модернизации менеджмента/рабочей бизнес модели
кредит, вклад, услуги связи это тоже товар который приобретают и если на этапе консультаций возникают проблемы, неважно до покупки или после, клиент в случае проблем буден настроен избежать дальнейшего контакта с организацией с таким проблемным сервисом/техподдержкой
Хоть кто-то дорос до понимания принципов работы хозрасчетной бригады.
А то куда ни позвони itil во всей красе, и пока доберешься до способного решить проблему специалиста отпадает желание работать с этой компанией.
Хотя, если в первой линии сидят не попугайчики, а способные оценить сложность проблемы специалисты по общению с клиентами. К тому-же знающие основы поддерживаемых систем, и регулярно информируемые последующими линиями о новых вариантах решений.
Но увы, техподдержка на удержание клиента не ориентирована. У них другие KPI, например скорость обработки заявки.
Не кажется ли вам, что нормирование процента передачи на 2ю линию — зло? Ведь такая планка провоцирует фронтлайн применять быстрые сиюминутные меры, не доводя проблему до устранения корневой причины на 3L. А если в потоке тикетов так велика доля запросов, действительно не требующая вмешательства в код/конфиг, то это косвенно указывает на проблемы с продуктом в целом или с понятностью инструкций для пользователей.
Не кажется ли вам, что нормирование процента передачи на 2ю линию — зло? Ведь такая планка провоцирует фронтлайн применять быстрые сиюминутные меры, не доводя проблему до устранения корневой причины на 3L.

Соглашусь с тем, что нормирование может быть злом, если оно под собой не имеет предварительного анализа и оснований, планка в 20% задана на основе анализа запросов за пол года, она не высока, так как ее чаще всего сотрудники Frontline перевыполняют.
Для себя мы решили, что на вторую линию должны попадать инциденты, решение которых требует какой — либо настройки продуктива.
Когда сотрудник Frontline видит ошибку в работе системы, исправление которой потребует доработку — он заводит тикет в Jira, привязывает его к инциденту в BMC Remedy и запрос в Jira назначает на команду развития, а сам инцидент оставляет в очереди Frontline и мониторит его выполнение. После того, как команда развития подготовила патч с исправлением и вторая линия поддержки его установила на продуктив, сотрудник Frontline проверяет исправление ошибки и после этого закрывает инцидент в BMC Remedy.
Каждый сотрудник Frontline закреплен за каким то подразделением второй линии и в случае возникновения каких либо вопросов и сомнений может обратиться к коллегам.
А если в потоке тикетов так велика доля запросов, действительно не требующая вмешательства в код/конфиг, то это косвенно указывает на проблемы с продуктом в целом или с понятностью инструкций для пользователей.

Особенность фронт систем в том, что на них «вылезает» всё — и ошибки в работе самой системы, ошибки на бэк системах, ошибки бизнес логики, ошибки сотрудников в процессе оформления продукта, особенности настройки маркетинговых акций и тд.
Мы используем дополнительную классификацию второго уровня в системе BMC Remedy и при закрытии запроса проставляем причину ее возникновения, так выявляя рост ошибок со стороны пользователей, мы можем передать информацию бизнес подразделениям, чтобы они провели доп обучение сотрудников розницы, если увеличивается количество интеграционных ошибок — мы так же сигнализируем об этом необходимым командам и т.д. Задача Frontline не просто закрыть инцидент, а сделать так чтобы их становилось меньше, своего рода Problem Management.
Only those users with full accounts are able to leave comments. Log in, please.