Um inquérito de satisfação que ninguém responde não mede nada. O módulo Pending Survey do NexTool resolve isto de frente: enquanto houver inquéritos pendentes, o utilizador não consegue abrir novos tickets pelo catálogo de serviços. Na sustentação de centros de serviço, aprendemos que a taxa de resposta não sobe com mais lembretes por e-mail - sobe quando responder deixa de ser opcional para continuar a usar o portal.
O problema
O GLPI oferece inquérito de satisfação nativo ao fechar tickets, mas a taxa de resposta costuma ser dececionante. Sem estímulo, o utilizador ignora a ligação enviada por e-mail e abre o ticket seguinte normalmente. O resultado é um volume de dados insuficiente para medir qualidade: as equipas que precisam de NPS ou CSAT fiáveis vivem o mesmo ciclo frustrante - a ferramenta tem a funcionalidade, mas os dados nunca chegam em massa.
A abordagem clássica de disparar lembretes por e-mail tem retorno marginal. O que muda o jogo é condicionar o próximo acesso ao catálogo à conclusão dos inquéritos anteriores. É exatamente isso que o Pending Survey faz, sem tocar no fluxo de quem já respondeu.
Como funciona o Pending Survey
O módulo interceta o acesso ao /ServiceCatalog do GLPI e verifica quantos inquéritos de satisfação estão pendentes para o utilizador autenticado. O comportamento é graduado em dois níveis:
- 1 inquérito pendente - alerta suave, com opção de dispensar. O utilizador é lembrado, mas continua a abrir o ticket.
- 2 ou mais inquéritos pendentes - bloqueio total. O catálogo é substituído por um ecrã com ligações diretas para responder a cada inquérito. Não há forma de dispensar.
O módulo respeita a configuração nativa de expiração de inquéritos (max_closedate): um inquérito vencido não conta como pendente e não bloqueia o utilizador em vão. Há isenções automáticas para técnicos e super-admins, além de isenções configuráveis por utilizador e por grupo. Funcionalidades principais:
- Bloqueio condicional do catálogo - dois níveis: alerta suave e bloqueio total.
- Ligações diretas para os inquéritos - o utilizador vê exatamente o que responder e acede com um clique.
- Isenções flexíveis - técnicos, super-admins e grupos específicos nunca são bloqueados.
- Interface responsiva - o ecrã de bloqueio funciona bem no telemóvel.
- Limiar configurável - o número de inquéritos que dispara o bloqueio total é ajustável.
Pending Survey vs lembrete por e-mail (nativo)
A diferença não é fazer mais lembretes, é escolher o momento da intervenção:
| Critério | Lembrete por e-mail (nativo) | Pending Survey |
|---|---|---|
| Momento da intervenção | Depois, na caixa de entrada | No próximo acesso ao catálogo |
| Efeito na taxa de resposta | Marginal | Sobe ao condicionar o acesso |
| Granularidade | Ligado ou desligado | Alerta suave (1) e bloqueio (2+) |
| Isenções | Não se aplica | Técnicos, super-admins, grupos |
| Respeita a expiração do inquérito | Não se aplica | Sim, via max_closedate |
| Fricção com o utilizador | Baixa, mas ignorável | Graduada e reversível no nível 1 |
Como ativar
- Instale o plugin NexTool no GLPI.
- Aceda a Configuração > NexTool > Módulos.
- Localize o cartão Pending Survey e clique em Instalar, depois Ativar.
- Nas definições, ajuste o limiar, ative o alerta suave e defina os utilizadores e grupos isentos.
Antes de ligar: meça quem seria bloqueado
O erro que mais custa é ligar o bloqueio total sem medir o stock de inquéritos pendentes. Se metade da base tem dois ou mais pendentes, acabou de barrar meia empresa no dia do arranque - e o telefone toca. Antes de ativar, execute esta consulta para dimensionar o impacto (ajuste os nomes conforme a sua versão do GLPI):
-- Utilizadores com 2+ inqueritos iniciados e ainda sem resposta
SELECT u.name AS utilizador, COUNT(*) AS pendentes
FROM glpi_ticketsatisfactions ts
JOIN glpi_tickets t ON t.id = ts.tickets_id
JOIN glpi_users u ON u.id = t.users_id_recipient
WHERE ts.date_answered IS NULL
AND ts.date_begin IS NOT NULL
GROUP BY u.id
HAVING pendentes >= 2
ORDER BY pendentes DESC;Na sustentação, medimos o mesmo padrão em vários clientes: os lembretes de inquérito por e-mail rendem percentagens de um dígito; ao condicionar o catálogo, a resposta sobe de forma consistente. Mas o outro erro comum é traiçoeiro: esquecer a isenção e travar a própria equipa. Já vimos um analista sénior sem conseguir abrir um pedido interno por causa de inquéritos antigos pendentes. Por isso a regra é: isente técnicos e gestores antes de subir o limiar, e comece pelo alerta suave uma ou duas semanas antes de ativar o bloqueio total.
Para quem é indicado (e quando não usar)
O módulo é recomendado para centros de serviço que precisam de elevar a taxa de resposta dos inquéritos, gestores que dependem de NPS ou CSAT com confiança estatística e organizações sujeitas a auditorias de qualidade que exigem indicadores de satisfação consistentes.
Quando não usar: se o catálogo é o único canal de abertura e existe um SLA de tempo para abrir o ticket, o bloqueio total pode tornar-se uma violação de SLA - nesse caso, fique só no alerta suave. E em culturas onde barrar o utilizador final é politicamente inviável, use o nível 1 como lembrete permanente e não acione o bloqueio. O objetivo é o dado de satisfação, não a guerra com quem abre o ticket.
Compatibilidade
- GLPI: 10.x e 11.x
- Plano: Licenciado
- Plugin: NexTool 3.x+
Próximo passo
O Pending Survey faz parte do NexTool, plugin modular para GLPI. Conheça todos os módulos ou fale com a equipa.
Este conteúdo foi produzido com auxílio de inteligência artificial e revisado pela equipe Nextool Solutions.
