Informes de usuarios como fuente

Cada empleado que pulsa el botón de reporte es un sensor que ve lo que el filtro dejó pasar. Como fuente de inteligencia tiene virtudes claras —llega en minutos, trae el correo completo con sus cabeceras, cubre justo lo que superó los controles— y sesgos que hay que declarar: solo cuenta lo que alguien notó, depende de la formación y del ánimo de cada área, y mezcla lo malicioso con lo legítimo que pareció raro.

Por eso un reporte no se cuenta como incidente: se clasifica. Y lo que más vale no es el total, sino lo rápido que llega el primero de cada campaña, porque desde ese momento se puede retirar el correo de los demás buzones.

Ejecuta SELECT * FROM metricas_simulacro. La métrica que más se publica de un simulacro es la tasa de clics, y baja de mes en mes. La que dice si el sensor funciona es la tasa de reporte: cuántos de los que recibieron el simulacro lo reportaron.

Ejecuta SELECT * FROM entregas_campana y SELECT * FROM reportes_lunes_23. La cola entrega los reportes ordenados por área, no por hora, y mezcla campañas: el primero de la tabla no es el primero de la campaña, y el que llegó más temprano puede ser de otro remitente. Se filtra por el dominio de la campaña y se busca la hora más temprana.

Ejecuta SELECT * FROM veredictos_1_al_22_nov. Un buzón de reportes con muchos correos legítimos no es un fracaso: es el precio de que la gente reporte en la duda, y se baja con retroalimentación, no prohibiendo reportar. Pero el triage necesita saber qué parte de su trabajo produce inteligencia.

Una persona que reporta y nunca sabe qué pasó deja de reportar. La retroalimentación mantiene vivo el sensor y además enseña: quien reportó un correo legítimo aprende por qué lo era, y quien reportó el primero de una campaña ve que sirvió.