Un buen SLA de soporte IT empieza por el impacto, no por el cronómetro

Un acuerdo de soporte puede prometer una respuesta rápida y dejar al usuario sin trabajar durante horas. También puede mostrar buenos porcentajes mientras se repiten las mismas incidencias cada semana. El problema suele estar en qué se ha definido y cómo se mide. Un SLA útil describe el servicio esperado, sus límites y la forma de evaluar su cumplimiento. Debe ayudar a coordinar a las personas, no convertirse en una colección de cifras que cada parte interpreta de manera diferente.

Separa respuesta, restauración y resolución

La respuesta confirma que alguien ha asumido el caso y realiza una primera valoración. La restauración permite volver a trabajar, quizá mediante una alternativa temporal. La resolución corrige la causa o completa la solicitud. Son momentos distintos y conviene registrarlos por separado. Un mensaje automático no equivale necesariamente a una respuesta técnica útil. Del mismo modo, prestar un equipo de sustitución puede recuperar la actividad sin que la reparación del original esté terminada.

Define prioridades con ejemplos reconocibles

Combina impacto y urgencia. La caída de un servicio para toda la plantilla suele necesitar una atención diferente a una configuración individual, pero un problema de una sola persona puede ser crítico si bloquea una actividad esencial sin alternativa. Utiliza ejemplos de la propia organización y permite revisar la prioridad cuando aparezca nueva información. El cargo de quien abre el ticket no debería ser el único criterio para decidir qué trabajo se atiende primero.

Incluye situaciones ambiguas en la conversación inicial: lentitud intermitente, pérdida de una función secundaria o un fallo que solo ocurre en una sede. Estas cuestiones revelan si ambas partes comparten expectativas. Documenta quién puede escalar un incidente y qué información necesita aportar. Evita exigir al usuario diagnósticos técnicos para recibir atención; bastan actividad afectada, personas bloqueadas, hora de inicio y alternativas disponibles para orientar el primer análisis.

Aclara el reloj y las dependencias

Un compromiso de dos horas cambia mucho según se cuente en horario laboral o de forma continua. Define calendarios, festivos, canales y cobertura fuera de horario. Establece también cuándo se pausa un contador y cómo se informa al usuario. Esperar una respuesta necesaria puede justificar una pausa concreta; trasladar el caso a otro equipo no debería hacerlo desaparecer del seguimiento. El responsable del servicio debe conservar visibilidad aunque intervengan terceros.

• Describe qué servicios están cubiertos y cuáles requieren otro circuito.
• Asocia cada prioridad a ejemplos, cobertura y puntos de escalado.
• Distingue comunicación inicial, recuperación operativa y solución definitiva.
• Explica dependencias externas y cómo se mantiene informado al solicitante.

Diseña comunicaciones que reduzcan incertidumbre

Durante una incidencia importante, el usuario necesita conocer qué está afectado, qué puede hacer y cuándo recibirá la siguiente actualización. No hace falta prometer una hora de solución si todavía no hay evidencia. Un intervalo de comunicación acordado evita consultas repetidas y ayuda a coordinar alternativas. Para solicitudes normales, muestra estado, siguiente acción y responsable. Los comentarios técnicos internos deben convivir con una explicación comprensible para quien depende del servicio.

Mide la calidad detrás del porcentaje

El cumplimiento del SLA es una señal, no una descripción completa de la experiencia. Añade reaperturas, incidencias recurrentes, antigüedad de casos pendientes y satisfacción con contexto. Si se cierran tickets rápidamente pero vuelven a abrirse, el indicador de velocidad está ocultando trabajo incompleto. Examina también la distribución de tiempos: una media aceptable puede esconder un grupo pequeño que espera mucho. Segmenta por tipo de solicitud para no comparar tareas con complejidades completamente diferentes.

Revisa una muestra de casos junto con el proveedor o el equipo interno. Pregunta qué impidió avanzar y si la clasificación inicial fue correcta. A veces la mejora está en una aprobación lenta, un formulario confuso o una instrucción que falta. La reunión de servicio debería generar acciones concretas, no limitarse a discutir penalizaciones. Las métricas deben permitir mejorar el sistema y detectar compromisos que necesitan ajustarse a la capacidad disponible.

Revisa el acuerdo cuando cambie el trabajo

Nuevas sedes, turnos o aplicaciones pueden cambiar la cobertura necesaria. Actualiza el SLA y las dependencias cuando suceda, en lugar de mantener un documento que describe una empresa anterior. Atlassian ofrece una referencia general sobre acuerdos de nivel de servicio; el valor real aparece al concretarlos para tu operación. Un buen acuerdo permite decidir, comunicar y mejorar con criterios compartidos, especialmente cuando coinciden varias incidencias y la capacidad de atención es limitada.