Los SLA son promesas para los clientes: los OLA se encargan de que tus equipos internos puedan cumplirlas. Con Trupeer, puedes ahorrar horas en la redacción de OLA empezando con una plantilla de acuerdo de nivel operativo gratuita, personalizándola con tus directrices de marca y convirtiendo el OLA en un recorrido en vídeo que alinea a cada equipo interno con unos estándares de servicio compartidos.

¿Qué es una plantilla de acuerdo de nivel operativo?

Un acuerdo de nivel operativo, u OLA, es un acuerdo interno entre equipos de la misma organización que sustenta un compromiso adquirido con alguien ajeno a ella. El service desk promete al negocio una resolución en cuatro horas para incidentes mayores. Esa promesa solo se mantiene si el equipo de red, el equipo de aplicaciones y cualquier otra parte de la cadena desempeñan su papel dentro de un tiempo conocido.

El OLA es donde se redactan esas partes internas. No es un contrato: nadie paga a nadie, y el cumplimiento es totalmente de gestión, lo cual es a la vez su debilidad y la razón por la que puede ser honesto de formas que un contrato no puede.

Una plantilla de acuerdo de nivel operativo es la estructura reutilizable: las partes, los servicios cubiertos, los compromisos, las medidas y los mecanismos de revisión. Encontrar plantillas de este tipo es fácil. La mayoría te permitirá redactar un OLA que se cumple al 100% y aun así falla, que es de lo que trata el resto de esta página.

OLA vs SLA: a qué se compromete cada uno realmente

En esta familia hay tres documentos y mezclarlos causa problemas reales.

Un acuerdo de nivel de servicio es el compromiso con el cliente o con el negocio. Se redacta en los términos del cliente, normalmente de extremo a extremo, y es lo que se informa a personas fuera de la cadena de entrega.

Un acuerdo de nivel operativo es interno, entre equipos que dependen de la misma organización. Existe únicamente para que el SLA sea alcanzable y nunca debería incluir un compromiso que el SLA no necesite.

Un contrato de soporte es el acuerdo comercial con un tercero, un proveedor o un proveedor subcontratado, que respalda la misma cadena. Tiene fuerza legal, que el OLA no tiene, y normalmente es el menos flexible de los tres, así que debe acordarse antes del SLA y no después.

La consecuencia práctica es una regla de secuenciación. Acordar primero los contratos de soporte; después, el SLA según lo que permiten esos contratos; y, por último, los OLA que cubren el resto. Las organizaciones que lo hacen en el orden inverso prometen al negocio algo que ningún proveedor ha acordado entregar.

Cómo personalizar esta plantilla en Trupeer

Paso 1: Abre la sección Plantillas

Ve a la sección Plantillas desde la navegación principal.

Paso 2: Selecciona y abre una plantilla

Haz clic en cualquier plantilla con la que quieras trabajar para abrirla.

Paso 3: Expande la vista de la plantilla

Si es necesario, expande la vista de la plantilla para ver el diseño completo y los detalles con claridad.

Paso 4: Edita la plantilla

Haz clic en Editar para empezar a modificar la plantilla seleccionada.

Dentro del editor, puedes:

• Añadir secciones nuevas

• Definir o actualizar reglas de formato

• Añadir un logotipo y ajustar su posición y la configuración relacionada

Paso 5: Guarda tu plantilla personalizada

Después de realizar todos los cambios necesarios, haz clic en Guardar para almacenar la plantilla actualizada como tuya.

Paso 6: Previsualiza y ajusta la plantilla

Cuando quieras ver cómo se ve tu plantilla personalizada, abre la Previsualización.

Desde la pantalla de previsualización, puedes seguir haciendo ajustes directamente si es necesario, asegurando que la plantilla aparezca exactamente como la quieres.

Con una plantilla de acuerdo de nivel operativo puedes:

• Ahorra horas en la redacción: Omite la página en blanco con una estructura creada para OLA.

• Alinea equipos internos: Los campos integrados garantizan que cada equipo conozca su responsabilidad.

• Mantén el estilo de marca: Aplica tu logotipo, tipografías y colores usando el kit de marca de Trupeer.

• Protege los SLA de los clientes: Los OLA sólidos evitan que las transferencias internas rompan las promesas externas.

• Estandariza en todos los servicios: Usa la misma plantilla de OLA para cada acuerdo interno.

• Llega a equipos globales: Traduce OLA a 65+ idiomas con un solo clic.

Por qué todos los equipos cumplen su OLA y aun así el SLA se incumple

Este es el patrón más común en la gestión de servicios y parece una contradicción.

Todos los equipos informan en verde. La red responde dentro de su hora. Las aplicaciones resuelven dentro de sus dos. El service desk hace la clasificación inicial en treinta minutos. El informe mensual de cumplimiento del OLA es fácil de leer. Y aun así, el SLA del cliente se incumple en un tercio de los incidentes mayores.

La explicación es que los OLA miden el tiempo dentro de los equipos, mientras que el SLA mide el tiempo de extremo a extremo. La diferencia entre esos dos números es el tránsito: el ticket que queda en una cola tras la reasignación, esperando a que lo recojan, o que se devuelve para pedir más información.

Ese tiempo no pertenece a nadie. No está en el OLA de ningún equipo, no se informa en ningún sitio y, con frecuencia, es mayor que todo el tiempo de trabajo combinado.

Lo que significa que el fallo es estructural, no un problema de rendimiento. Añadir presión a los equipos para cumplir sus números actuales no ayudará, porque ya los están cumpliendo.

El OLA gobierna la transferencia, no el trabajo

El replanteamiento que lo soluciona es pequeño y cambia para qué sirve el documento.

Un OLA redactado de la forma habitual compromete a un equipo con cuánto tarda su propio trabajo. Esa es la parte que el equipo controla, así que es la parte con la que está dispuesto a firmar, y es lo menos útil para acordar porque nunca fue la variable.

Un OLA bien redactado compromete a los equipos con la interfaz entre ellos. Qué debe haber en un ticket antes de pasarlo. Cuánto tiempo tiene el equipo receptor para recogerlo. Qué ocurre cuando el ticket está incompleto. Quién es responsable del ticket durante el intervalo.

Una vez que la transferencia es el tema, los dos campos que faltaban se vuelven evidentes. Los criterios de entrada, es decir, qué debe ser cierto antes de que empiece el reloj del equipo receptor. Y una asignación explícita del propio tiempo de tránsito, para que el hueco entre equipos sea el número de alguien y no el de nadie.

Todo lo demás en una plantilla de OLA es administración. Esos dos campos son el documento.

Criterios de entrada: qué debe ser cierto antes de que empiece el reloj

El comportamiento más destructivo en una cadena con varios equipos es el “rebote”: un ticket llega sin suficiente información, el equipo receptor lo devuelve y su reloj se reinicia.

El “rebote” es totalmente racional desde el punto de vista del equipo receptor. No pueden trabajar el ticket y su cumplimiento se mide por su tiempo de resolución, así que devolverlo los protege a ambos. Además, es donde se va una gran parte del tiempo transcurrido y es invisible en cualquier informe que mida los equipos por separado.

Los criterios de entrada lo solucionan moviendo la obligación hacia arriba. Cada fila de OLA enumera los campos específicos que deben completarse para que ese equipo acepte el trabajo. Para una transferencia de red, podría ser el nombre del dispositivo, el código del sitio, el texto exacto del error, la hora en que se observó por primera vez y si otros usuarios se ven afectados. Para una transferencia de aplicaciones, podría ser el usuario, la referencia de la transacción, los pasos para reproducirlo y una captura de pantalla.

Entonces cambia la redacción del compromiso del equipo que envía. No “clasificar en treinta minutos”, sino “pasar un ticket que cumpla los criterios de entrada en treinta minutos”. Mismo reloj, distinta obligación, y el incentivo ahora recae en el equipo que realmente puede reunir la información.

El equipo receptor conserva el derecho de rechazar, y debería ser un derecho limitado: el rechazo solo es válido cuando falta de verdad un criterio de entrada con nombre, y cada rechazo se registra con el motivo. Registrar es lo que convierte el “rebote” de un hábito invisible en un número que alguien tiene que explicar.

Plantilla gratuita de acuerdo de nivel operativo: la estructura para copiar

Copia desde aquí. Los campos marcados con un asterisco son los que omiten las plantillas estándar.

Encabezado. Referencia y versión del OLA. Partes, es decir, los dos equipos por nombre. El SLA o el servicio que respalda. Fecha de vigencia, fecha de revisión y el responsable nombrado en cada lado.

Alcance. Qué servicios, sistemas o tipos de solicitud cubre, y qué no cubre explícitamente.

Horario de servicio. Cobertura para cada parte, incluidas las disposiciones fuera de horario y en qué se diferencian. Los horarios desajustados entre dos equipos de la misma cadena es una brecha común y silenciosamente fatal.

Tabla de compromisos. Una fila por tipo de solicitud o prioridad, con: el desencadenante, los criterios de entrada, el tiempo de respuesta, el tiempo de resolución o de devolución, el tiempo de tránsito asignado y el punto de escalado.

Escalado. A quién se contacta en cada etapa, por qué vía y después de cuánto tiempo. Incluye la ruta fuera de horario.

Dependencias. Lo que este equipo necesita de otros, incluidos los posibles contratos de soporte con un tercero, con sus propios tiempos indicados para que se pueda comprobar el cálculo.

Medición. Qué se mide, desde qué sistema, por quién y con qué frecuencia se informa. Incluye tasa de rebote junto con la respuesta y la resolución, ya que es la métrica que revela si los criterios de entrada están funcionando.

Excepciones. Circunstancias acordadas en las que los compromisos no se aplican, como durante un incidente mayor declarado o un periodo de congelación de cambios.

Revisión. Fechas y qué desencadena una revisión fuera del ciclo.

Copia hasta aquí. Mantén el contenido en dos o tres páginas. Un OLA lo bastante largo como para requerir leerlo dos veces no se consultará durante un incidente, y es precisamente durante un incidente cuando importa.

Cómo comprobar que los OLA realmente suman hasta el SLA

Antes de firmar nada, haz las cuentas. Tarda quince minutos y casi siempre se omite, porque los OLA se negocian uno a uno con equipos distintos en días distintos.

Dos reglas hacen que esto sea útil. El tiempo de tránsito debe aparecer como una línea propia, porque ese es el objetivo. Y cada cadena necesita margen, porque una cadena que suma exactamente hasta el SLA incumple cuando algo sale ligeramente mal. Un margen razonable es del 10% al 15%.

Si la suma supera el SLA, tienes tres opciones honestas: renegociar el SLA, reducir el tiempo de un equipo con algo que lo haga posible, o eliminar una transferencia. Lo que no puedes hacer es firmar OLA que garanticen un incumplimiento y luego gestionar el rendimiento en función de ellos, que es la postura en la que se encuentran un número sorprendente de service desks.

El minorista cuyo tiempo de tránsito fue mayor que su trabajo

Rendlesham Group gestiona varias marcas minoristas con unos seis mil empleados y un service desk de TI interno que da soporte a las tiendas y a la sede central.

Su SLA de incidentes P2 para el negocio era de cuatro horas hasta la resolución. La tasa de incumplimiento en P2 se había mantenido alrededor del 38% durante dos años. El cumplimiento del OLA de cada equipo se informaba mensualmente y todos los equipos estaban en verde.

Alguien, por fin, registró con marca de tiempo cada cambio de estado en 120 incidentes P2 incumplidos.

El tiempo total transcurrido, en mediana, fue de seis horas y cincuenta y un minutos. De ese tiempo, tres horas y doce minutos fueron tiempo dentro de un equipo trabajando activamente el ticket. Tres horas y treinta y nueve minutos fueron tránsito: estar en una cola tras la reasignación, esperar a que lo recojan o que lo devuelvan.

Más de la mitad del tiempo transcurrido en un incidente incumplido no era responsabilidad de nadie y no se informaba en ningún sitio.

El mayor contribuyente individual fue el “rebote”. Cuarenta y uno de los 120 tickets se habían devuelto al menos una vez por un equipo receptor por información insuficiente, y cada rebote añadió, además, una mediana de una hora y veinte minutos, además de reiniciar el reloj de ese equipo. Las dos razones más comunes fueron que no había texto de error ni una captura adjunta, y que no había confirmación de qué tienda se vio afectada por el incidente.

Los cambios fueron acotados. Los criterios de entrada se redactaron en cada fila de OLA. El compromiso del service desk se reescribió de “clasificar en treinta minutos” a “pasar un ticket que cumpla los criterios de entrada en treinta minutos”. Se asignaron quince minutos de tránsito por cada transferencia y se contabilizaron contra el equipo receptor una vez que se cumplieron los criterios de entrada. Y cada rebote se registró con un motivo.

En los dos trimestres siguientes, la tasa de rebote bajó del 34% de los P2 al 9%. El tiempo de tránsito en mediana bajó de tres horas y treinta y nueve minutos a una hora y seis. La tasa de incumplimiento de P2 bajó del 38% al 11%.

No cambió materialmente el tiempo interno de resolución de ningún equipo. Nadie trabajó más rápido. El tiempo que antes no era de nadie simplemente pasó a ser de alguien.

Cómo redactar un acuerdo de nivel operativo, paso a paso

Empieza por el SLA, no por una plantilla. Escribe qué se ha prometido al cliente, de extremo a extremo, con su definición de reloj.

Mapa la cadena. Cada equipo que toca una solicitud de ese tipo, en orden, incluyendo cualquier tercero. Dibuja las transferencias como pasos propios, no como flechas.

Para cada transferencia, haz una pregunta al equipo receptor: ¿qué necesitas en el ticket para empezar a trabajar sin tener que volver a nosotros? Esa respuesta, escrita, son tus criterios de entrada. Los equipos responden esto con facilidad y precisión, y la mayoría nunca se lo han preguntado.

Ahora acuerda los tiempos, trabajando dentro de las cuentas anteriores en lugar de equipo por equipo. Hacerlo como una sola conversación con todos presentes lleva una hora y evita por completo el problema de la suma.

Asigna el tránsito explícitamente y decide quién lo gestiona. Quince minutos por transferencia es un buen punto de partida y debería contabilizarse contra el equipo receptor.

Acordar la medición, incluida la tasa de rebote, y de dónde proviene. Si tus herramientas no pueden generarla, vale la pena saberlo antes de firmar, en lugar de en la primera revisión.

Luego ejecútalo durante un trimestre antes de formalizarlo. Las primeras versiones suelen estar mal en uno o dos puntos y es más fácil corregirlas antes de que existan firmas.

Errores comunes de OLA y lo que cuesta cada uno

Medir equipos y no la cadena. Todos están en verde y el SLA se incumple. El fallo más común y el tema de esta página.

Sin criterios de entrada. El “rebote” se convierte en la defensa racional del equipo receptor y el tiempo transcurrido crece de forma invisible.

Tiempos que no suman. El conjunto de OLA garantiza un incumplimiento y nadie lo ha sumado nunca.

Horarios de servicio desajustados. Un equipo cubre hasta las seis, el siguiente hasta las cinco. Todo lo que llegue después de las cinco se queda para la noche, algo que ningún informe muestra porque ambos equipos están dentro de su horario.

Copiar el lenguaje del SLA en un OLA. Las penalizaciones, los créditos y la redacción legal no pertenecen aquí, y al importarlos los equipos negocian a la defensiva en lugar de hacerlo con honestidad.

Redactar un OLA con un tercero. Si el dinero cambia de manos, es un contrato de soporte y necesita participación de procurement y legal, no una plantilla. Nuestro IT procurement policy template cubre la ruta de aprobación.

Firmar y archivar. Un OLA que nadie revisa describe una cadena de servicio que deja de existir en aproximadamente un año.

Cómo gestionar y revisar los OLA cuando ya existen

Informa sobre la cadena, no sobre los componentes. Importa un solo número: el rendimiento de extremo a extremo frente al SLA, y las métricas del OLA existen para explicarlo, no para mantenerse por sí solas.

Revisa trimestralmente, con todas las partes en la misma sala. Las revisiones bilaterales reproducen el problema original, porque los huecos viven entre las partes que nunca están en la misma conversación.

Observa tres cosas. La tasa de rebote por transferencia, que te indica dónde hay que mejorar los criterios de entrada. El tiempo de tránsito por transferencia, que te muestra dónde se están formando las colas. Y la proporción de incidentes que siguieron una ruta que el OLA no describe, lo que te dice que el documento se ha desviado de la realidad.

Activa una revisión fuera del ciclo cuando un equipo se reorganice, cuando un sistema pase de un equipo a otro, cuando entre un nuevo tercero en la cadena o cuando cambie el SLA subyacente. Las cuatro situaciones ocurren con más frecuencia que lo que asume el ciclo anual de revisión.

¿OLA, SLA o contrato de soporte: cuál necesitas?

Si el compromiso es con alguien fuera de tu organización de entrega, ya sea un cliente externo o una unidad de negocio interna que recibe el servicio, es un SLA.

Si es entre dos equipos dentro de la misma organización y no cambia dinero de manos, es un OLA.

Si es con un proveedor bajo un acuerdo comercial, es un contrato de soporte y necesita legal y procurement en lugar de esta plantilla.

El caso incómodo es el del centro de servicios compartidos o un equipo interno con un modelo de chargeback, que se sitúa entre un OLA y un SLA. La respuesta práctica es redactarlo como un OLA y eliminar cualquier lenguaje sobre penalizaciones, porque los regímenes internos de penalización producen de forma fiable comportamientos defensivos y un servicio peor.

Para las definiciones orientadas al cliente y el texto de respuesta que se sitúan encima de todo esto, nuestro help desk response template y ticket and resolution template cubren la capa que realmente ve el usuario final.

¿Puedo conseguir una plantilla de OLA en Word o Excel?

Word para el acuerdo, porque el alcance, las excepciones y las secciones de revisión son texto y el documento se distribuye para su aprobación y firma.

Excel para dos partes específicamente. La tabla de compromisos, donde quieres los criterios de entrada, los tiempos y la asignación de tránsito en columnas que puedas ordenar y comprobar. Y la hoja de cálculo, donde cada cadena suma contra su SLA y marca cualquier cosa sin margen. Esa segunda hoja es la que merece la pena construir primero, ya que a menudo cambia lo que ibas a acordar.

PDF para la versión firmada, exportada desde la fuente. Mantén la versión de trabajo editable, porque los criterios de entrada necesitarán ajustes después del primer trimestre de rebotes reales.

Cómo mantener el OLA y la realidad sincronizados

Un OLA describe una cadena de trabajo que cambia constantemente. Los equipos se reorganizan, los sistemas se mueven, las herramientas cambian y el documento es lo último que actualiza alguien.

La parte que se queda obsoleta más rápido son los criterios de entrada, porque describen qué debe contener un ticket y lo que debe contener un ticket depende de cómo funcionan realmente las herramientas actuales y el proceso actual.

Trupeer AI ayuda haciendo que los procedimientos subyacentes sean baratos de mantener actualizados. Registra una vez el proceso de clasificación inicial o de transferencia y obtienes un procedimiento escrito con los pasos y las pantallas capturados, que el service desk puede seguir y que muestra claramente qué información se está recopilando. Cuando cambien las herramientas, vuelve a registrarlo en lugar de reescribirlo.

Regístralo. Ponle marca. Tradúcelo. Trupeer it.

El SOP creator cubre los procedimientos de los que depende el OLA, y nuestro IT SOP template cubre cómo decidir cuáles de ellos merece la pena mantener. Documentation mantiene los acuerdos y los procedimientos juntos, y las instrucciones de configuración están en la document template setup guide.

Preguntas frecuentes

¿Hay una plantilla gratuita de acuerdo de nivel operativo en Word?

La estructura de arriba se pega directamente en Word o Google Docs, incluidos los campos de criterios de entrada y la asignación de tránsito que omiten las plantillas estándar. No hay descarga con acceso restringido ni formulario. Mantén la tabla de compromisos en una hoja de cálculo y consúltala, porque esa parte necesita ordenarse y sumarse.

¿Hay una plantilla gratuita de acuerdo de nivel operativo en PDF?

Exporta la versión firmada a PDF una vez que las partes la hayan acordado y mantén la copia de trabajo editable. Los criterios de entrada casi siempre necesitan ajustes después del primer trimestre, cuando ya puedes ver por qué se están rebotando realmente los tickets.

¿Hay una plantilla gratuita de acuerdo de nivel operativo en Excel?

Excel es el lugar adecuado para la tabla de compromisos y para la comprobación de las cuentas. Una hoja con una fila por transferencia y un total acumulado frente al SLA, marcando cualquier cadena con menos de un 10% de margen. Construir esa hoja antes de negociar suele cambiar lo que se termina negociando.

¿Dónde puedo encontrar un ejemplo de OLA en PDF?

Varios proveedores de ITSM y organismos gubernamentales publican plantillas de OLA y SLA como documentos, y son razonables para la estructura. Léalos por las secciones más que por el contenido, ya que los compromisos de cualquier ejemplo publicado son la cadena de otra persona y los tiempos no significan nada fuera del SLA para el que se construyeron.

¿Quién firma un acuerdo de nivel operativo?

El responsable nombrado en cada lado, que debería ser el gerente responsable de la entrega de ese equipo y no una función de gestión de servicios. Un OLA firmado solo por gestión de servicios es una aspiración, porque la persona que tiene que dotarlo de recursos no estaba en la sala.

¿Cuántos OLA necesita un service desk?

Menos de lo que la mayoría de los equipos esperan. Uno por cada par de equipos que intercambian trabajo con regularidad, cubriendo todos los tipos de solicitud en una sola tabla de compromisos, en lugar de uno por cada servicio. Más allá de una docena, el mantenimiento se convierte en la limitación y los documentos se desactualizan más rápido de lo que se revisan.

¿Un acuerdo de nivel operativo debería tener penalizaciones?

No. No existe una relación legal para exigir su cumplimiento y los regímenes internos de penalización producen de forma fiable un comportamiento defensivo: los equipos rechazan el trabajo, discuten cuándo empieza el reloj y optimizan para su propio número en lugar del resultado. Informa sobre la cadena de extremo a extremo en su lugar, lo que hace visible la consecuencia compartida sin que nadie tenga que ser sancionado.

¿Con qué frecuencia deben revisarse los OLA?

Trimestralmente con todas las partes presentes, además de una revisión fuera del ciclo siempre que un equipo se reorganice, cuando un sistema pase de un equipo a otro, cuando entre un tercero en la cadena o cuando cambie el SLA subyacente. El ritmo trimestral detecta la desviación y los desencadenantes detectan los cambios que hacen que el documento sea incorrecto de un día para otro.