NexTool Solutions

Una encuesta de satisfacción que nadie responde no genera ninguna decisión. Esta guía muestra cómo GLPI realmente dispara, almacena y mide la encuesta de satisfacción - de qué columna sale cada ajuste, por qué a veces simplemente no se envía, y qué hacemos al dar soporte a entornos de clientes para levantar la tasa de respuesta del suelo.

Dónde se configura la encuesta (y por qué es por entidad)

Al contrario de lo que muchos buscan, la encuesta de satisfacción en GLPI no es un botón global: se configura por entidad, en Administración > Entidades > (seleccione la entidad) > pestaña Asistencia. Cada campo de la pantalla escribe en una columna de la tabla glpi_entities, y el valor puede heredarse de la entidad padre. Conocer la columna detrás de cada campo es lo que permite diagnosticar por SQL cuando la interfaz "dice" que todo está bien.

El campo Configuración con valor -2 (heredar) es la trampa silenciosa: una subentidad puede parecer activa cuando en realidad hereda "ninguna encuesta" de la raíz. Las versiones recientes trajeron la misma mecánica a los Cambios, en columnas equivalentes con el sufijo _change.

El disparador real: el cierre + el cron, no la solución

Aquí está la causa número 1 de "la encuesta no sale". La encuesta no nace cuando el ticket se resuelve (estado 5, Resuelto); nace cuando el ticket se cierra (estado 6, Cerrado) y, aun así, solo cuando la tarea de cron createinquest se ejecuta y sortea ese ticket dentro de la inquest_rate. Son dos requisitos independientes:

1. El ticket debe cerrarse. Si el cierre automático está apagado y los técnicos solo "resuelven", los tickets quedan en Resuelto para siempre y no se genera ninguna encuesta. El cierre automático es el campo autoclose_delay de la propia entidad.
2. El cron debe ejecutarse en modo externo. La tarea createinquest genera las encuestas de los tickets cerrados. En modo interno solo se ejecuta cuando alguien carga una página - en entidades de bajo tráfico puede pasar días sin ejecutarse.

Ese fue exactamente el caso en un entorno que asumimos: la encuesta llevaba meses "activada" y la base de datos no tenía una sola respuesta. No era la plantilla ni la tasa. createinquest estaba en modo interno (mode = 1) en un GLPI de bajo tráfico, así que el cron prácticamente nunca se disparaba; y, para colmo, el cierre automático estaba apagado, así que casi nada llegaba al estado Cerrado. Activamos el cron externo del sistema operativo y ajustamos autoclose_delay: las encuestas empezaron a generarse el mismo día. Desde entonces, revisar estos dos puntos se volvió un elemento fijo de nuestro runbook al asumir cualquier GLPI.

El cron externo es una línea en el crontab del sistema, ejecutada con el usuario de PHP:

# /etc/cron.d/glpi - cron externo de GLPI (usuario de PHP-FPM)
# 1 ejecución por minuto; procesa TODAS las tareas en modo externo,
# incluida "createinquest" (generación de las encuestas de satisfacción).
* * * * *  apache  /usr/bin/php /var/www/glpi/front/cron.php >/dev/null 2>&1

Y el diagnóstico directo en la base de datos confirma si la tarea está activa y cuándo se ejecutó por última vez:

-- Estado de la tarea que genera las encuestas (usar usuario de solo lectura)
-- state: 0=deshabilitada 1=en espera 2=en ejecución
-- mode:  1=interno (se ejecuta en page load)  2=externo (cron del SO)
-- frequency: intervalo en segundos (por defecto 86400 = 1 día)
SELECT name, state, mode, frequency,
       lastrun,
       DATE_ADD(lastrun, INTERVAL frequency SECOND) AS proxima_prevista
FROM glpi_crontasks
WHERE name = 'createinquest';

La plantilla de la notificación

Con la encuesta generada, quien invita al usuario es la notificación. Personalícela en Configuración > Notificaciones > Plantillas de notificación, en la plantilla ligada al evento de satisfacción del Ticket. Las etiquetas útiles:

• ##ticket.urlsatisfaction## - enlace directo y autenticado a la encuesta (el más importante).
• ##ticket.id## y ##ticket.title## - referencia para que el usuario recuerde la atención.
• ##satisfaction.text## / ##satisfaction.type## - texto y tipo de la encuesta.

El error común aquí es esmerarse en un correo largo: cuanto más texto antes del enlace, menor la conversión. Una línea de contexto, el enlace y listo.

Midiendo la tasa de respuesta de verdad

La media honesta de respuesta de encuestas por correo está en el rango del 10% al 20%; tratar el 30% como "malo" es irreal. Todas las respuestas viven en glpi_ticketsatisfactions, una fila por encuesta generada. Cuando no se respondió, date_answered queda nulo - así se separa "enviada" de "respondida":

-- Tasa de respuesta y media (últimos 90 días), usuario de solo lectura
-- type: 1=interna (estrellas)  2=externa (URL)
-- satisfaction: 0 a 5; date_answered nulo = aún no respondida
SELECT
    COUNT(*)                                                   AS generadas,
    SUM(date_answered IS NOT NULL)                            AS respondidas,
    ROUND(100 * SUM(date_answered IS NOT NULL) / COUNT(*), 1) AS tasa_respuesta_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);

Observe que la media solo considera a quien respondió. Calcular la media sobre todas las filas (incluidos los nulos) ensucia el número y fue otra distorsión que ya corregimos en un informe de cliente.

Levantando la tasa de respuesta del suelo

La configuración correcta es un requisito previo; el volumen de respuestas es otra batalla. Lo que funciona en la práctica:

• Bloquear nuevos tickets hasta responder con el módulo Pending Survey: el usuario reencuentra la encuesta pendiente al intentar abrir el próximo ticket. Es lo que más mueve la aguja.
• Reducir el inquest_delay para generar la encuesta cerca del cierre, mientras la atención sigue fresca en la memoria.
• Notificar por otro canal además del correo, por ejemplo vía WhatsApp.
• Mantenerla simple: 1 nota y 1 comentario opcional. Una encuesta larga hunde la conversión.

Una trampa de la inquest_rate: el sorteo ocurre en el momento del cron y no es retroactivo. Bajar del 100% al 30% no "cancela" encuestas ya generadas, y volver a subir no recupera los tickets que ya pasaron - la marca de agua max_closedate solo avanza.

¿Necesita una satisfacción que mida de verdad, con un cron fiable y una tasa de respuesta sana? El soporte de GLPI de NexTool asume la configuración, el monitoreo del cron y los informes mensuales para su operación. Conozca el servicio de soporte y mantenimiento.

Revisado por el equipo de NexTool Solutions.