NexTool Solutions

Pesquisa de satisfação que ninguém responde não gera decisão nenhuma. Este guia mostra como o GLPI realmente dispara, armazena e mede a pesquisa de satisfação - de qual coluna sai cada configuração, por que ela às vezes simplesmente não é enviada, e o que fazemos na sustentação de ambientes de clientes para tirar a taxa de resposta do chão.

Onde a pesquisa é configurada (e por que é por entidade)

Ao contrário do que muita gente procura, a pesquisa de satisfação no GLPI não é um botão global: ela é configurada por entidade, em Administração > Entidades > (selecione a entidade) > aba Assistência. Cada campo da tela grava em uma 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 certo.

O campo Configuração com valor -2 (herdar) é a pegadinha silenciosa: uma sub-entidade pode parecer ativa e, na verdade, estar herdando "nenhuma pesquisa" da raiz. Versões mais recentes trouxeram a mesma mecânica para Mudanças, em colunas equivalentes com sufixo _change.

O gatilho real: fechamento + cron, não a solução

Aqui mora a causa número 1 de "a pesquisa não sai". A pesquisa não nasce quando o chamado é solucionado (status 5, Solucionado); ela nasce quando o chamado é fechado (status 6, Fechado) e, mesmo assim, apenas quando a tarefa de cron createinquest roda e sorteia aquele chamado dentro da inquest_rate. São dois pré-requisitos independentes:

1. O chamado precisa fechar. Se o fechamento automático estiver desligado e os técnicos apenas "solucionarem", os chamados ficam em Solucionado para sempre e nenhuma pesquisa é gerada. O fechamento automático é o campo autoclose_delay da própria entidade.
2. O cron precisa rodar em modo externo. A tarefa createinquest gera as pesquisas dos chamados fechados. Em modo interno ela só roda quando alguém carrega uma página - em entidades de baixo tráfego, pode passar dias sem rodar.

Foi exatamente esse o caso em um ambiente que assumimos: a pesquisa estava "ativada" havia meses e o banco não tinha uma única resposta. Não era o template nem a taxa. O createinquest estava em modo interno (mode = 1) num GLPI de baixo tráfego, então o cron praticamente nunca disparava; e, para piorar, o fechamento automático estava desligado, então quase nada chegava ao status Fechado. Ligamos o cron externo do sistema operacional e ajustamos o autoclose_delay: no mesmo dia as pesquisas começaram a ser geradas. Desde então, ao assumir qualquer GLPI, checar esses dois pontos virou item fixo do nosso runbook.

O cron externo é uma linha no crontab do sistema, executada com o usuário do 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

E o diagnóstico direto no banco confirma se a tarefa está de pé e quando rodou pela última vez:

-- 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';

O template da notificação

Com a pesquisa gerada, quem convida o usuário é 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## - link direto e autenticado para a pesquisa (o mais importante).
• ##ticket.id## e ##ticket.title## - referência para o usuário lembrar do atendimento.
• ##satisfaction.text## / ##satisfaction.type## - texto e tipo da pesquisa.

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

Medindo a taxa de resposta de verdade

A média honesta de resposta de pesquisas por e-mail fica na faixa de 10% a 20%; tratar 30% como "ruim" é irreal. Todas as respostas moram em glpi_ticketsatisfactions, uma linha por pesquisa gerada. Quando não foi respondida, date_answered fica nulo - é assim que se separa "enviada" de "respondida":

-- 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);

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

Tirando 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 chamados até responder com o módulo Pending Survey: o usuário reencontra a pesquisa pendente ao tentar abrir o próximo chamado. É o que mais move o ponteiro.
• Reduzir o inquest_delay para gerar a pesquisa perto do fechamento, 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. Pesquisa longa derruba a conversão.

Uma pegadinha da inquest_rate: o sorteio acontece no momento do cron e não é retroativo. Baixar de 100% para 30% não "cancela" pesquisas já geradas, e subir de novo não recupera os chamados que já passaram - o max_closedate só anda para frente.

Precisa de satisfação medindo de verdade, com cron confiável e taxa de resposta saudável? A sustentação de GLPI da NexTool assume a configuração, o monitoramento do cron e os relatórios mensais para a sua operação. Conheça o serviço de suporte e sustentação.

Revisado pela equipe NexTool Solutions.