Назначить каждую заявку нужному специалисту кажется тривиальной задачей, но в реальных службах поддержки это ручное решение становится узким местом: кто-то должен просмотреть очередь, понять категорию и передать заявку — а тем временем часы SLA уже тикают. Модуль Smart Assign от NexTool автоматизирует этот этап по категориям, применяя балансировку нагрузки или последовательную ротацию между специалистами ответственной группы в тот самый момент, когда заявка создаётся.
Проблема
В работе без автоматического назначения всегда есть единая точка принятия решений: кто-то открывает очередь только что созданных заявок, читает категорию и тему и решает, кому их передать. Эта роль обычно достаётся координатору или самому опытному аналитику — то есть именно тому специалисту, которого меньше всего хочется занимать рутинной сортировкой.
На практике последствия проявляются двояко. Во-первых, в часы пик очередь растёт, потому что заявку ещё никто не взял: она существует, открыта, но остаётся без ответственного, пока идёт срок. Во-вторых, распределение становится неравномерным: у одного специалиста накапливается пятнадцать заявок, а у другого три — не из-за компетенций, а из-за того, кто в тот момент смотрел на экран. Оба сценария подрывают SLA и восприятие качества пользователем.
Smart Assign убирает этого посредника. Как только заявка создана, модуль проверяет настроенные правила и определяет ответственного ещё до того, как человек откроет очередь. Сортировка перестаёт зависеть от того, кто дежурит у экрана.
Как работает Smart Assign
Модуль срабатывает на хуке создания заявок GLPI: уже существующие заявки не перераспределяются. Распределение включается по категориям, специалист выбирается из ответственной группы категории, а режим распределения, выбранный на вкладке «Функциональность» модуля, действует для всей среды:
- Распределение по категориям — в каждой категории ITIL вкладка Smart Assign включает или отключает распределение и показывает ответственную группу, доступных специалистов и критерий выбора. Идеально для специализированных команд, где у каждого направления (инфраструктура, ERP, сети) своя группа.
- Специалисты ответственной группы — участвуют активные специалисты ответственной группы категории, с возможностью исключить руководителей группы; кто получит заявку, решает один из двух режимов ниже.
- Режим балансировки (меньше заявок) — заявка уходит специалисту группы с наименьшим количеством открытых заявок на данный момент. Выравнивается реальная нагрузка, а не теоретическая.
- Режим ротации (последовательный) — заявки распределяются по порядку, одному специалисту за другим, независимо от нагрузки. Полезно, когда у всех сопоставимая производительность и объём не является критерием.
- Автоматическая адаптация — когда кто-то входит в группу или покидает её, ротация и балансировка подстраиваются сами, без ручной перенастройки.
- Отдельный журнал — каждое решение сохраняется в базе и отображается на вкладке «Журналы» модуля, с указанием причины, если заявка не была распределена, что даёт прослеживаемость для аудита процессов и для разбора жалоб «почему эта заявка досталась мне».
Smart Assign и встроенные бизнес-правила
GLPI уже частично решает эту задачу с помощью бизнес-правил для заявок (Настройки > Правила). Они могут назначать по таким критериям, как категория, но статично: всегда указывают на одного и того же адресата. Таблица ниже показывает, где заканчивается каждый подход:
| Функция | Встроенные бизнес-правила | Smart Assign |
|---|---|---|
| Назначение по категории или группе | Да (фиксированный адресат) | Да, между специалистами ответственной группы категории |
| Балансировка по нагрузке (меньше открытых заявок) | Нет | Да |
| Последовательная ротация (round-robin) | Нет | Да |
| Адаптация к входу/выходу специалиста из группы | Вручную | Автоматически |
| Отдельная запись решения о назначении | Общая история | Вкладка «Журналы» модуля, с причиной, если распределение не выполнено |
Как включить
- Установите плагин NexTool в GLPI.
- Перейдите в Настройки > NexTool > Модули.
- Включите модуль Smart Assign.
- На вкладке Функциональность модуля выберите режим распределения (балансировка или ротация), действующий для всей среды, и способ подсчёта нагрузки (по группе или по категории). Затем в каждой категории ITIL включите распределение на вкладке Smart Assign и проверьте ответственную группу.
- Создайте тестовую заявку в настроенной категории и проверьте назначенного специалиста в самой заявке и на вкладке Журналы модуля.
Что мы узнали на практике
При сопровождении клиентских служб чаще всего ломается не отсутствие правила, а «правило, указывающее на конкретного человека». Клиент создаёт встроенное бизнес-правило, отправляющее всю категорию «Сеть» специалисту X. Это работает месяцами, пока специалист X не уходит в отпуск: заявки продолжают назначаться ему, простаивают, и SLA тихо нарушается, потому что у очереди «был ответственный». Типичная ошибка — путать наличие владельца с наличием обслуживания. Поэтому для групп из более чем трёх специалистов мы переводим такие статичные правила на режим балансировки Smart Assign: вместо фиксированного имени заявка попадает к тому, у кого в эту минуту меньше нагрузки, а ушедший в отпуск перестаёт получать заявки, как только его убирают из ответственной группы или деактивируют в GLPI. Деталь, которая видна только на практике: балансировка считает открытые заявки, а не закрытые за день, поэтому специалист, который решает быстро, снова скоро начинает получать заявки — так выравнивается реальная нагрузка, а не теоретическая.
Тот же подсчёт, который модуль использует для выбора адресата, можно воспроизвести в базе, чтобы проверить распределение. Этот запрос выводит открытые заявки по назначенному специалисту — ровно то число, которое режим балансировки минимизирует, когда нагрузка считается по группе (по умолчанию):
SELECT u.name AS technician, COUNT(t.id) AS open_tickets
FROM glpi_tickets t
JOIN glpi_tickets_users tu ON tu.tickets_id = t.id AND tu.type = 2
JOIN glpi_users u ON u.id = tu.users_id
WHERE t.status IN (1,2,3,4) -- new, processing, planned, pending
AND t.is_deleted = 0
GROUP BY u.id
ORDER BY open_tickets DESC;Каждое решение записывается на вкладке «Журналы» модуля, в стандартной таблице GLPI с фильтрами по уровню, событию, заявке и специалисту: кому была назначена заявка, а если не была — причина (неактивная категория, категория без ответственной группы или группа без доступного специалиста). Это значительно сокращает разбор вопроса «почему эта заявка досталась мне».
Кому подходит (и когда не использовать)
Smart Assign приносит явную пользу:
- Командам из трёх и более специалистов, где неравномерное распределение повторяется.
- Службам поддержки с пиками нагрузки, где координатор становится узким местом сортировки.
- Средам с чётко определёнными категориями и специализированными по направлениям командами.
- Организациям, которым нужно доказывать на аудите, как распределялись заявки.
Когда это не имеет смысла: в командах из одного-двух специалистов выигрыш минимален — ручное распределение ничего не стоит. А когда назначение зависит от чувствительного контекста (VIP-клиент, конкретный эксперт по критичной системе), такую тонкую маршрутизацию лучше оставить встроенным бизнес-правилам; в этом случае используйте Smart Assign для обычного потока, а встроенные правила — для исключений, вместо того чтобы накладывать два решения на одну и ту же заявку.
Совместимость
- GLPI: 10.x и 11.x
- Тариф: FREE
- Плагин: NexTool 6.10.1+
- PHP: 8.0+
Следующий шаг
Smart Assign входит в состав NexTool — модульного плагина для GLPI. Познакомьтесь с другими модулями или свяжитесь с командой, чтобы получить демонстрацию в вашей среде.
Проверено командой NexTool Solutions.
