NexTool Solutions

Опрос удовлетворённости, на который никто не отвечает, не приводит ни к каким решениям. В этом руководстве показано, как GLPI на самом деле запускает, хранит и измеряет опрос удовлетворённости, — из какого столбца берётся каждая настройка, почему опрос иногда просто не отправляется и что мы делаем при сопровождении клиентских сред, чтобы поднять долю ответов с нуля.

Где настраивается опрос (и почему для каждой организации отдельно)

Вопреки тому, что многие ищут, опрос удовлетворённости в GLPI — это не глобальная кнопка: он настраивается для каждой организации в Администрирование > Организации > (выберите организацию) > вкладка Поддержка. Каждое поле экрана записывается в столбец таблицы glpi_entities, а значение может наследоваться от родительской организации. Зная столбец за каждым полем, можно диагностировать проблему через SQL, когда интерфейс «говорит», что всё в порядке.

Поле Конфигурация со значением -2 (наследовать) — тихая ловушка: дочерняя организация может выглядеть включённой, а на самом деле наследовать «без опроса» от корневой. В более новых версиях тот же механизм появился и для изменений, в аналогичных столбцах с суффиксом _change.

Настоящий триггер: закрытие + cron, а не решение

Здесь кроется причина номер 1 того, что «опрос не уходит». Опрос не создаётся, когда заявка решена (статус 5, Решена); он создаётся, когда заявка закрыта (статус 6, Закрыта), и даже тогда — только когда запускается задача cron createinquest и выбирает эту заявку в пределах inquest_rate. Это два независимых условия:

1. Заявка должна закрыться. Если автоматическое закрытие выключено, а специалисты только «решают» заявки, они навсегда остаются в статусе Решена, и ни один опрос не создаётся. Автоматическое закрытие — это поле autoclose_delay той же организации.
2. Cron должен работать во внешнем режиме. Задача createinquest создаёт опросы для закрытых заявок. Во внутреннем режиме она запускается только тогда, когда кто-то загружает страницу, — в организациях с низким трафиком она может не запускаться днями.

Именно так было в одной среде, которую мы взяли на сопровождение: опрос был «включён» уже несколько месяцев, а в базе не было ни одного ответа. Дело было не в шаблоне и не в доле. createinquest работал во внутреннем режиме (mode = 1) в GLPI с низким трафиком, поэтому cron практически никогда не срабатывал; вдобавок автоматическое закрытие было выключено, так что почти ничего не доходило до статуса Закрыта. Мы включили внешний cron операционной системы и настроили autoclose_delay: в тот же день опросы начали создаваться. С тех пор, беря любой GLPI на сопровождение, мы проверяем эти два пункта — это постоянный элемент нашего регламента.

Внешний cron — это одна строка в системном crontab, выполняемая от имени пользователя PHP:

# /etc/cron.d/glpi - cron externo do GLPI (usuário do PHP-FPM)
# 1 disparo por minuto; processa TODAS as tarefas em modo externo,
# inclusive "createinquest" (geração das pesquisas de satisfação).
* * * * *  apache  /usr/bin/php /var/www/glpi/front/cron.php >/dev/null 2>&1

А диагностика прямо в базе подтверждает, работает ли задача и когда она запускалась в последний раз:

-- Estado da tarefa que gera as pesquisas (usar usuário somente-leitura)
-- state: 0=desabilitada 1=aguardando 2=rodando
-- mode:  1=interno (roda em page load)  2=externo (roda no cron do SO)
-- frequency: intervalo em segundos (padrão 86400 = 1 dia)
SELECT name, state, mode, frequency,
       lastrun,
       DATE_ADD(lastrun, INTERVAL frequency SECOND) AS proxima_prevista
FROM glpi_crontasks
WHERE name = 'createinquest';

Шаблон уведомления

Когда опрос создан, пользователя приглашает уведомление. Настройте его в Настройки > Уведомления > Шаблоны уведомлений, в шаблоне, связанном с событием удовлетворённости для Ticket. Полезные теги:

• ##ticket.urlsatisfaction## — прямая ссылка на опрос с авторизацией (самое важное).
• ##ticket.id## и ##ticket.title## — чтобы пользователь вспомнил, о каком обращении речь.
• ##satisfaction.text## / ##satisfaction.type## — текст и тип опроса.

Типичная ошибка здесь — старательно писать длинное письмо: чем больше текста перед ссылкой, тем ниже конверсия. Одна строка контекста, ссылка — и всё.

Как на самом деле измерить долю ответов

Честная средняя доля ответов на опросы по e-mail — в диапазоне от 10% до 20%; считать 30% «плохим» результатом нереалистично. Все ответы хранятся в glpi_ticketsatisfactions, по одной строке на каждый созданный опрос. Если ответа не было, date_answered остаётся пустым — так отличают «отправлен» от «отвечен»:

-- Taxa de resposta e média (últimos 90 dias), usuário somente-leitura
-- type: 1=interna (estrelas)  2=externa (URL)
-- satisfaction: 0 a 5; date_answered nulo = ainda não respondida
SELECT
    COUNT(*)                                                   AS geradas,
    SUM(date_answered IS NOT NULL)                            AS respondidas,
    ROUND(100 * SUM(date_answered IS NOT NULL) / COUNT(*), 1) AS taxa_resposta_pct,
    ROUND(AVG(CASE WHEN date_answered IS NOT NULL
                   THEN satisfaction END), 2)                 AS media_0a5
FROM glpi_ticketsatisfactions
WHERE date_begin >= DATE_SUB(CURDATE(), INTERVAL 90 DAY);

Обратите внимание: среднее учитывает только тех, кто ответил. Расчёт среднего по всем строкам (включая пустые) искажает число — это ещё одно искажение, которое мы уже исправляли в отчёте клиента.

Как поднять долю ответов с нуля

Правильная настройка — обязательное условие; количество ответов — отдельная битва. Что работает на практике:

• Блокировать новые заявки до ответа с помощью модуля Pending Survey: пользователь снова видит неотвеченный опрос, когда пытается создать следующую заявку. Это даёт самый заметный эффект.
• Сократить inquest_delay, чтобы опрос создавался ближе к закрытию, пока обращение ещё свежо в памяти.
• Уведомлять по другому каналу, помимо e-mail, например через WhatsApp.
• Сохранять простоту: 1 оценка и 1 необязательный комментарий. Длинный опрос снижает конверсию.

Ловушка inquest_rate: случайный выбор происходит в момент работы cron и не имеет обратной силы. Снижение со 100% до 30% не «отменяет» уже созданные опросы, а повторное повышение не возвращает уже прошедшие заявки — max_closedate движется только вперёд.

Нужен опрос удовлетворённости, который действительно измеряет, с надёжным cron и здоровой долей ответов? Сопровождение GLPI от NexTool берёт на себя настройку, мониторинг cron и ежемесячные отчёты для вашей службы поддержки. Узнайте об услуге поддержки и сопровождения.

Проверено командой NexTool Solutions.