Большинство служб поддержки (Service Desk) работает в реактивном режиме: ждут, пока придёт заявка, и бегут её решать. Воронка обслуживания переворачивает эту логику: каждый слой отфильтровывает спрос до того, как он дойдёт до специалиста. В GLPI воронка не включается одной кнопкой: это сочетание категорий, бизнес-правил, базы знаний и cron, которое нужно измерять и настраивать. В этом руководстве показано, как собрать каждый слой из того, что уже есть в GLPI, и какие ловушки, по нашему опыту сопровождения клиентских сред, уже обрушивали воронки целиком.
Прежде чем строить воронку, измерьте, откуда идёт объём
Самая частая ошибка — строить воронку задом наперёд: создавать десятки общих статей и форм в надежде, что они сократят число заявок. При сопровождении мы делаем наоборот: сначала выясняем, на какие категории приходится основной объём, потому что именно там каждый слой даёт реальную отдачу. Запрос ниже, выполненный под пользователем только для чтения, выводит категории, которые генерируют больше всего спроса за последние 90 дней, и отделяет инциденты от запросов — именно это различие решает, пойдёт ли спрос в самообслуживание или на первую линию (N1):
-- Top categorias por volume (últimos 90 dias): onde as camadas de
-- prevenção e autoatendimento têm o maior retorno. Usar usuário somente-leitura.
-- type: 1 = incidente, 2 = requisição
SELECT
COALESCE(c.completename, '(sem categoria)') AS categoria,
COUNT(*) AS chamados,
SUM(t.type = 1) AS incidentes,
SUM(t.type = 2) AS requisicoes
FROM glpi_tickets t
LEFT JOIN glpi_itilcategories c ON c.id = t.itilcategories_id
WHERE t.is_deleted = 0
AND t.date >= DATE_SUB(CURDATE(), INTERVAL 90 DAY)
GROUP BY t.itilcategories_id
ORDER BY chamados DESC
LIMIT 15;Отсюда следуют два вывода. Категории повторяющихся запросов (сброс пароля, предоставление доступа, стандартная установка) — кандидаты на самообслуживание и автоматизацию: пользователю не должен быть нужен специалист. Категории инцидентов с большим объёмом указывают на повторяющиеся сбои, которые слой профилактики должен перехватывать до того, как пользователь их заметит. А если наверху оказывается «(sem categoria)» (без категории), проблема находится ещё до воронки: сортировка заявок пущена на самотёк, и ни одно правило не может маршрутизировать то, что не классифицировано.
Матрица решений: каждый спрос — в своём слое
Воронка — это не иерархия людей, а маршрутизация спроса. У каждого типа спроса есть правильный слой и встроенный механизм GLPI, который его обеспечивает. Матрица ниже — отправная точка, которую мы используем при проектировании воронки клиента:
| Типичный спрос | Слой | Механизм в GLPI | Признак того, что всё работает |
|---|---|---|---|
| Сбой инфраструктуры (заполнен диск, остановлена служба) | Профилактика | Заявка, созданная мониторингом (Zabbix/Agent) до первого обращения | Инцидент зарегистрирован с источником «мониторинг», а не пользователем |
| Стандартный запрос (сброс пароля, доступ, установка) | Самообслуживание | Пошаговая форма + правило, которое само решает или маршрутизирует | Снижение объёма в соответствующей категории |
| Повторяющийся вопрос («как сделать X») | Самообслуживание | Статья, опубликованная как FAQ (is_faq), видимая на портале | Просмотры статьи без последующей заявки |
| Новый или сложный инцидент | Решение (N1) | Бизнес-правило назначает группу по категории + SLA по приоритету | Доля решённых на N1 без эскалации |
| Повторяющийся структурный сбой | Решение (N2/N3) | Эскалация + регистрация проблемы (Problem), связанной с заявками | Заявки привязаны к Problem, первопричина устранена один раз |
Слой 1 — профилактика: заявка, рождённая мониторингом
Цель этого слоя — заявка, которую команда (или сама система) создаёт до того, как пользователь заметит проблему. На практике:
- Мониторинг создаёт заявку: Zabbix, GLPI Agent или другой сборщик создаёт заявку по e-mail (collector) или через API при превышении порога — диск заполнен на 90%, служба остановлена, сертификат скоро истечёт. Заявка приходит уже с категорией и в группу инфраструктуры.
- Оповещение о плановых работах: объявление на портале и уведомление перед окном работ предотвращают лавину вопросов «а у вас всё упало?».
- Устранение первопричины: повторяющиеся инциденты превращаются в проблему (Problem) в GLPI, которую решают один раз вместо N одинаковых заявок.
Выигрыш измерим: доля профилактики — это процент инцидентов, первая регистрация которых пришла от мониторинга, а не от пользователя. Интеграция Zabbix с GLPI — самый прямой путь к этому слою.
Слой 2 — самообслуживание: опубликовать не значит показать
Здесь кроется ловушка, которая чаще всего убивает слой самообслуживания: команда пишет десятки статей, а портал самообслуживания всё равно ничего не показывает пользователю. В GLPI статья появляется в публичном FAQ только при одновременном выполнении трёх условий:
- статья опубликована (с датой начала действия, а не в черновике);
- она отмечена как видимая в FAQ (поле is_faq);
- у неё задана целевая аудитория, включающая профиль self-service (или «всех»): без аудитории статья видна только своему автору.
Не выполнено одно из трёх — и статья существует в базе, но невидима для тех, кому она нужна. Добавьте к этому видимость категории: категория, не отмеченная как видимая в helpdesk, не появляется в форме создания заявки, и пользователь даже не доходит до самообслуживания через неё. Помимо статей, этот слой включает пошаговые формы (сброс пароля, стандартные обращения), которые решают или маршрутизируют без вмешательства. Начинайте базу знаний с категорий, которые SQL-запрос выше поставил на вершину, а не с руководства по продукту от А до Я.
Слой 3 — решение: маршрутизация по правилу, а не по e-mail
То, что не удалось предотвратить или решить через самообслуживание, должно быстро попасть к тому, кто решает, — и попасть правильно. Двигатель здесь — бизнес-правила для заявок (RuleTicket): они назначают группу, категорию, приоритет и SLA по критериям (категория, источник, слово в заголовке, инициатор). Маршрутизация по правилам проверяема и воспроизводима; маршрутизация по принципу «перешли письмо такому-то» не масштабируется и пропадает, когда этот кто-то уходит в отпуск. Запрос ниже выводит активные правила для заявок в том порядке, в котором GLPI их выполняет:
-- Regras de negócio de chamado (RuleTicket) ativas, na ordem de execução.
-- O GLPI processa por `ranking`; uma ação "parar de processar" numa
-- regra anterior impede as seguintes de rodar. Usar usuário somente-leitura.
SELECT ranking, name, `match` AS operador_criterios, is_active
FROM glpi_rules
WHERE sub_type = 'RuleTicket'
AND is_active = 1
ORDER BY ranking;Порядок (столбец ranking) важен, потому что действие «прекратить обработку» прерывает последующие правила. Типичная ошибка — создать новое правило в конце очереди в расчёте, что оно скорректирует приоритет, не заметив, что предыдущее правило с включённым «прекратить обработку» уже завершило маршрутизацию, и новое никогда не выполняется. Уровни N1/N2/N3 — это группы; эскалация между ними — это правило плюс SLA по приоритету, а не ручное решение в каждом отдельном случае.
Ошибка, которая обрушивает любую воронку: автоматизация, которая никогда не запускается
Можно тщательно собрать все три слоя, и всё равно ничего не будет происходить само. Эскалация SLA, отправка уведомлений, автоматическое закрытие решённых заявок, оповещения — всё это в GLPI зависит от автоматических действий (CronTask), а они надёжно выполняются только тогда, когда GLPI вызывает внешний cron операционной системы. В режиме по умолчанию «GLPI» (запуск при веб-навигации) действия выполняются нерегулярно, зависят от того, зайдёт ли кто-то в интерфейс, и зависают под нагрузкой. Классический симптом, с которым к нам обращаются: «SLA не эскалируется», «уведомление не приходит», «заявка не закрывается сама» — и причина почти всегда одна и та же. Строка ниже решает проблему (скорректируйте путь к корню вашего GLPI и пользователя PHP):
# GLPI - ação automática EXTERNA, a cada 1 minuto, como usuário do PHP.
# Sem isto, SLA/escalonamento, notificações e fechamento automático NÃO rodam.
# Ajuste o caminho para a raiz do seu GLPI (GLPI 10 e 11 usam front/cron.php).
* * * * * www-data /usr/bin/php /var/www/html/glpi/front/cron.php >/dev/null 2>&1Затем в Настройки > Автоматические действия переключите режим задач с «GLPI» на «CLI». Без этого шага значительная часть воронки остаётся декоративной.
Из практики сопровождения: воронка, которая существовала только на бумаге
Взяв на сопровождение уже работающую среду, мы столкнулись с самым распространённым сценарием: воронка была нарисована на слайде, но не в системе. В базе знаний было больше сотни статей — все сохранены как черновики, ни одна не отмечена как FAQ и без целевой аудитории, поэтому портал самообслуживания выглядел для пользователя пустым. Правила назначения существовали, но у третьего из них было включено «прекратить обработку», и оно отправляло половину заявок не в ту группу. А внешний cron так и не был настроен, поэтому SLA не эскалировался, а автоматическое закрытие стояло — бэклог раздувался решёнными заявками, которые никто не подтверждал. Прежде чем что-либо трогать, мы выполнили SQL-запрос объёма по категориям: на сброс пароля и VPN приходилась значительная часть общего числа. Мы опубликовали и отметили как FAQ полдюжины статей по этим двум категориям, исправили порядок правил и включили внешний cron. За несколько недель объём этих категорий заметно снизился в том же отчёте — не потому, что проблема исчезла, а потому, что она перестала превращаться в заявку. Воронка не была новой: она просто никогда не выходила за пределы бумаги.
Построение воронки в GLPI — это меньше про плагины и больше про порядок: измерить объём, маршрутизировать правилами, по-настоящему опубликовать самообслуживание и убедиться, что автоматизация запускается. Сопровождение GLPI от NexTool включает именно такой проект — от матрицы категорий до правил и cron — и ежемесячный контроль, показывающий, как каждый слой сокращает спрос, доходящий до специалиста.
Проверено командой NexTool Solutions.
