Zyntops Log: por qué un sistema debe medirse a sí mismo

Un flujo automatizado sin trazabilidad es una caja negra. Funciona, hasta que un día no funciona, y entonces nadie sabe cuándo empezó a fallar, cuánto tiempo llevaba fallando, ni cuánto se ha dejado de ahorrar mientras tanto. Peor aún: si nadie mide cuánto tiempo ahorra el sistema cuando funciona bien, el ahorro es una promesa de venta, no un hecho verificable.

Zyntops Log resuelve esto con un principio simple: todo sistema que automatiza un proceso debe generar, como parte de su funcionamiento normal, la evidencia de que lo está haciendo bien.

El problema de la caja negra

Cuando un proceso se automatiza sin instrumentación, la única señal de que algo va mal suele ser una queja: “esto no ha llegado”, “el informe no se generó”, “el ticket sigue abierto”. Para entonces, el problema puede llevar días activo. Y cuando todo va bien, no hay ninguna señal en absoluto — lo cual parece positivo, pero significa que la única prueba del valor del sistema es la ausencia de quejas, no una cifra concreta que se pueda enseñar a quien pagó por el proyecto.

La instrumentación no es opcional en un sistema bien diseñado. Es la diferencia entre “creemos que esto funciona” y “esto funciona, y aquí está el registro que lo demuestra”.

Anatomía de un timestamp de inicio y fin

La implementación técnica es deliberadamente simple, porque la complejidad es el enemigo de la fiabilidad en un sistema de monitorización. En cada flujo de n8n, se añaden dos nodos ligeros:

• Un nodo al inicio del flujo que registra: identificador único de la ejecución, nombre del proceso, timestamp de inicio y datos de contexto mínimos (por ejemplo, qué disparó la ejecución).
• Un nodo al final del flujo (o uno por cada rama de salida, si el flujo tiene bifurcaciones) que registra: el mismo identificador, timestamp de fin, resultado (éxito, error, o excepción gestionada) y cualquier métrica relevante del proceso concreto.

Un ejemplo de entrada de log, simplificado:

{
  "id": "flow-conciliacion-2026-04-18-0731",
  "proceso": "conciliacion_facturas_erp_bms",
  "inicio": "2026-04-18T07:31:02Z",
  "fin": "2026-04-18T07:31:09Z",
  "duracion_segundos": 7,
  "duracion_manual_estimada_segundos": 420,
  "resultado": "exito",
  "autorizado_por": "maria.lopez@cliente.com"
}

Esos siete segundos de ejecución automatizada, comparados con los 420 segundos que tardaba la versión manual del mismo paso, son la unidad mínima de dato que alimenta el reporte de ahorro. Ninguna cifra se estima a posteriori: se calcula acumulando estos registros reales, ejecución tras ejecución.

Del registro individual al reporte mensual

Cada registro individual tiene poco valor por sí solo. El valor aparece al agregarlos: sumando la duración manual estimada de todas las ejecuciones de un mes y restándole la duración real, se obtiene el tiempo liberado real de ese proceso, no una proyección. Multiplicando ese tiempo por el coste por hora definido en el Mapa de Fricción original, se obtiene el ahorro económico real del mes.

El reporte mensual automático que recibe el cliente incluye, como mínimo: número de ejecuciones del proceso, tasa de éxito frente a excepciones gestionadas, horas liberadas acumuladas y ahorro estimado en euros. No requiere que nadie lo pida ni lo construya a mano — es una consulta programada sobre los mismos registros que genera el sistema al operar.

Este es el mismo mecanismo que justifica el 80% de reducción que aparece en la calculadora de la web: no es una cifra de marketing, es la media observada al comparar duración real contra duración manual estimada en los procesos ya instrumentados con Zyntops Log.

Mapeo de responsabilidades

Además de medir tiempo, Zyntops Log registra qué usuario autoriza cada tarea, normalmente a través de WhatsApp o de una llamada a la API cuando la autorización requiere intervención humana (por ejemplo, aprobar un pago por encima de cierto importe). Esto convierte el log en algo más que una métrica de rendimiento: es también un registro de auditoría de quién decidió qué y cuándo, útil tanto para resolver incidencias como para cumplir con requisitos de trazabilidad internos.

Precisamente porque ese registro contiene un dato personal (quién autorizó cada acción), se trata como tal en la Política de Privacidad del servicio: se define su finalidad, su base de legitimación y su plazo de conservación, igual que cualquier otro dato de carácter personal que el sistema procese.

La idea central

Un sistema que no se mide a sí mismo obliga a confiar en él por fe. Un sistema instrumentado con timestamps de inicio y fin en cada punto crítico convierte esa fe en un número verificable cada mes: cuánto tiempo se liberó, cuánto se ahorró, y quién decidió qué en el camino. Esa es la diferencia entre automatizar un proceso y construir una infraestructura que se puede auditar.