OLA vs SLA: la promesa interna que sostiene tu servicio
October 21, 2026
Tu SLA establece que los incidentes de prioridad 2 deben resolverse en cuatro horas. El servicio de asistencia registra el ticket en cuestión de minutos y luego espera, porque el equipo de red trabaja desde su propia cola y nada en esa cola indica un plazo de cuatro horas. Esta es la razón más común por la que los SLA fallan: el compromiso se hace con el cliente, pero el trabajo depende de equipos que nunca estuvieron de acuerdo con él, por lo que los incumplimientos parecen fallos del servicio de asistencia cuando, en realidad, son fallos en la transferencia de tareas.
Un acuerdo de nivel operativo, o OLA, cierra esa brecha. Es la promesa interna que hace posible la externa. Este artículo explica cómo se construyen los OLA a partir de los SLA y cómo Freshservice los aplica a nivel de tarea.
Un SLA es un compromiso entre el proveedor de servicios y el cliente, expresado como objetivos de respuesta y resolución en términos que el negocio comprende. Un OLA es un compromiso entre equipos internos que define la rapidez con la que el equipo de red, base de datos, seguridad o compras actuará sobre el trabajo que le asigne el servicio de asistencia. Un contrato de respaldo aplica la misma idea a proveedores externos, como una empresa de telecomunicaciones o un proveedor de hardware. Confundir los tres genera problemas predecibles: los equipos responsabilizan al servicio de asistencia por el tiempo perdido en la cola de otros, los proveedores no reciben un objetivo claro y los equipos internos tratan las solicitudes del servicio de asistencia como favores en lugar de obligaciones.
Cada acuerdo también necesita un responsable diferente. El SLA está orientado al cliente y es responsabilidad del servicio de asistencia o del propietario del servicio. El OLA es interno y es responsabilidad del gerente del equipo de resolución, y el contrato de respaldo es externo y es responsabilidad del departamento de compras o de gestión de proveedores. Separarlos otorga a cada objetivo un responsable designado, lo cual es el primer paso hacia una rendición de cuentas que se sostenga en una revisión y evite que cada fallo se atribuya siempre al mismo equipo.
La derivación comienza desde el objetivo del SLA y se trabaja hacia atrás mediante restas. Si los incidentes de prioridad 2 deben resolverse en cuatro horas, ese tiempo se divide entre la clasificación (triage), el equipo de resolución, y la verificación y cierre. Una asignación sencilla otorga al servicio de asistencia 30 minutos para la clasificación, al equipo de resolución tres horas, y los últimos 30 minutos para confirmar la solución con el usuario, esas tres horas se convierten en el OLA. La prioridad en sí misma proviene de una matriz de impacto y urgencia, y cada nivel de prioridad conlleva su propio objetivo de resolución, razón por la cual una fila de OLA por prioridad mantiene la asignación coherente entre los equipos.
Los OLA bien estructurados comparten algunos rasgos: cada uno es más corto que el SLA que respalda, cada uno deja un margen para los tickets que se reabren o reasignan, cada uno establece un objetivo que el equipo de resolución puede cumplir hoy, y cada uno se revisa trimestralmente con datos reales.
Un OLA que nadie puede cumplir es peor que no tener ninguno, porque enseña a los equipos a ignorar la fecha límite. En un SLA de prioridad 2 de cuatro horas con un OLA de red de tres, si un equipo de red necesita habitualmente cuatro horas, esto demuestra que el SLA no es realista, no el equipo. Ese hallazgo es útil, ya que muestra si el SLA debería aumentar, si la capacidad debería crecer o si una dependencia debería desaparecer. Sin el OLA, el mismo incumplimiento simplemente aparecería como un fallo del servicio de asistencia.
El patrón es el mismo en todas partes: un equipo interno, una acción medible y un límite de tiempo vinculado al SLA. Lo que cambia es la profundidad del trabajo. Cuando una sucursal pierde la conectividad, el servicio de asistencia lo clasifica como prioridad 1 y asigna una tarea al equipo de red, cuyo OLA podría requerir una confirmación en 15 minutos y una solución temporal en dos horas, lo que deja margen dentro de un SLA de cuatro horas. Una herramienta de informes que agota el tiempo de espera es diferente, porque los administradores de bases de datos necesitan inspeccionar consultas, bloqueos y almacenamiento. Su OLA suele ser más largo, por ejemplo, un día hábil para la prioridad 3, ya que el diagnóstico es más profundo y el impacto en el negocio es menor.
Las compras muestran una tercera variante. Un usuario necesita un portátil de reemplazo y el servicio de asistencia no puede finalizar la solicitud hasta que el departamento de compras apruebe y realice el pedido. Un OLA con compras establece un objetivo de dos días hábiles para emitir el pedido, mientras que el tiempo de entrega del proveedor se rige por un contrato de respaldo. Vistos en conjunto, los tres casos apuntan a lo mismo: cada equipo recibe un objetivo que refleja la naturaleza real de su trabajo, y la suma de esos objetivos debe encajar dentro de lo prometido al cliente.
En Freshservice, las políticas de OLA establecen plazos para las tareas dentro de tickets, problemas, cambios y versiones. Cada tarea recibe una fecha de vencimiento cuando coincide con una política. Las políticas se crean como reglas de tarea bajo la configuración de políticas de SLA y OLA en el área de administración, y cada una está vinculada a un tipo de registro principal y utiliza horas hábiles o horas naturales. Cada política necesita al menos una condición, que puede leer campos del registro principal o del formulario de tarea, incluidos los campos personalizados, y las condiciones se pueden combinar con lógica de coincidencia total o parcial. Cuando existen varias políticas, se aplica la primera que coincide, por lo que las políticas más estrictas deben ir al principio: una regla general colocada primero capturaría tareas destinadas a una más estricta.
Con las horas hábiles, se aplica el horario del grupo de agentes asignado a la tarea, un detalle importante para equipos en diferentes zonas horarias o turnos distintos. Las reglas de escalamiento notifican a los destinatarios elegidos cuando una tarea permanece sin resolver después de un intervalo establecido, con hasta tres niveles para la resolución de tareas. Las fechas de vencimiento solo ayudan cuando los datos subyacentes son sólidos, por lo que la migración a Freshservice requiere tanto cuidado con los grupos y horarios como con los propios tickets.
Un porcentaje de SLA único oculta dónde se pierde el tiempo. Informar sobre el cumplimiento de OLA por grupo de resolución le da a cada gerente su propia cifra. Las preguntas que surgen al evaluar herramientas de ITSM rara vez cubren los informes por grupo, aunque esa perspectiva convierte al OLA de un documento en una rutina de gestión. Las medidas útiles incluyen tareas completadas a tiempo por grupo y prioridad, el tiempo promedio desde la creación de la tarea hasta la primera acción, la cantidad de tareas que alcanzan el segundo o tercer escalamiento y el recuento de reasignaciones por tarea. Revisadas en la misma reunión donde se discuten los resultados del SLA, estas cifras muestran si un incumplimiento comenzó en el servicio de asistencia o más adelante en el proceso.
Cuatro errores aparecen repetidamente. Copiar el SLA en el OLA no deja margen, por lo que la primera transferencia consume todo el presupuesto de tiempo. Escribir OLA sin el equipo de resolución produce objetivos que son ignorados. No revisarlos nunca permite que los volúmenes, los productos y las organizaciones cambien hasta que los números diverjan de la realidad. Y tratar el OLA como una penalización hace que la gente deje de registrar marcas de tiempo honestas y comience a cerrar tareas antes de tiempo. Presentarlo en cambio como una herramienta de programación compartida significa que un objetivo incumplido inicia una conversación sobre capacidad y prioridades en lugar de una disputa sobre quién tiene la culpa.
Los programas de OLA que logran sostenerse en el tiempo rara vez comienzan con un despliegue en toda la organización. Lo habitual es arrancar con los dos o tres equipos que reciben la mayor cantidad de tareas del servicio de asistencia y definir acuerdos únicamente para las prioridades 1 y 2, que son las que más impacto tienen sobre el SLA comprometido con el usuario final. Este alcance acotado permite que los equipos se familiaricen con los nuevos objetivos sin percibirlos como una carga administrativa adicional, y facilita detectar pronto dónde los tiempos definidos no reflejan la realidad operativa.
Después de un mes de ejecución, los datos de cumplimiento ofrecen una imagen mucho más precisa que cualquier estimación inicial: qué equipos cumplen con holgura, cuáles necesitan ajustar sus objetivos y en qué puntos de la cadena se acumulan las demoras. Con esa información, la extensión hacia otras prioridades u otros equipos se basa en evidencia en lugar de conjeturas. Es también el momento adecuado para revisar si los umbrales de escalamiento y las notificaciones están funcionando como se esperaba.
Un alcance pequeño y una propiedad clara son lo que hace que el enfoque funcione. Cada OLA necesita un responsable que conozca el objetivo, tenga visibilidad sobre su cumplimiento y pueda actuar cuando algo se desvía. Cuando esa responsabilidad está bien asignada, el SLA deja de depender de la buena voluntad entre áreas y pasa a ser el resultado de una cadena de compromisos en la que cada transferencia tiene un objetivo y un nombre detrás.
Si los incumplimientos de SLA siguen rastreándose hasta las transferencias entre equipos, nuestros expertos pueden ayudarte a mapear esas dependencias, la definición de objetivos de OLA realistas y su configuración en Freshservice, de modo que cada acuerdo quede medido y visible desde el primer día.
