Crea un tracker de SLA que calcule los plazos de los tickets, pause los temporizadores cuando respondan los clientes e informe de los incumplimientos de servicio por equipo.
Los equipos de operaciones de atención al cliente rara vez incumplen un SLA porque alguien ignore una fecha. Los plazos cambian, los tickets pasan de unas manos a otras y las respuestas de los clientes pueden detener el trabajo durante días. Una hoja de cálculo con una sola columna de fecha límite deja de funcionar si alguien no la actualiza después de cada cambio.
El primer problema consiste en tratar cada objetivo de SLA como un único plazo. El objetivo de primera respuesta mide la rapidez con la que un agente confirma que ha recibido una solicitud nueva. El objetivo de resolución mide cuánto tiempo tiene el equipo para solucionarla. Un ticket puede cumplir el objetivo de respuesta en 15 minutos y aun así incumplir el de resolución tres días después. Una sola fecha límite no muestra qué compromiso falló.
La responsabilidad crea otro problema. Un agente puede responder, un especialista investigar y un responsable aprobar la solución. Si nadie se ocupa del temporizador de SLA activo, cada persona puede pensar que otra está vigilándolo. El ticket permanece en una cola hasta que se agota el tiempo.
Pensemos en un problema de acceso a una cuenta notificado a las 10:00. El agente responde a las 10:12 y cumple el objetivo de respuesta de 30 minutos. Después pide una captura de pantalla a las 10:20. El cliente responde la tarde siguiente. Si el tracker cuenta ese tiempo de espera dentro del objetivo de resolución, responsabiliza al equipo de soporte por un tiempo que no podía utilizar. Si pausa el temporizador pero no lo reanuda, el resultado será incorrecto en el sentido contrario.
Un tracker debe ofrecer un registro operativo compartido para cada ticket: responsable, equipo, prioridad, plazos de respuesta y resolución, estado del temporizador, motivo de la pausa e historial de cambios. Así, los agentes pueden centrarse en el trabajo próximo a incumplir el plazo y los responsables pueden identificar retrasos causados por la dotación de personal, las transferencias o el tiempo de espera del cliente.
Las hojas manuales pueden funcionar con una cola pequeña y estable. Cuando los plazos dependen de la prioridad, el horario laboral, las reasignaciones y las pausas, el tracker necesita reglas coherentes.
Cada ticket necesita suficiente información para explicar quién es responsable, qué compromiso se aplica y si el temporizador debe seguir funcionando. Empieza por lo básico: cliente o cuenta, prioridad, equipo asignado, responsable del ticket y estado actual.
Después, añade los campos que controlan el plazo:
Mantén separadas la primera respuesta y la resolución completa. Un equipo puede prometer una primera respuesta en cuatro horas laborables y disponer de dos días laborables para resolver el caso. Una sola fecha límite permite que una confirmación rápida oculte un ticket sin resolver.
No pidas a los agentes que seleccionen «incumplido» manualmente. Calcúlalo a partir de la hora actual, la hora límite, el estado del ticket y las pausas válidas. Por ejemplo, un ticket incumple su SLA de resolución cuando ha pasado su hora límite, sigue abierto y el temporizador está activo.
AppMaster puede mantener esta lógica en un solo lugar. Su Data Designer permite modelar los campos de los tickets, mientras que un Business Process visual puede calcular los plazos y el estado de incumplimiento cada vez que un agente crea o actualiza un ticket.
Unas reglas claras hacen que los resultados del SLA sean justos. Define el objetivo de cada categoría de ticket antes de crear fórmulas o informes. De lo contrario, dos agentes pueden gestionar la misma solicitud de forma distinta y el recuento de incumplimientos pierde sentido.
La mayoría de los equipos varía los objetivos según la prioridad, el plan del cliente y el tipo de solicitud. Mantén pequeña la primera versión. Por ejemplo, los incidentes urgentes en producción podrían requerir una primera respuesta en una hora, los problemas de acceso de planes de pago en cuatro horas laborables y las preguntas rutinarias en dos días laborables.
Escribe cada regla en un lenguaje sencillo. «Un problema de facturación de alta prioridad para un cliente premium necesita una primera respuesta en un plazo de dos horas laborables» indica exactamente qué datos debes guardar: prioridad, plan, tipo de solicitud, hora de creación y hora de la primera respuesta.
Decide si los objetivos funcionan las 24 horas o solo durante el horario de soporte. Si el soporte opera de lunes a viernes de 9:00 a 17:00, un ticket recibido el viernes a las 16:30 con un objetivo de dos horas debe vencer el lunes a las 10:30, no el viernes por la tarde.
Documenta los días laborables, el horario de soporte, la zona horaria, los festivos y cualquier calendario independiente de incidentes disponible las 24 horas. Cuando sea posible, usa un calendario con nombre para cada política. Los equipos con clientes en distintos países pueden necesitar calendarios regionales, pero crear uno para cada cliente genera un mantenimiento innecesario.
Elige exactamente cuándo comienza el temporizador. Los tickets nuevos suelen empezar cuando el sistema los recibe. Los tickets reabiertos necesitan una regla independiente: continuar con el tiempo restante, reiniciar el temporizador original o comenzar un nuevo objetivo. Elige un método y aplícalo de forma coherente.
Asigna los cambios de política a una persona o a un grupo pequeño. Los agentes pueden corregir los datos de un ticket, pero no deberían cambiar los plazos para eliminar un incumplimiento. Guarda la versión de la política en cada registro y documenta las excepciones aprobadas con su motivo y fecha.
Una aplicación de AppMaster puede mantener las políticas en una zona de administración y aplicar la regla correspondiente cuando un ticket entra en el sistema. Así se sustituyen las fórmulas independientes de una hoja de cálculo por un único temporizador coherente.
Mantén la primera versión lo bastante sencilla como para que un responsable de operaciones pueda revisar un ticket y entender por qué cambió su plazo.
Empieza con una tabla de tickets que contenga un ID, asunto, cliente, prioridad, estado, hora de creación, hora de primera respuesta, hora de resolución, plazos, responsable asignado y equipo responsable. Cada ticket debe tener un único responsable y un único equipo actuales, aunque varias personas comenten en él.
Crea registros independientes para los equipos y las políticas de SLA. Un registro de equipo puede incluir su nombre y su horario laboral. Cada política debe indicar qué tickets cubre, sus objetivos de respuesta y resolución, el tipo de temporizador y si el tiempo de espera del cliente detiene el temporizador.
Añade un registro de festivos con la fecha, el equipo o la ubicación correspondiente y una etiqueta breve. Guarda todas las marcas de tiempo en una zona horaria coherente, normalmente UTC, y muestra la hora local en la interfaz cuando sea necesario. Mezclar zonas horarias provoca errores alrededor de los fines de semana y los cambios de horario de verano.
Conserva un historial de estados en lugar de sobrescribir el pasado. Cada entrada debe registrar el ID del ticket, el estado anterior y el nuevo, la hora del evento y la persona o regla que realizó el cambio. Registra eventos como «Esperando al cliente», «El cliente respondió», «Asignado» y «Resuelto».
Este historial explica los cambios de plazo. Si una fecha límite pasa del martes por la mañana al martes por la tarde, un responsable puede comprobar que el equipo pausó el SLA durante tres horas mientras esperaba al cliente. El Data Designer visual de AppMaster puede modelar estos registros relacionados y su Business Process Editor puede actualizar los plazos después de los cambios de estado.
Inicia el temporizador con un evento claro, como el momento en que el sistema recibe un ticket de soporte. No lo inicies cuando alguien tenga ocasión de abrir el ticket. Guarda la hora de inicio para que todos los cálculos posteriores usen el mismo punto de referencia.
Después, selecciona la política de SLA correspondiente según el plan del cliente, el tipo de ticket, la prioridad o la región. A continuación, calcula la fecha límite:
El horario laboral hace que esto sea menos sencillo de lo que parece. Si un SLA de cuatro horas comienza a las 16:00 y el soporte funciona de 9:00 a 17:00, queda una hora para ese día. El ticket vence al mediodía del siguiente día laborable, no a las 20:00.
Cuando cambie la prioridad de un ticket, conserva la hora de inicio original y aplica la regla de escalado documentada. Algunos equipos aplican el objetivo urgente desde el inicio original; otros comienzan un objetivo nuevo cuando el ticket se escala. Cualquiera de los dos enfoques puede funcionar si todo el equipo sigue la misma regla.
Muestra tanto el plazo exacto como el tiempo restante. Etiquetas como «Quedan 2 h 15 min», «vence en 1 día» y «atrasado 35 min» ayudan a los agentes a revisar una cola más rápido que las marcas de tiempo. Usa un estado neutro para los tickets en buen estado, una advertencia cuando se acerque el plazo y un estado claro de incumplimiento cuando se supere.
Pausa el temporizador únicamente cuando el equipo no pueda avanzar con el ticket sin la intervención del cliente. Los motivos habituales son esperar información, confirmación, acceso, aprobación o archivos. Un retraso interno, como esperar a un compañero, no debe pausar el SLA.
Usa un conjunto breve y claro de estados:
Cuando un agente seleccione uno de estos estados, guarda la hora exacta y el motivo de la pausa. Registra también el mensaje o evento que solicitó la respuesta del cliente. Así, los supervisores pueden comprobar que la pausa estaba justificada.
Cuando el cliente responda, reanuda el temporizador a la hora de la respuesta. Añade el tiempo de espera a total paused time y vuelve a calcular el tiempo restante según las reglas del horario laboral. Una espera del cliente de 90 minutos desplaza el plazo 90 minutos, teniendo en cuenta las horas de cierre.
Muestra el tiempo pausado en la vista del ticket. Los agentes deben saber si un ticket lleva 15 minutos o tres días esperando, y los supervisores deberían poder detectar los tickets que vuelven repetidamente al estado de espera.
Limita los motivos de pausa a los permitidos por la política de SLA. Exige un evento de solicitud al cliente antes de aceptar una pausa. En AppMaster, un Business Process puede comprobar el nuevo estado, guardar la hora de inicio de la pausa y rechazar cambios no válidos antes de actualizar el registro de SLA.
Un correo automático de «hemos recibido tu mensaje» no debe reiniciar el temporizador. Usa un mensaje entrante del cliente o una respuesta confirmada por un agente y conserva todo el historial de pausas junto al ticket.
Un cliente envía el martes a las 10:00 una pregunta sobre facturación: «¿Por qué mi factura muestra dos cargos?». El tracker crea el ticket B-184, lo asigna a Soporte y aplica el SLA de facturación. El equipo tiene cuatro horas laborables para dar una primera respuesta útil y ocho horas laborables para resolver el caso.
El soporte funciona de lunes a viernes, de 9:00 a 17:00. A las 10:35, un agente confirma que el equipo está revisando la cuenta. El temporizador de primera respuesta se detiene después de 35 minutos, por lo que quedan 3 horas y 25 minutos. El ticket cumple el objetivo de primera respuesta.
A las 11:00, el agente necesita el número de factura y marca el ticket como «Esperando al cliente». El temporizador de resolución se pausa después de una hora de trabajo activo. El tracker guarda la hora de inicio y el motivo de la pausa.
El cliente responde a las 15:30. El tracker añade las 4 horas y 30 minutos de pausa al plazo. La fecha límite de resolución original era el martes a las 18:00, por lo que el nuevo plazo pasa a ser el miércoles a las 14:30, una vez que el tiempo restante se traslada al siguiente día laborable.
Un agente resuelve el problema el miércoles a las 15:10. El ticket lleva 40 minutos de retraso. Cuenta como una resolución fuera de plazo para Soporte, mientras que la primera respuesta sigue a tiempo.
Un informe de incumplimientos debe mostrar claramente la diferencia: Soporte recibió un ticket de facturación, cumplió el objetivo de primera respuesta, incumplió el de resolución por 40 minutos y pasó 4 horas y 30 minutos esperando al cliente. La antigüedad total del ticket contaría una historia equivocada.
Un ticket incumple su SLA cuando pasa la fecha límite antes de que se realice la acción requerida. Usa la fecha límite ajustada después de las pausas válidas por espera del cliente.
Mantén separados los tickets abiertos atrasados y los tickets resueltos fuera de plazo. Los abiertos atrasados necesitan atención inmediata. Los resueltos tarde pertenecen a los informes de rendimiento. Mezclarlos oculta el trabajo urgente y hace que el informe sea más difícil de usar.
Para cada periodo, agrupa los resultados por el equipo que era responsable del ticket cuando venció el plazo. Filtra por política, prioridad y rango de fechas. Un equipo de facturación con una política de respuesta de cuatro horas no debería compararse directamente con un equipo de escalados técnicos que tiene una política de resolución de dos días laborables.
Usa recuentos junto con tasas:
Una tasa de incumplimiento del 50 % significa algo distinto cuando procede de un ticket atrasado de dos que cuando procede de 50 tickets atrasados de 100. Revisa las tendencias junto con los detalles de los tickets. Los incumplimientos frecuentes de alta prioridad pueden señalar problemas en las reglas de escalado o las transferencias, no necesariamente una carga de trabajo general excesiva.
Un informe útil permite al responsable abrir la lista de tickets atrasados, ver la política y la prioridad y comprobar quién era responsable en el momento del incumplimiento. Debe facilitar una revisión práctica del trabajo que necesita correcciones, no premiar a los equipos por cerrar tickets demasiado pronto.
Los agentes necesitan una lista de trabajo breve, no un informe lleno de tickets antiguos. Cada ticket abierto debe mostrar el responsable, el equipo, la prioridad, el plazo, el estado del temporizador y el tiempo restante. Registra de inmediato los cambios de responsable cuando un ticket pase de un equipo a otro.
Usa etiquetas sencillas para los temporizadores. «Activo» significa que el equipo es responsable de la siguiente acción. «Pausado, esperando al cliente» significa que el reloj está detenido. Muestra el tiempo activo por separado del tiempo pausado para que los usuarios entiendan por qué un ticket lleva varios días abierto.
Una vista para agentes puede incluir los tickets que vencen en las próximas cuatro horas, los tickets atrasados, los tickets pendientes de respuesta del cliente y los tickets reasignados hoy. Envía avisos antes del plazo. Un objetivo de respuesta de cuatro horas necesita recordatorios más tempranos que un objetivo de resolución de tres días.
Los responsables necesitan otra vista. Un informe semanal puede agrupar los tickets atrasados por equipo y mostrar el número de incumplimientos, el porcentaje cumplido, el tiempo medio de retraso y los tickets que siguen abiertos después de su plazo. Incluye el responsable y la última actualización de cada elemento atrasado.
Conserva un registro de auditoría de los cambios de política. Si el equipo de operaciones cambia un objetivo de ocho a 12 horas, registra quién lo cambió, cuándo y qué tickets nuevos usan la regla. Los resultados históricos deben conservar la regla aplicable cuando comenzó cada ticket.
AppMaster permite crear vistas web independientes para agentes y responsables, manteniendo los mismos datos de tickets y reglas de negocio detrás de ambas.
Unos gráficos impecables pueden contar una historia equivocada cuando las reglas subyacentes no son correctas.
No hagas cálculos con horas naturales cuando el acuerdo promete horas laborables. Un ticket abierto el viernes a las 16:30 con un objetivo de respuesta de ocho horas laborables no incumple a las 00:30 del sábado. Cuenta únicamente las horas laborables y los festivos definidos en la política.
Aplica el mismo cuidado a las pausas. El estado «esperando al cliente» solo debe pausar un SLA cuando el equipo haya enviado una solicitud clara y no pueda continuar sin una respuesta. Pausar todos los tickets con esa etiqueta oculta retrasos que corresponden al equipo.
Conserva las fechas que explican cada resultado: la fecha límite original, la política utilizada, la hora de inicio y fin de cada pausa, el motivo de la pausa, la fecha límite ajustada, la hora de resolución y la persona que cerró el ticket. Sin este historial, nadie puede comprobar por qué un ticket apareció como cumplido.
Usa una única regla de responsabilidad en los informes por equipo. Si Soporte reasigna un ticket a Facturación, no cuentes el mismo incumplimiento para ambos equipos. Puedes asignar el resultado al equipo que era responsable cuando venció el plazo y mostrar las transferencias por separado.
Exige una marca de tiempo de resolución antes de cerrar un ticket. Un estado cerrado no demuestra cuándo terminó el trabajo. Por ejemplo, si un ticket pasa de Soporte a Facturación a las 14:00 y vence a las 15:00, Facturación es responsable del incumplimiento según la regla de responsabilidad en el momento del incumplimiento. El informe puede mostrar la transferencia anterior de Soporte sin añadir un segundo incumplimiento.
Revisa todas las políticas de SLA antes de que los agentes dependan del tracker. Cada política necesita un objetivo claro, como una primera respuesta de cuatro horas o una resolución de dos días laborables, además del calendario que se aplica. Define una política predeterminada para los tickets que no coincidan con una regla de cliente, plan o prioridad.
Prueba situaciones de tiempo poco habituales, no solo casos normales:
Compara los totales del panel con la lista de tickets que hay detrás. Si un informe indica que el Equipo A tiene 12 incumplimientos, filtra los registros y cuéntalos. Esto detecta tickets duplicados, equipos sin asignar y tickets reabiertos que se han contado dos veces.
Define las reglas de acceso antes de publicar la aplicación. Los agentes deben actualizar los tickets que gestionan, los responsables necesitan informes de sus equipos y los administradores deben controlar la configuración de las políticas. En AppMaster, prueba cada rol con una cuenta independiente para que un responsable no necesite acceso de administrador para revisar los informes de incumplimientos de SLA.
Empieza con un tipo de ticket y una política de SLA. Un equipo de soporte podría comenzar con solicitudes estándar por correo electrónico y un objetivo de primera respuesta de 24 horas. Es suficiente para probar las fechas límite, las pausas aprobadas y los registros de incumplimientos.
Pide a algunos miembros del equipo de operaciones de atención al cliente que ejecuten tickets reales en el flujo de trabajo, incluidos un caso normal, un caso a la espera del cliente y un plazo incumplido. Recoge comentarios concretos. Los agentes pueden necesitar estados independientes para esperar a un cliente y esperar a otro equipo. Los responsables pueden descubrir que una etiqueta genérica de «pausado» oculta demasiada información.
Cuando una hoja de cálculo limite el proceso, crea el tracker como una aplicación sin código en AppMaster. Puedes crear formularios de tickets, definir la lógica de los temporizadores en el Business Process Editor visual y ofrecer paneles independientes a agentes y responsables. AppMaster puede generar el backend, la aplicación web y la aplicación móvil nativa cuando el tracker necesite funcionar más allá de una tabla compartida.
Al principio, mantén los informes sencillos: tickets abiertos, tickets próximos a incumplir, tickets pausados e incumplimientos por equipo. Compara algunos plazos con comprobaciones manuales, revisa los tickets incumplidos y sus periodos de pausa y cambia una regla cada vez antes de volver a probarla. Cuando el personal confíe en los cálculos, añade otro tipo de ticket o política de prioridad y repite las mismas comprobaciones.
¿Por qué debería hacer un seguimiento separado de la primera respuesta y la resolución?Registra la primera respuesta y la resolución como compromisos separados. Una confirmación rápida puede cumplir el objetivo de respuesta mientras el ticket sigue sin resolverse y supera su plazo de resolución.
¿Cuándo debe comenzar un temporizador de SLA?Inicia el temporizador cuando el sistema recibe el ticket y aplica después la política de SLA que corresponda a su prioridad, plan, tipo o región. Guarda esa hora de inicio para que las actualizaciones posteriores usen el mismo punto de referencia.
¿Cómo calculo los plazos de SLA durante el horario laboral?Cuenta únicamente las horas de soporte incluidas en la política. Por ejemplo, si el soporte cierra a las 17:00 y un objetivo de dos horas comienza a las 16:30, los 90 minutos restantes pasan al siguiente día laborable.
¿Cuándo puede un equipo pausar un temporizador de SLA?Pausa el temporizador únicamente cuando el equipo necesite algo del cliente para poder continuar, como acceso, aprobación, archivos o información solicitada. No lo pauses por colas internas, transferencias o retrasos de personal.
¿Qué debe ocurrir cuando un cliente responde a un ticket pausado?Registra la hora de inicio de la pausa, un motivo concreto y la solicitud al cliente que la originó. Cuando el cliente envíe una respuesta relevante, reanuda el temporizador y conserva todo el historial de pausas en el ticket.
¿Qué equipo es responsable de un incumplimiento de SLA después de transferir un ticket?Asigna a cada ticket un único responsable actual y un equipo responsable. Para los informes por equipo, cuenta el incumplimiento contra el equipo que tenía el ticket cuando venció el plazo y muestra las transferencias anteriores por separado.
¿Qué deben ver los agentes en un tracker de SLA?Muestra el plazo exacto, el tiempo restante, el estado del temporizador, el responsable, el equipo y la prioridad. A los agentes también les resultan útiles colas breves con los tickets próximos a vencer, atrasados y pendientes de respuesta del cliente.
¿Qué métricas de SLA deben informar los responsables?Mantén separados los tickets abiertos atrasados y los tickets resueltos fuera de plazo. Informa del total de tickets con SLA, las resoluciones a tiempo, los tickets abiertos atrasados, las resoluciones tardías y la tasa de incumplimiento. Después, permite abrir los registros de los tickets correspondientes.
¿Cómo pruebo un tracker de SLA antes de lanzarlo?Prueba tickets creados cerca del cierre, antes de fines de semana y festivos, después de una espera del cliente y durante una transferencia de equipo. Cierra también un ticket después de su plazo y verifica que el tracker registre un único incumplimiento con la política correcta.
¿Puedo crear un tracker de SLA sin programar?Sí. AppMaster permite modelar tickets, políticas, equipos, festivos e historial de estados en su Data Designer. Puedes usar Business Processes visuales para calcular plazos, gestionar pausas aprobadas y crear vistas independientes para agentes y responsables a partir de los mismos datos.
14 jul 2026
9 min
13 jul 202610 min
08 jul 20267 minExperimente con AppMaster con plan gratuito.
Cuando esté listo, puede elegir la suscripción adecuada.
