Saltar al contenido

Agende una llamada de 30 minutos

La programación la gestiona Calendly, cuya política de privacidad se aplica a los datos que introduzca. Abrir en Calendly

Todas las perspectivas

Respuesta frente a resolución: lo que un SLA de servicios gestionados debería prometer de verdad

Por el equipo de ingeniería de SynapseTel Cloud · Publicado 30 de septiembre de 2026 · 6 min de lectura

Un objetivo de respuesta indica cuándo un ingeniero cualificado empieza a trabajar en su incidente. Un objetivo de resolución indica cuándo vuelve a funcionar el servicio. Casi toda la decepción con los servicios gestionados empieza por confundir ambos, así que aquí explicamos cómo leer severidades, relojes, pausas y exclusiones antes de firmar.

Dos promesas distintas

Un objetivo de respuesta es una promesa de atención: en un plazo fijado, un ingeniero cualificado ha tomado su incidente, ha entendido el impacto y le ha dicho qué va a pasar. Un objetivo de resolución es una promesa de resultado: en un plazo fijado, el servicio vuelve a funcionar, ya sea corregido o con una solución alternativa acordada.

Muchos contratos destacan los tiempos de respuesta porque son fáciles de cumplir. Un correo automático de "hemos recibido su ticket" no es una respuesta, ni tampoco una cola de triaje que nadie atiende. Al leer un acuerdo, busque la definición de respuesta. Debe nombrar a una persona con la capacidad de actuar y una primera actualización humana dirigida a usted. Si el acuerdo no tiene ningún objetivo de resolución, está comprando atención, no resultados. Puede ser un trato justo, pero solo si sabe que ese es el trato.

La severidad lo decide todo, así que defínala por escrito

Cada objetivo del acuerdo depende de un nivel de severidad, por lo que unas definiciones vagas hacen que todo objetivo sea negociable a posteriori. Un modelo habitual de cuatro niveles funciona bien cuando cada nivel se define por el impacto en el negocio y no por síntomas técnicos. P1: un servicio de producción está caído o una interrupción grave afecta a la mayoría de los usuarios, sin solución alternativa. P2: degradación importante o una función clave no disponible, con una solución alternativa limitada. P3: impacto parcial o no crítico, con solución alternativa disponible. P4: un problema menor, una pregunta o un defecto estético.

Acuerde quién fija la severidad. Lo habitual es que usted la proponga al reportar el incidente y que el proveedor pueda reclasificarla con una razón escrita que usted pueda ver. Acuerde también que la severidad puede subir cuando crece el impacto y que una discrepancia pasa a un contacto de escalamiento designado en lugar de quedarse en el ticket. Un incidente registrado como P3 a las 17:00 que se convierte en una caída total a las 19:00 debe tratarse como P1 desde el momento en que lo fue.

Qué reloj está corriendo

Un objetivo de cuatro horas significa cosas muy distintas según el reloj. El tiempo natural corre cada minuto de cada día. El horario laboral corre solo dentro de una jornada acordada, así que una respuesta de cuatro horas laborales a un P3 abierto un viernes a las 16:30 puede vencer el lunes por la mañana. El horario de cobertura es el que defina el acuerdo, por ejemplo 24x7 para P1 y horario laboral para lo demás.

Ningún reloj es incorrecto, pero el acuerdo debe indicar cuál se aplica a cada severidad, en qué zona horaria y cómo se tratan los festivos. Una buena prueba es pedir al proveedor que resuelva un ejemplo por escrito: un P2 reportado un sábado a las 22:00, y cuándo vencen su respuesta y su resolución. Si la respuesta requiere una reunión, el reloj todavía no está definido.

Cuándo puede pausarse el reloj y cuándo no

Algunas pausas son justas. Si el ingeniero necesita un acceso, un archivo de registro o una decisión que solo usted puede aportar, es razonable que el reloj de resolución se detenga mientras el incidente espera por usted y se reanude en cuanto responda. Lo importante es que cada pausa quede registrada, sea visible para usted y esté ligada a una petición concreta.

Otras pausas no son justas y deberían quedar fuera del acuerdo. Esperar a los propios proveedores del proveedor, como un fabricante de hardware, un proveedor de nube o un editor de software, es un riesgo del proveedor salvo que el acuerdo diga otra cosa. También lo es esperar una ventana de cambios que el proveedor controla. Un acuerdo que permite detener el reloj "a la espera de un tercero" sin límite ha eliminado en silencio el objetivo de resolución.

Resolución no es causa raíz

Resolución suele significar servicio restablecido, a veces mediante una solución alternativa, no que la falla de fondo se haya encontrado y eliminado. Esa es la prioridad correcta durante una interrupción: primero restablecer, después investigar. La investigación sigue necesitando su propio compromiso.

Para los incidentes P1, y para cualquier P2 recurrente, pida una revisión posterior al incidente por escrito en un número acordado de días laborables. Debe cubrir qué ocurrió, la cronología, la causa raíz en la medida en que se conozca y las acciones que evitarán que se repita, cada una con un responsable y una fecha. Después, compruebe en la siguiente revisión mensual si esas acciones se cerraron.

Medir por incidente, informar por mes

El cumplimiento debe medirse por incidente e informarse por severidad: la proporción de P1 respondidos y resueltos dentro del objetivo este mes, y así para cada nivel. Los promedios ocultan el incidente que importaba. Un tiempo medio de respuesta de 20 minutos puede incluir un P1 que esperó tres horas.

Pida los registros de base, no solo los porcentajes. Cada incidente debe incluir sus plazos de vencimiento, los momentos reales de reconocimiento y resolución, y el tiempo en pausa. Con eso puede comprobar el informe usted mismo en lugar de confiar en él.

Los créditos de servicio compensan; no restablecen

Los créditos de servicio suelen ser un pequeño porcentaje de la cuota mensual y a menudo tienen un tope. Son una señal útil de que el proveedor se toma en serio los objetivos, pero nunca cubrirán el coste de una interrupción real, así que no elija proveedor por el tamaño de sus créditos.

Los términos que le protegen durante un incidente grave son operativos. Busque un contacto de escalamiento designado, una cadencia de comunicación para incidentes graves con una actualización al menos cada 30 a 60 minutos hasta restablecer el servicio, y una regla clara sobre quién puede declarar un incidente grave. Esos términos definen la peor hora de su año. El crédito llega un mes después.

Exclusiones que conviene leer dos veces

Todo acuerdo tiene exclusiones y la mayoría son razonables: mantenimiento programado, interrupciones causadas por usted, versiones de software sin soporte y hechos fuera del control de cualquiera. Lo que importa es el detalle. El mantenimiento debe hacerse en ventanas acordadas con un plazo de aviso acordado, no cuando el proveedor lo anuncie. Las versiones sin soporte deben estar listadas, con un plan para dejarlas atrás, para que la exclusión no cubra en silencio la mitad de su entorno.

Preste atención a las exclusiones de plataformas de terceros que el proveedor opera en su nombre. Si el proveedor ejecuta sus cargas de trabajo en una nube pública, una caída de esa nube está fuera de su control. Cómo se detecta, se comunica y se sortea no lo está, y el acuerdo debe seguir diciendo qué hace el proveedor durante una.

Preguntas que hacer antes de firmar

¿Qué cuenta exactamente como respuesta y quién la realiza? ¿Qué reloj se aplica a cada severidad y en qué zona horaria? ¿Cuándo puede pausarse el reloj de resolución, cómo se registra cada pausa y podemos verla? ¿Quién fija la severidad y cómo se resuelve un desacuerdo? ¿Hay un objetivo de resolución para cada severidad y qué significa resolución? ¿Cuándo recibimos una revisión posterior al incidente? ¿Cómo se informa el cumplimiento y podemos ver los datos por incidente que lo respaldan? ¿Qué ocurre, paso a paso, en la primera hora de un P1?

Un proveedor que responde a estas preguntas por escrito, antes de que usted firme, suele gestionar sus incidentes de la misma manera.

Cómo lo muestra nuestro portal de clientes

Cada cliente de SynapseTel Cloud trabaja en un portal donde cada incidente muestra su severidad, sus plazos de respuesta y de resolución, y una conversación con el ingeniero que lo atiende. Cuando un incidente espera por usted, el portal pausa el reloj de resolución y amplía el plazo exactamente el tiempo que esperó. Su acuerdo de soporte, con sus definiciones de severidad, objetivos y horario de cobertura, está en el mismo lugar, y la revisión de servicio de cada mes informa del cumplimiento frente a él. Por ahora los objetivos corren en tiempo natural, y sus objetivos son los que fija su acuerdo.

Empiece aquí

Planificar una implementación o un servicio de soporte

Envíenos la forma del problema. Le responde un ingeniero, no un comercial, en un día hábil.

Lo que sigue

  1. 01Describa el entorno
  2. 02Revisión de ingeniería
  3. Sesión de trabajo