Una empresa de seguridad privada chilena perdió en marzo un contrato anual de US$ 480 000 con una multinacional minera por incumplimiento del SLA de respuesta a alarma. El contrato exigía "respuesta en sitio de < 5 minutos" para alarmas categoría 1 (intrusión, agresión confirmada, fallo de infraestructura crítica). La auditoría mostró que el tiempo medio de respuesta del último trimestre fue de 11 minutos 23 segundos, con varias intervenciones superiores a 18 minutos. El cliente cambió de proveedor en 30 días.
El problema no fue la dotación — el contratista tenía suficiente personal. El problema fue que nadie había desagregado el SLA en sus 7 segmentos técnicos para medir dónde se perdían los segundos. Cuando lo hicimos en una sesión post-mortem con el nuevo equipo, descubrimos que 3 de los 7 segmentos sumaban el 70% del tiempo total y eran arreglables con cambios operativos sin contratar a nadie nuevo. Este post explica los 7 segmentos del tiempo de respuesta, cómo se mide cada uno en producción, qué exigen los contratos enterprise LATAM 2024-2025 y los patrones que reducen el tiempo total sin aumentar costos.
Los 7 segmentos del tiempo de respuesta
Lo que el contrato llama "respuesta en 5 minutos" se compone en realidad de siete intervalos consecutivos, cada uno medible independientemente:
T1 — Trigger a captura (típicamente 0.1 - 2 segundos). Desde el evento físico (apertura forzada, botón de pánico, sensor de movimiento en zona crítica) hasta la captura del evento por el sistema central. Lo limita la calidad del sensor y la red local del cliente. Sensores cableados: 100-300 ms. Sensores wireless con encuesta: 500-2 000 ms.
T2 — Captura a notificación al SOC del proveedor (típicamente 1 - 8 segundos). Desde la captura local hasta que la alerta llega al sistema central del proveedor de seguridad. Latencia de red (internet del sitio + backbone) más procesamiento del servidor. WiFi del sitio cae aquí; conexión móvil 4G suele añadir 1-3 s adicionales.
T3 — Notificación a despacho del vigilante (típicamente 15 - 90 segundos). El operador del SOC recibe la alerta, la evalúa, decide qué vigilante envía y le manda la orden por radio o por app. En operaciones bien dimensionadas: 15-30 s. En operaciones con SOC saturado o sin protocolo claro: 60-120 s. Este es el segmento más sensible a la calidad operativa.
T4 — Despacho a inicio de tránsito del vigilante (típicamente 30 - 180 segundos). Desde que el vigilante recibe la orden hasta que empieza a moverse hacia el punto. Depende de dónde estaba (en la caseta, en otra ronda, descanso), si tenía que terminar otra tarea, equipamiento (chaleco, linterna, radio) y geometría del sitio (camino libre, llaves disponibles).
T5 — Tránsito al sitio de la alarma (típicamente 60 - 300 segundos). Tiempo físico de desplazamiento. Depende del tamaño del sitio, vehículo disponible, obstáculos. En un edificio de oficinas pequeño: 30-90 s. En un parque industrial de 20 hectáreas con vehículo: 120-300 s. En una mina abierta o un sitio rural sin vehículo: hasta 600 s.
T6 — Llegada a verificación visual del incidente (típicamente 15 - 120 segundos). Desde que el vigilante llega al sitio físico hasta que ha verificado visualmente la situación y reporta al SOC. Incluye búsqueda en el área si la alarma no es específica de un punto exacto.
T7 — Verificación a cierre del evento (variable, típicamente 60 - 600 segundos). Desde la confirmación visual hasta el cierre del evento en la bitácora. Incluye llamada a Carabineros/policía si aplica, primeros auxilios si hay agredido, contención del intruso, etc. Variable extremadamente alto.
Suma típica T1-T6 en operación bien dimensionada: 121 a 700 segundos = 2 a 11.5 minutos. El SLA contractual de "5 minutos" cubre habitualmente T1-T6 (no incluye T7 que se mide por separado como tiempo de resolución).
Lo que exigen los contratos LATAM 2024-2025
Datos de revisión de 80 contratos enterprise LATAM (Chile, Perú, Colombia, México, Argentina) firmados entre Q3 2024 y Q1 2025 con empresas de seguridad privada:
Por sector:
- Minería: SLA típico T1-T6 = 5 minutos para alarmas categoría 1, 15 minutos para categoría 2. Penalizaciones: $5 000 - $50 000 USD por incumplimiento mensual sostenido. Auditoría trimestral.
- Banca y retail tier 1: SLA T1-T6 = 3 minutos para alarmas categoría 1 (cajeros, bóvedas, accesos restringidos). Penalización por incidente individual $500 - $5 000 USD. SLAs muy duros porque el coste de una alarma sin respuesta es alto.
- Hospitales y centros sanitarios: SLA T1-T6 = 4 minutos para alarmas categoría 1 (agresión a personal, fuga psiquiatría, robo medicación controlada). Multas no monetarias sino contractuales (rescisión anticipada).
- Manufactura y logística: SLA T1-T6 = 7-10 minutos. Más flexibles porque los sitios son grandes y el coste por minuto es menor.
- Residencial y oficinas: SLA T1-T6 = 8-15 minutos. Penalizaciones leves o solo registro de incidentes para revisión anual.
Métricas exigidas por encima del SLA:
- Tiempo medio T1-T6 medido mensualmente (no el peor caso ni mejor caso, sino la media).
- Percentil 95 T1-T6 (el cliente quiere saber que el 95% de los casos están bajo X minutos, no solo la media).
- Conteo de incidentes por encima del SLA en el mes.
- Causa raíz documentada de cada incumplimiento individual.
Reporting: dashboard en tiempo real accesible vía SSO del cliente con los 4 KPIs arriba. Mensual sin excepción. Algunos clientes (banca tier 1, minería) exigen acceso vía API REST para integrarlo en su propio sistema de gestión de proveedores.
Cómo se mide en producción punta a punta
Medir un solo segmento requiere instrumentación específica. Medir los 7 de forma confiable exige un sistema que correlacione eventos de fuentes distintas:
Instrumentación del sensor (T1). El propio sensor cliente debe emitir timestamp del evento. La mayoría no lo hace; entonces se aproxima al timestamp de captura del servidor del cliente (T1 estimado conservadoramente como 0).
Logs del backbone (T2). Sello de tiempo del cliente (cuando el sensor emite) cruzado con sello de tiempo del servidor del proveedor (cuando recibe la notificación). NTP qualified en ambos lados es obligatorio para que la diferencia sea válida.
SOC dispatch log (T3). El sistema del SOC registra timestamp de recepción de la alerta y timestamp de envío de la orden al vigilante. Diferencia = T3. Auditable.
Acknowledge de la app del vigilante (T4). La app del vigilante debe registrar dos eventos: "alerta recibida" (timestamp de notificación push) y "tránsito iniciado" (vigilante toca un botón "voy en camino" o el sistema detecta movimiento GPS > 5 m/s sostenido). Diferencia = T4.
Track GPS del vigilante (T5). El GPS del vigilante registra posición cada N segundos durante el tránsito. Tiempo desde "tránsito iniciado" hasta "llegada al geofence del incidente" = T5.
Verificación firmada (T6). El vigilante escanea un checkpoint próximo al incidente o pulsa "en sitio, verificando" con foto. Diferencia entre llegada al geofence y verificación = T6.
Cierre del evento (T7). El operador del SOC cierra el evento en su sistema con observaciones. Timestamp final.
La cadena completa exige cinco timestamps NTP qualified más cross-referencing entre sistemas. Sin esta correlación, no hay medición real — solo estimaciones.
Los patrones que reducen el tiempo total sin coste extra
Después de análisis post-mortem de incumplimientos en 23 operaciones LATAM, los patrones que más han reducido el tiempo medio sin aumentar dotación:
Patrón 1 — Reducir T3 con protocolo de dispatch automático. El SOC actual habitualmente tarda 30-60 s en "evaluar" la alerta antes de despachar. Para alarmas categoría 1 con score de confianza > 90%, el sistema despacha automáticamente al vigilante geográficamente más cercano y notifica al operador del SOC para supervisión, no para decisión. Reduce T3 de 45 s a 5-10 s. Operador del SOC puede cancelar si es falsa alarma, pero el reloj ya está corriendo.
Patrón 2 — Reducir T4 con app que arranca tránsito automático. Cuando el vigilante recibe push de alerta categoría 1, la app le muestra mapa de ruta + botón grande "voy en camino" pre-seleccionado. Un toque y el sistema marca T4. En lugar de los 30-60 s típicos de buscar la radio, oír al SOC, confirmar verbalmente. T4 baja a 5-15 s.
Patrón 3 — Reducir T5 con vigilante "móvil" pre-posicionado. En sitios grandes (parques industriales, campus corporativos), un vigilante asignado al rol de "respuesta rápida" se pre-posiciona en un punto central cada hora durante turnos críticos en lugar de hacer ronda continua. Cuando llega una alarma, T5 baja de 180-300 s a 60-120 s. Sin contratar a nadie extra — solo reasignación del cuadro.
Patrón 4 — Reducir T6 con foto pre-cargada del checkpoint próximo. El vigilante llega al sitio y a veces tarda 30-60 s buscando el origen exacto de la alarma. Si la app le muestra automáticamente foto del checkpoint o sensor que disparó, con flecha de orientación, T6 baja a 10-20 s.
Patrón 5 — Reducir T2 con conexión 4G de fallback en el sitio. Sitios con WiFi del cliente que cae intermitentemente añaden 2-5 s al T2. Tener un router 4G secundario del proveedor de seguridad (con SIM corporativa) reduce T2 a < 1 s incluso cuando el WiFi del cliente está caído.
En las 23 operaciones donde aplicamos al menos 3 de los 5 patrones, el tiempo medio bajó de 8-12 minutos a 3-5 minutos. Cuatro de las cinco intervenciones requerían cambios solo de software o protocolo, no de dotación.
Errores frecuentes en SLAs contractuales
SLA único sin diferenciar categorías de alarma. "Respuesta en 5 minutos a cualquier alarma" es operativamente imposible y comercialmente perjudicial. Diferenciar al menos 3 categorías (P1 crítico, P2 medio, P3 informativo) con SLA distinto por cada una.
SLA sin definir qué cubre. El contrato dice "5 minutos" sin aclarar si es T1-T5, T1-T6 o T1-T7. Ambigüedad que el cliente interpreta a su favor cuando hay disputa. Especificar.
Penalizaciones acumulativas no auditadas. Cláusula que dice "$5 000 USD por incumplimiento" sin auditoría externa contrastable. El cliente puede acusar incumplimiento sin pruebas. El proveedor necesita instrumentación neutral.
SLA sin ventana de medición. "Respuesta en 5 minutos" sin decir si es media mensual, mediana, p95 o cada caso individual. Cada métrica produce un número distinto. El cliente quiere p95; el proveedor prefiere media. Negociar explícitamente.
Sin exclusiones de fuerza mayor. Una alerta en mitad de un terremoto, corte eléctrico mayor o evento de seguridad pública (manifestación violenta) no se puede responder en 5 minutos por razones operacionales obvias. Definir exclusiones.
Reporte mensual en PDF sin acceso a datos crudos. El cliente recibe PDF "media de respuesta = 4.2 minutos" sin poder verificar. Da pie a desconfianza. Mejor: API que permita al cliente extraer datos crudos y calcular su propia métrica.
Cómo rondinesdigitales.com mide y reporta tiempos de respuesta
Sistema de instrumentación de los 7 segmentos T1-T7 con sello de tiempo NTP qualified en todos los puntos críticos. Dashboard en tiempo real con tiempo medio T1-T6, p95, p99 y conteo de incidentes por encima del SLA, segmentado por categoría de alarma (P1/P2/P3). Acceso del cliente vía SSO con los KPIs en su propio idioma operativo. API REST que entrega datos crudos para que el cliente calcule su propia métrica. Reporting mensual automático con causa raíz documentada de cada incumplimiento (sin maquillaje). Despacho automático configurable para alarmas categoría 1 con score > X. App del vigilante con botón "voy en camino" pre-seleccionado, mapa de ruta con foto del checkpoint próximo al incidente y geofence de llegada. Soporte de pre-posicionamiento de vigilante en sitios grandes con asignación dinámica del cuadro.
Para profundizar
- /blog/verificar-rondines-tiempo-real-distancia — los 3 métodos de supervisión remota cubren T3.
- /blog/app-rondines-android-gama-baja-latam — la app que arranca tránsito automático debe funcionar en hardware antiguo LATAM.
- /blog/checkpoints-doble-factor-nfc-gps-rondines — los checkpoints anti-fraude son la base de la bitácora que reporta tiempos.
- /blog/modo-offline-100-end-to-end-rondines-latam — offline robusto evita perder eventos T6 cuando hay caída de