Ручная маршрутизация (cherry-pick)
Самый простой и самый плохой подход в чистом виде. Все новые заявки лежат в общей очереди, операторы открывают список и берут что хотят. Что происходит:
- Опытные операторы хватают сложные заявки (профессиональный интерес, рост репутации)
- Новички берут простые (страх не справиться)
- «Невкусные» заявки (с грубыми пользователями, по непопулярным услугам) висят неделями
- Самые быстрые операторы оказываются загружены вдвое больше остальных
Когда cherry-pick всё-таки работает: в команде < 3 человек и зрелой (нет новичков), где есть культура «сам беру по нагрузке». Тогда люди договариваются естественным образом.
Полу-ручной режим, который работает лучше: триаж + cherry-pick. Один дежурный (роль ротируется) присваивает каждой новой заявке команду + примерный приоритет за 5 минут после поступления. Дальше внутри команды операторы берут сами. Это сохраняет автономность, но избавляет от «висящих» нераспределённых заявок.
Round-robin — по очереди
Автоматическое распределение «каждой новой заявке — следующий в списке оператор». Просто и справедливо в смысле количества заявок.
Проблема: заявки не равны. У одного оператора 12 заявок «сбросить пароль» (3 минуты каждая), у другого — 12 заявок «разобраться, почему не работает интеграция с 1С» (по 2 часа). Round-robin распределяет поровну по количеству, не по сложности.
Когда round-robin работает: при однородной нагрузке. Например, если 80% заявок — это типовые операции (доступы, пароли, простые установки), а сложных мало. Тогда «вес» каждой заявки примерно одинаков, и round-robin даёт справедливое распределение.
Weighted round-robin — улучшенная версия. У каждого оператора есть «капасити» (10 одновременно открытых заявок), и новая идёт тому, у кого свободных слотов больше. Это лучше учитывает реальную загрузку, но всё ещё игнорирует сложность.
Skill-based routing — по навыкам
Заявка маршрутизируется тому, кто умеет её решать. Реализуется через теги навыков на операторах и категории на заявках:
- Оператор Иванов умеет: Active Directory, 1С Бухгалтерия, Bitrix24
- Оператор Петрова умеет: Linux, Docker, мониторинг
- Заявка «не работает 1С после обновления» → ищет операторов с навыком 1С → Иванов
Если несколько операторов подходят — берётся тот, у кого меньше открытых заявок (weighted skill-based).
Где skill-based выигрывает:
- В крупных командах (10+ операторов) с разной специализацией
- При сложных тикетах, где «универсальный» оператор будет тратить часы на разбор того, что специалист сделает за 20 минут
- В MSP-сценариях (несколько клиентов с разным стеком технологий)
Где не работает: маленькие команды, где все +/- умеют всё. Тогда skill-based вырождается в round-robin с лишней admin-нагрузкой по ведению навыков.
Комбинированные стратегии
В реальности зрелые команды редко используют один подход в чистом виде. Типовая работающая комбинация:
- Триаж (либо дежурный, либо автоправила) — определяет приоритет и команду за 5 минут после создания заявки
- Внутри команды — skill-based для сложных, round-robin для простых
- Cherry-pick на «общей доске» — все нераспределённые висят в общем списке, операторы могут взять оттуда, если есть свободное время
В TIQQET это реализовано через правила автомаршрутизации: условия (категория = «доступ к 1С» AND приоритет = high) → действия (assign team «1С-эксперты», priority = high, notify lead). Правила запускаются на событии создания заявки, и пользователь сразу видит, что заявка попала к правильным людям.
Если автомаршрутизация не сработала (заявка нестандартная) — она попадает в «нераспределённые» к дежурному триажу. Так не теряется ни одна заявка.
Метрики качества маршрутизации
Как понять, что распределение работает? Несколько метрик:
- Время до первого назначения — медиана от создания заявки до того, как у неё появился assignee. Здоровое значение для рабочих часов — < 5 минут (через автоправила) или < 30 минут (через ручной триаж)
- Reassignment rate — процент заявок, которые перекинули с одного оператора на другого. > 15% — маршрутизация не попадает с первого раза, надо разбирать правила
- Распределение нагрузки (gini coefficient или просто std deviation) по операторам — насколько неравномерна нагрузка. Если у самого загруженного в 3 раза больше открытых заявок, чем у среднего — что-то ломается
- Время решения по «правильному» vs «неправильному» оператору — сравните medianTTR заявок, которые решил skill-эксперт, vs тех, кого взял «неподходящий» оператор. Разница покажет цену плохой маршрутизации
Попробуйте TIQQET в деле
On-premise ServiceDesk с полным циклом заявок, SLA-контролем и мобильными приложениями. Развёртывание за 1 день.
Частые вопросы
Можно ли вообще не маршрутизировать — все берут из общей очереди?
В команде < 3 человек — можно. В команде 5+ — это деградирует в постоянные «висящие» заявки и неравномерную нагрузку. Минимум — автоправила по категориям.
Что делать, если у нас один оператор и один «специалист» на L2?
Cherry-pick для L1 (один оператор сам берёт всё, что приходит), эскалация к L2 по правилу или вручную. Маршрутизация в строгом смысле не нужна, нужны правила эскалации.
Сколько навыков (skills) оптимально для skill-based?
5-15 тегов на категории высокого уровня (1С, AD, Linux, network, hardware, бухгалтерия). Больше — становится сложно вести. Если очень много специализаций — лучше отдельные team вместо отдельных навыков на людях.
Можно ли учитывать в маршрутизации настроение/доступность оператора?
Да, через статусы: «working», «away», «do not assign». Если оператор на встрече — новые заявки идут другим. Это базовая функция в большинстве helpdesk-систем.
Должен ли руководитель команды быть в очереди как assignee?
В качестве fallback — да. Если автоправила не сработали и нет дежурного — заявка должна попасть лиду, чтобы он распределил вручную. Лид не как «обычный исполнитель», но как safety net.