Mesa de servicio de TI en gobierno y empresas: cómo cumplir el SLA y demostrarlo ante una auditoría
Una mesa de servicio tiene dos trabajos: resolver lo que la gente necesita y demostrar que lo resolvió en el plazo comprometido. El primero se ve todos los días. El segundo aparece cuando llega una auditoría, una revisión de contrato o una queja formal, y casi siempre falla por lo mismo: las cifras viven en lugares que cualquiera puede editar.
Qué pregunta un auditor (y qué tienes que poder mostrar)
1. Catálogo, prioridades y dueño desde el primer minuto
Cada solicitud debe nacer con categoría, prioridad, responsable y plazo, sin importar si entró por el portal, el correo o la app del técnico. Si la asignación depende de que alguien lea el correo, el reloj ya está corriendo sin dueño. Un catálogo claro (qué servicios existen, qué datos pide cada uno y qué plazo tiene) evita además la mitad de las idas y vueltas con el usuario.
2. Autoservicio que sí resuelve
Los datos de Gartner muestran el problema: mucha gente intenta resolver sola, pero pocos lo logran, y la causa principal es no encontrar contenido relevante. Lo que funciona en una mesa interna:
3. Plazos en horario hábil real, con avisos
El plazo debe correr con el calendario oficial del cliente, pausarse cuando se espera al usuario y avisar al 75 % y al 100 % con el motivo del riesgo. Lo explicamos con un ejemplo paso a paso en [cómo calcular el SLA en horario hábil](/blog/como-calcular-sla-horario-habil-dias-inhabiles-pausas).
4. Penalizaciones calculadas mientras pasan
En mesas que responden por un contrato, el incumplimiento cuesta dinero. Si las penalizaciones se calculan al cierre del mes, ya no hay nada que hacer. Calcularlas en vivo, por indicador del contrato (disponibilidad, tiempo de atención, tiempo de resolución), permite ver cuánto está en juego hoy y dónde actuar primero.
5. Bitácora que no se puede maquillar
La pieza que más cambia una auditoría es la bitácora encadenada: cada registro guarda una huella criptográfica (por ejemplo, SHA-256) que incluye la del registro anterior. Si alguien modifica un evento pasado, su huella deja de coincidir y la cadena se rompe desde ese punto; una verificación lo detecta en segundos. Es el mismo principio de integridad que recomiendan las guías de gestión de bitácoras de seguridad del NIST: los registros deben protegerse contra alteraciones y su integridad debe poder comprobarse.
6. Constancias que cualquiera puede verificar
Al cerrar una solicitud, la mesa puede emitir una constancia con folio, fechas, tiempos y resultado, y un QR que lleva a una página pública de verificación. Quien la recibe —un área usuaria, un auditor, un proveedor— comprueba desde su teléfono, sin cuenta, que la constancia es auténtica y que su huella coincide con la bitácora.
Cómo empezar sin un proyecto de un año
Preguntas frecuentes
