NexTool Solutions

Um inquérito de satisfação a que ninguém responde não gera decisão nenhuma. Este guia mostra como o GLPI realmente dispara, armazena e mede o inquérito de satisfação - de que coluna sai cada configuração, porque é que por vezes simplesmente não é enviado, e o que fazemos na sustentação de ambientes de clientes para tirar a taxa de resposta do chão.

Onde o inquérito é configurado (e porque é por entidade)

Ao contrário do que muita gente procura, o inquérito de satisfação no GLPI não é um botão global: é configurado por entidade, em Administração > Entidades > (selecione a entidade) > separador Assistência. Cada campo do ecrã grava numa coluna da tabela glpi_entities, e o valor pode ser herdado da entidade-pai. Saber a coluna por trás de cada campo é o que permite diagnosticar por SQL quando a interface "diz" que está tudo bem.

O campo Configuração com valor -2 (herdar) é a armadilha silenciosa: uma subentidade pode parecer ativa quando, na verdade, está a herdar "nenhum inquérito" da raiz. As versões mais recentes trouxeram a mesma mecânica às Mudanças, em colunas equivalentes com o sufixo _change.

O gatilho real: o encerramento + o cron, não a resolução

Aqui está a causa número 1 de "o inquérito não sai". O inquérito não nasce quando o ticket é resolvido (estado 5, Resolvido); nasce quando o ticket é fechado (estado 6, Fechado) e, mesmo assim, apenas quando a tarefa de cron createinquest corre e sorteia esse ticket dentro da inquest_rate. São dois pré-requisitos independentes:

1. O ticket tem de fechar. Se o encerramento automático estiver desligado e os técnicos apenas "resolverem", os tickets ficam em Resolvido para sempre e nenhum inquérito é gerado. O encerramento automático é o campo autoclose_delay da própria entidade.
2. O cron tem de correr em modo externo. A tarefa createinquest gera os inquéritos dos tickets fechados. Em modo interno só corre quando alguém carrega uma página - em entidades de baixo tráfego, pode passar dias sem correr.

Foi exatamente esse o caso num ambiente que assumimos: o inquérito estava "ativado" havia meses e a base de dados não tinha uma única resposta. Não era o modelo nem a taxa. O createinquest estava em modo interno (mode = 1) num GLPI de baixo tráfego, por isso o cron praticamente nunca disparava; e, para piorar, o encerramento automático estava desligado, por isso quase nada chegava ao estado Fechado. Ligámos o cron externo do sistema operativo e ajustámos o autoclose_delay: no mesmo dia os inquéritos começaram a ser gerados. Desde então, verificar estes dois pontos passou a ser um item fixo do nosso runbook sempre que assumimos um GLPI.

O cron externo é uma linha no crontab do sistema, executada com o utilizador do PHP:

# /etc/cron.d/glpi - cron externo do GLPI (utilizador do PHP-FPM)
# 1 execução por minuto; processa TODAS as tarefas em modo externo,
# incluindo "createinquest" (geração dos inquéritos de satisfação).
* * * * *  apache  /usr/bin/php /var/www/glpi/front/cron.php >/dev/null 2>&1

E o diagnóstico direto na base de dados confirma se a tarefa está de pé e quando correu pela última vez:

-- Estado da tarefa que gera os inquéritos (usar utilizador só de leitura)
-- state: 0=desativada 1=em espera 2=em execução
-- mode:  1=interno (corre no carregamento de página)  2=externo (cron do SO)
-- frequency: intervalo em segundos (predefinido 86400 = 1 dia)
SELECT name, state, mode, frequency,
       lastrun,
       DATE_ADD(lastrun, INTERVAL frequency SECOND) AS proxima_prevista
FROM glpi_crontasks
WHERE name = 'createinquest';

O modelo da notificação

Com o inquérito gerado, quem convida o utilizador é a notificação. Personalize em Configuração > Notificações > Modelos de notificação, no modelo ligado ao evento de satisfação do Ticket. As tags úteis:

• ##ticket.urlsatisfaction## - ligação direta e autenticada para o inquérito (a mais importante).
• ##ticket.id## e ##ticket.title## - referência para o utilizador se lembrar do atendimento.
• ##satisfaction.text## / ##satisfaction.type## - texto e tipo do inquérito.

O erro comum aqui é caprichar num e-mail longo: quanto mais texto antes da ligação, menor a conversão. Uma linha de contexto, a ligação e ponto.

Medir a taxa de resposta a sério

A média honesta de resposta a inquéritos por e-mail situa-se na faixa dos 10% aos 20%; tratar 30% como "mau" é irrealista. Todas as respostas vivem em glpi_ticketsatisfactions, uma linha por inquérito gerado. Quando não foi respondido, date_answered fica nulo - é assim que se separa "enviado" de "respondido":

-- Taxa de resposta e média (últimos 90 dias), utilizador só de leitura
-- type: 1=interno (estrelas)  2=externo (URL)
-- satisfaction: 0 a 5; date_answered nulo = ainda não respondido
SELECT
    COUNT(*)                                                   AS gerados,
    SUM(date_answered IS NOT NULL)                            AS respondidos,
    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);

Repare que a média só considera quem respondeu. Calcular a média sobre todas as linhas (incluindo os nulos) suja o número e foi outra distorção que já corrigimos num relatório de cliente.

Tirar a taxa de resposta do chão

Configuração correta é pré-requisito; volume de respostas é outra batalha. O que funciona na prática:

• Bloquear novos tickets até responder com o módulo Pending Survey: o utilizador reencontra o inquérito pendente ao tentar abrir o ticket seguinte. É o que mais move o ponteiro.
• Reduzir o inquest_delay para gerar o inquérito perto do encerramento, enquanto o atendimento ainda está fresco na memória.
• Notificar por outro canal além do e-mail, por exemplo via WhatsApp.
• Manter simples: 1 nota e 1 comentário opcional. Um inquérito longo derruba a conversão.

Uma armadilha da inquest_rate: o sorteio acontece no momento do cron e não é retroativo. Baixar de 100% para 30% não "cancela" inquéritos já gerados, e voltar a subir não recupera os tickets que já passaram - a marca de água max_closedate só avança.

Precisa de satisfação a medir a sério, com um cron fiável e uma taxa de resposta saudável? A sustentação de GLPI da NexTool assume a configuração, a monitorização do cron e os relatórios mensais para a sua operação. Conheça o serviço de suporte e sustentação.

Revisto pela equipa NexTool Solutions.