ВЛ
Не смог пройти мимо) В работе саппорта есть один важный параметр FCR (first call resolution), это процент решённых запросов без переадресации на старшую линию поддержки. У вас проблемы на самом деле нет, картина достаточно стандартная: L1 регистрирует/маршрутизирует + пытается решить. L2 - копает вглубь, пока хватает базовых навыков и доступов, что бы поправить код или решить inc. Как правило L1-L2 отрабатывают достаточно оперативно, у них фокус усилий именно на этом. А вот L3 это реально жеппа. В большинстве случаев L3 это скиловые спецы, у которых ваши тикеты идут третьими с конца по приоритетам и если начинать смещать фокус на устранение Inc, то они скорее всего со временем уйдут, т.к. такая работа это не по уровню, у них задача замерять на основе inc, качество реализованного функционала и копаться в коде будут разве что при устранении корневой причины группы Inc, чем решать конкретный кейс конкретного пользователя. Это, скажем так, из наблюдений. Чтобы как-то начать исправлять ситуацию, обратиться придется не к технической стороне вопроса, а к организационной и первым делом я бы задумался, как увеличить этот самый FCR. Чуть более 10 лет назад решая такую же задачу я проделывал такую штуку: каждую неделю -две я выдергивал одного сотрудника из L2 и направлял на стажировку к L3, предварительно договорившись с руководителями профильных функций. Основная задача - поиск простых типовых операций, которые можно отнести к рутинным, но результат выполнения которых дает профит. За это время к инженеру L2 прилипало +2 к умениям и +5 к навыкам, после чего он возвращался обратно и уже мог делать самостоятельно чуть больше чем раньше (некоторые проблемы легко решаются путем повышения прав доступа). Потом следующий и т.д. Спустя N времени и прокачки скилов ставится задача составить перечень рутинных операций на L3, которые можно упаковать в простой скрипт и запуск которого не поломает систему, но исправит бажулю, причем не обязательно даже через повышение прав. После получения новых инструментов быстрого вмешательства и исправления с выполнением контрольной процедуры проверки, кол-во запросов на L3 начинает сокращаться. Мотивация для L3 - от них наконец то отстанут с "дурацкими" Inc от клиентов. Для L2 - добавление полномочий, апгрейд навыков, установление новых границ развития навыков + рост кол-ва решённых запросов в нормативное время. Тоже самое с L1. Постепенно нужно приучать операторов выполнять некоторые операции самостоятельно, что бы они смотрели немного глубже в специфику inc, а не просто их форвардили дальше без погружения в детали. Shadow support и reverse shadow support между L2 и L3 это по сути процесс skill transition, но за счёт смещения фокуса (у L2 - Inc, у L3 - проблемы или full debug) скорость решения начинает расти. Shadow support - L2 наблюдает за тем, как L3 осуществляет поддержку, т.е. face-2-face народ сидит и обрабатывает тикеты. Обычно на этом этапе вскрывается весь реальный пипец, который отгребает L3.
Reverse shadow support - L2 при поддержке L3 пытается обработать тикеты. L3 проверяют и подсказывают. В свое время по такой схеме удалось довести долю FCR до 70% (с 15 примерно) на L1-L2 и запросы стали решаться практически online. А L3 получив больше времени на работу с более серьезными проблемами поняли, что передача рутинных операций на младшие линии бережет их от лишнего геморроя/стресса, поэтому они сами в последствии стараются скинуть с себя этот головняк. Ещё один профит - L3 получает источник для пополнения кадров, потому как где ещё искать спецов с развитым навыком решения Inc, которых можно погружать дальше в разработку не вкладываясь особо в наставничество с минимальным сроком ввода в новую должность. Есть и другие трюки, которые зависят от профиля компании, тематик, специфики запросов, но это уже другая история. Как-то так:)
Reverse shadow support - L2 при поддержке L3 пытается обработать тикеты. L3 проверяют и подсказывают. В свое время по такой схеме удалось довести долю FCR до 70% (с 15 примерно) на L1-L2 и запросы стали решаться практически online. А L3 получив больше времени на работу с более серьезными проблемами поняли, что передача рутинных операций на младшие линии бережет их от лишнего геморроя/стресса, поэтому они сами в последствии стараются скинуть с себя этот головняк. Ещё один профит - L3 получает источник для пополнения кадров, потому как где ещё искать спецов с развитым навыком решения Inc, которых можно погружать дальше в разработку не вкладываясь особо в наставничество с минимальным сроком ввода в новую должность. Есть и другие трюки, которые зависят от профиля компании, тематик, специфики запросов, но это уже другая история. Как-то так:)
Супер! Спасибо
