Классика тех.поддержки – разбиение ее на три линии. Обычно их называют L1, L2 и L3.
Первая линия – специалисты начального уровня, обычно какие-нибудь студенты, которые работают либо сменно, либо стандартные 5/2, в зависимости от необходимости обеспечить суппорт круглосуточно.
Их задача – принять заявку (через почту, систему постановки задач, по телефону или через колл-центр – тоже все зависит от ваших задач), понять ее важность и отношение к тому или иному проекту, и передать ее дальше по цепочке на вторую линию, если проблема действительно имеется. L1 может выполнять какие-то совсем несложные действия, например, делать сброс пароля для пользователя, если он его забыл и хочет восстановить.
Если L1 не может разобраться с заявкой, то она переводит задачу на вторую линию, там сидят уже более подкованные ежи, которые знают систему, имеют кое-какие доступы, в некоторых случаях даже доступы к базам. Тут проводится более детальный разбор полетов, уточняются причины, поднимаются логи. Инженер L2 – это уже что-то типа начинающего программера, он может попробовать воспроизвести проблему, собрать логи, выявить количество пострадавших и т.д. Если L2 не может решить проблему, то он переводит задачу на L3.
На L3 обычно сидят обычные боевые разработчики, которые работают по спринтам и решают бизнес-задачи. К ним попадают проблемы, которые по сути являются багами и которые надо править. В зависимости от количества пострадавших определяется приоритет. Их достаточно два – немедленный и обычный. Если теряются деньги или другие бизнес-критикал параметры страдают, то приоритет немедленный – бросаем всё и чиним всеми силами. L3 может быть выделенной группой, а может быть дежурным программистом.
У админов аналогичное разбиение, есть L1, L2 и L3.
Заявки принимает L1, например, это четыре человека, которые работают посменно 12-часовыми сменами в режиме «два через два».
L1 маршрутизируют заявки и выполняют несложные операции типа настройки компов в ночные смены, когда заявок немного. L2 занимается заведением доступов, почты и прочими несложными задачами. Задачи L3 – это уже поднятие серверов, настройка сети и т.д.
Хорошая практика делать службу единого окна, то есть если у вас несколько проектов, то для пользователей хорошо сделать единую точку входа, то есть единый L1 для всех проектов, чтобы пользователям было проще. В случае любой проблемы – пишите на почту, например.
Оценивать качество поддержки можно по количеству удовлетворенных качеством решения проблем пользователей.
На уровне идей так:
- Нормализовать KPI для всех: плясать от процента удовлетворенных пользователей, а не от их количества.
- Если хотите поощрять тех, кто больше работает, то можно ввести какой-то поправочный коэффициент, который это бы учитывал.
- Можно добавить в формулу время первичной реакции с каким-то понижающим коэффициентом, чтобы оно не сильно учитывалось, если сотрудник отвечает вовремя, но сильно учитывался в случае факапа срока.
- Добавить в формулу KPI в качестве параметра время решения проблемы.
Например, автоматом можно считать метрики первого ответа и решения проблемы – на это есть SLA, пользователь по решению проблемы ставит пятибалльную оценку (ему приходит письмо, мол, оцените качество). На основе этого и генерируется итоговая оценка суппортера. По сути, это та же формула, только вопрос в развесовке критичных для тебя параметров.
Если считаете, что время ответа в случае соблюдения SLA не критично – понижаете коэффициент, но задираете в случае несоблюдения. Какой-то серебряной пули, которая подойдет всем, тут нет. Надо понять, что подходит именно вам, и подтюнь систему.
Хорошей идеей кажется сначала обкатать систему в режиме dry-run на 2-3 сотрудниках в тестовом режиме, просто посчитав, соответствует ли полученная формула вашим ожиданиям. И если да, то уже можно масштабировать на всю банду.