Restablecimiento de los SLA de Zendesk al responder o cambiar el estado: Una guía completa

Gestionar los Acuerdos de Nivel de Servicio (SLA, por sus siglas en inglés) en Zendesk puede sentirse como intentar atrapar humo. Configuras políticas, defines objetivos y observas cómo los temporizadores se agotan. Pero entonces sucede algo inesperado: cambia la prioridad de un ticket, un cliente envía un mensaje que no necesita respuesta o tu equipo marca un ticket como pendiente. De repente, esos temporizadores de SLA se comportan de maneras que no anticipaste.

Comprender cuándo se restablecen o se pausan los temporizadores de SLA de Zendesk no es solo un detalle técnico. Es la diferencia entre informes precisos y pasar horas cada semana explicando manualmente por qué las métricas parecen "incorrectas" a tu equipo de liderazgo. Esta guía desglosa exactamente cómo funcionan estas mecánicas para que puedas configurar tus políticas con confianza.

Comprender la diferencia: Restablecer vs. pausar

Antes de sumergirnos en métricas específicas, aclaremos dos comportamientos fundamentalmente diferentes:

Restablecer significa que el temporizador comienza a contar desde cero nuevamente. Cualquier tiempo transcurrido se borra y el SLA comienza de nuevo. Esto sucede cuando eventos específicos activan un nuevo ciclo de medición.

Pausar significa que el temporizador se detiene temporalmente pero recuerda dónde lo dejó. Cuando las condiciones cambian, el temporizador se reanuda exactamente desde donde se pausó. No se pierde ni se gana tiempo.

Aquí está el por qué esta distinción importa. Cuando un temporizador se restablece, tu equipo obtiene una ventana de objetivo completamente nueva. Cuando se pausa, la presión se mantiene porque ese plazo original aún se avecina. Malinterpretar qué comportamiento se aplica a qué métrica conduce a una falsa confianza o a un pánico innecesario.

Pausa de SLA de Zendesk en el estado: Cuándo los temporizadores se detienen temporalmente

Las métricas de resolución se comportan de manera diferente a las métricas de respuesta. En lugar de restablecerse en las acciones del agente, se pausan según el estado del ticket. Esto refleja mejor la realidad de los flujos de trabajo de soporte donde el trabajo no siempre es continuo.

Tiempo de espera del solicitante

El Tiempo de espera del solicitante mide el tiempo total que un cliente pasa esperando a tu equipo durante todo el ciclo de vida del ticket. La parte inteligente es que se pausa automáticamente cuando el ticket está en estado Pendiente (esperando al cliente).

El temporizador se ejecuta mientras el ticket está en estado Nuevo, Abierto o En espera. Cuando lo marcas como Pendiente, la pausa se activa. Cuando el cliente responde y el estado vuelve a Abierto, el temporizador se reanuda exactamente donde lo dejó.

Esta métrica te brinda la visión más centrada en el cliente de tu rendimiento. Responde a: "¿Cuánto tiempo esperó realmente esta persona por nosotros?" no "¿Cuánto tiempo existió el ticket?"

Tiempo de trabajo del agente

El Tiempo de trabajo del agente lleva el concepto de pausa aún más lejos. Solo cuenta el tiempo cuando el ticket está en estado Nuevo o Abierto, pausando tanto en Pendiente COMO en En espera.

¿Por qué la diferencia? En espera normalmente significa que estás esperando a un tercero: un proveedor, un transportista, otro departamento. Si estás esperando a otra persona, no estás trabajando activamente en el ticket, por lo que la métrica no debería contar en contra de tu equipo.

Esta métrica es particularmente útil para los equipos que escalan tickets a terceros externos. Mide solo el tiempo que los tickets están genuinamente disponibles para que tus agentes trabajen en ellos.

Actualización Pausable

La Actualización Pausable combina conceptos de ambas categorías. Al igual que la Actualización Periódica, mide el tiempo entre los comentarios del agente. Pero al igual que las métricas de resolución, se pausa cuando el ticket está Pendiente.

El objetivo se activa cuando un agente hace su primer comentario público mientras el ticket está en estado Nuevo, Abierto o En espera. Se pausa si el ticket pasa a Pendiente. Se reanuda cuando el ticket vuelve a Abierto o En espera.

Una peculiaridad a tener en cuenta: si un agente envía un comentario público y cambia el estado a Pendiente en la misma acción, la métrica de Actualización Pausable no se aplicará hasta que el ticket se envíe por primera vez en Nuevo, Abierto o En espera con un comentario público. Esto confunde a algunos equipos que esperan que la métrica comience de inmediato.

Casos límite comunes y soluciones alternativas

Incluso con reglas claras, los escenarios del mundo real complican el seguimiento de los SLA. Estos son los casos límite más comunes que encuentran los equipos de soporte.

El escenario de "No se necesita respuesta"

Tu agente resuelve un ticket. El cliente responde con un simple "gracias" o confirmación de que la solución funcionó. Técnicamente, esto crea un nuevo objetivo de Tiempo de Próxima Respuesta porque hay un comentario del cliente sin respuesta. Pero responder se siente incómodo e innecesario.

Cuando el cliente comenta nuevamente sobre un problema genuinamente nuevo, el temporizador de SLA cuenta desde su mensaje original de "gracias", no desde la nueva declaración del problema. Esto crea informes de incumplimiento falsos y sesga tus métricas.

Una solución alternativa implica el uso de una macro que agrega un breve comentario público (que cumple con el SLA) y luego lo hace inmediatamente privado para que el cliente nunca lo vea. Otro enfoque mueve temporalmente el ticket a una política de SLA diferente que no impone el Tiempo de Próxima Respuesta, utilizando un activador para devolverlo si el cliente envía otro mensaje.

Cambios de prioridad e incumplimientos falsos

Un ticket llega como prioridad Normal con un objetivo de resolución de 24 horas. Después de la investigación, te das cuenta de que es más urgente y lo cambias a prioridad Alta con un objetivo de 4 horas. ¿El problema? Si el ticket ya se incumplió bajo la prioridad Normal, ese incumplimiento permanece en tus informes, aunque el ticket ahora se esté manejando adecuadamente bajo los objetivos de prioridad Alta.

Zendesk aplica nuevos objetivos de prioridad en el futuro, pero no ajusta retroactivamente los datos históricos de incumplimiento. Esto causa dolores de cabeza a los equipos que intentan informar con precisión sobre el rendimiento del SLA.

Algunos equipos solucionan esto creando tickets completamente nuevos cuando los cambios de prioridad son significativos, aunque esto pierde el historial de la conversación. Otros mantienen hojas de cálculo de seguimiento separadas para anotar qué incumplimientos fueron "legítimos" versus "artefactos de cambio de prioridad".

Tickets reabiertos

Cuando se reabre un ticket resuelto, las diferentes métricas se comportan de manera diferente:

• Tiempo de Primera Respuesta y Tiempo de Próxima Respuesta: Activan nuevos objetivos si se reabre con un comentario público del cliente
• Actualización Periódica y Actualización Pausable: Activan nuevos objetivos solo si se reabre con un comentario público del agente
• Tiempo de Trabajo del Agente y Tiempo de Espera del Solicitante: Reactivan el mismo objetivo, tratando el tiempo en estado Resuelto como una pausa
• Tiempo Total de Resolución: Continúa contando desde la creación del ticket, tratando el tiempo Resuelto como una pausa

Comprender estos matices ayuda a explicar por qué los tickets reabiertos a veces parecen tener un comportamiento extraño del SLA.

Mejores prácticas para configurar políticas de SLA

Después de comprender las mecánicas de restablecimiento y pausa, ¿cómo deberías configurar realmente tus políticas? Aquí hay recomendaciones prácticas de equipos que han aprendido por las malas.

Comienza de forma sencilla. Elige el Tiempo de Primera Respuesta más una métrica de resolución (el Tiempo de Espera del Solicitante suele ser la opción más centrada en el cliente). Siéntete cómodo con estos conceptos básicos antes de agregar complejidad como el Tiempo de Próxima Respuesta o la Actualización Periódica.

Decide cuidadosamente entre el horario comercial y las horas del calendario. El horario comercial es más justo para tu equipo porque no cuenta las noches y los fines de semana. Pero los clientes experimentan el tiempo del calendario. Un ticket enviado el viernes por la noche se siente como si hubiera estado abierto todo el fin de semana, incluso si el reloj de tu horario comercial no ha avanzado mucho. Algunos equipos utilizan el horario comercial para los informes internos y las horas del calendario para los compromisos con el cliente.

Ordena tus políticas correctamente. Zendesk las evalúa de arriba a abajo y aplica la primera coincidencia. Coloca tus políticas más restrictivas en la parte superior y las políticas generales más amplias en la parte inferior. Un error común es tener una política genérica que coincida con todo antes de que se evalúen las políticas específicas.

Considera las diferencias de canal. Las conversaciones de chat tienen diferentes expectativas que los tickets de correo electrónico. Es posible que desees un Tiempo de Primera Respuesta de 5 minutos para el chat, pero un objetivo de 1 hora para el correo electrónico. Utiliza condiciones para enrutar diferentes canales a diferentes políticas.

Establece objetivos realistas basados en la capacidad real, no en objetivos ambiciosos. Un SLA que incumples constantemente es peor que ningún SLA. Entrena a tu equipo para que ignore la métrica y erosiona la confianza con los clientes que ven que no se cumplen los compromisos.

Mejorar el rendimiento de SLA de Zendesk con IA

Comprender las mecánicas de SLA es importante. Pero, ¿no sería mejor alcanzar esos objetivos sin esfuerzo?

Las herramientas modernas de IA te ayudan a resolver tickets más rápido y de manera más consistente. eesel AI ofrece AI Agent y AI Copilot que funcionan directamente con tu integración de Zendesk para mejorar tus métricas.

Nuestro AI Agent maneja preguntas comunes y repetitivas al instante. ¿Un cliente pregunta sobre restablecimientos de contraseñas, estado de pedidos o solución de problemas básicos? Obtiene una respuesta precisa en segundos, no en horas. Tu Tiempo de Primera Respuesta se vuelve efectivamente instantáneo para estos tickets, y tus tiempos de resolución disminuyen porque los problemas de rutina nunca llegan a una cola humana.

Para problemas complejos que necesitan el toque humano, nuestro AI Copilot redacta respuestas extrayendo información de tu base de conocimientos, tickets anteriores y documentación conectada. Los agentes revisan y envían en lugar de comenzar desde cero. Esto reduce el Tiempo de Trabajo del Agente y les da a los clientes respuestas más rápido.

Puedes simular nuestra IA en tus tickets históricos antes de ponerla en marcha. Ve exactamente cómo se habría desempeñado en comparación con tus objetivos de SLA existentes. Ajusta las configuraciones en función de datos reales en lugar de esperar lo mejor.

Dado que nos integramos directamente con Zendesk, no hay una configuración compleja ni cambios en el flujo de trabajo. Tus políticas de SLA existentes siguen midiendo como siempre, pero los números se ven mejor.