Comprendiendo el tiempo de propiedad del objetivo de SLA de Zendesk: Una guía completa

Cuando su equipo de soporte escala un ticket a Ingeniería, ¿quién es responsable de cumplir con el SLA (Service Level Agreement)? Si el cliente está esperando y el ticket ha rebotado entre tres equipos internos diferentes, ¿cómo rastrea quién es responsable de la demora? Aquí es donde entra en juego el tiempo de propiedad del objetivo de SLA de grupo de Zendesk.

Los SLA de grupo (también llamados Acuerdos de Nivel Operacional u OLA, por sus siglas en inglés) le permiten medir cuánto tiempo permanece un ticket con equipos internos específicos. A diferencia de los SLA regulares que prometen tiempos de respuesta a los clientes, los SLA de grupo rastrean las transferencias internas y la propiedad. Son particularmente útiles para organizaciones con soporte escalonado, flujos de trabajo interfuncionales o SLA internos estrictos con otros departamentos.

Analicemos cómo funciona el tiempo de propiedad del objetivo de SLA de Zendesk, cómo configurarlo y cuándo podría querer aumentarlo con soluciones impulsadas por IA.

¿Qué es el tiempo de propiedad del objetivo de SLA de Zendesk?

Los SLA regulares en Zendesk rastrean el tiempo entre los mensajes del cliente y las respuestas de su equipo. Son compromisos externos, visibles para los clientes y vinculados a sus promesas de servicio. Los SLA de grupo funcionan de manera diferente. Miden cuánto tiempo permanece un ticket asignado a un grupo específico de agentes, rastreando la responsabilidad interna en lugar de las métricas orientadas al cliente.

La métrica de tiempo de propiedad mide específicamente la duración desde que se asigna un ticket a un grupo hasta que se reasigna a otro grupo o se resuelve. Esto es lo que Zendesk llama un "Acuerdo de Nivel Operacional" u OLA. Piense en ello como un contrato interno entre equipos. Cuando el Nivel 1 escala al Nivel 2, ambas partes saben exactamente cuánto tiempo tiene el Nivel 2 para resolver el problema.

Aquí es cuando los SLA de grupo tienen sentido:

• Estructuras de soporte multinivel donde los tickets escalan desde la primera línea a equipos especializados
• Flujos de trabajo interfuncionales que involucran soporte, ingeniería, producto u operaciones
• Escalamientos de proveedores o socios donde necesita rastrear los tiempos de respuesta del equipo externo
• Mesas de ayuda de TI internas que miden los tiempos de resolución para diferentes departamentos

Hay una trampa importante: los SLA de grupo solo están disponibles en el plan Enterprise de Zendesk. Si está en Suite Professional (115 dólares por agente al mes anualmente) o inferior, no tendrá acceso a esta función. Necesitará Suite Enterprise (169 dólares por agente al mes anualmente) o superior.

Cómo funciona el tiempo de propiedad del SLA de grupo

Comprender cuándo comienza y se detiene el tiempo de propiedad es fundamental para usar los SLA de grupo de manera efectiva. El reloj comienza a correr en el momento en que se asigna un ticket a un grupo que coincide con las condiciones de su política de SLA de grupo. Se detiene cuando el ticket se resuelve o se reasigna a un grupo diferente.

Aquí hay un ejemplo concreto. Imagine que un ticket llega a su grupo de soporte de primera línea. Su política dice que el Nivel 1 tiene 4 horas para resolver los tickets. El agente se da cuenta de que es un error y escala a Ingeniería después de 2 horas. El tiempo de propiedad se detiene a las 2 horas (muy dentro del objetivo de 4 horas) y comienza un nuevo reloj para el grupo de Ingeniería, que podría tener un objetivo de 8 horas.

¿Qué sucede cuando se reabren los tickets? Si un ticket fue resuelto por Ingeniería, pero el cliente informa que la solución no funcionó, el tiempo de propiedad se restablece cuando el ticket se reasigna a Ingeniería. Esto evita que los equipos jueguen con el sistema marcando los tickets como resueltos prematuramente.

También debe elegir entre horas hábiles y horas de calendario:

Zendesk permite múltiples horarios de horas hábiles en los planes Enterprise, por lo que diferentes grupos pueden tener diferentes horas de trabajo. Su equipo de soporte de APAC podría operar de 9 AM a 6 PM hora de Singapur, mientras que su grupo de Ingeniería sigue el horario del Pacífico de EE. UU.

Los SLA de grupo y los SLA regulares pueden coexistir en el mismo ticket. Su cliente podría ver un compromiso de tiempo de primera respuesta de 24 horas, mientras que internamente está rastreando que Ingeniería tiene 8 horas para proporcionar una solución. Ambos temporizadores funcionan de forma independiente. Obtenga más información sobre las políticas de SLA estándar en la documentación de Zendesk.

Configuración de políticas de SLA de grupo con tiempo de propiedad

Antes de comenzar a configurar los SLA de grupo, necesitará algunas cosas en su lugar:

1. Plan Suite Enterprise o superior (169 dólares por agente al mes anualmente)
2. Grupos ya creados en su Zendesk (Centro de administración > Personas > Grupos)
3. Campo de prioridad completado en los tickets (generalmente a través de disparadores que establecen la prioridad según el tipo de solicitud o el formulario)

Para obtener instrucciones de configuración detalladas, consulte la documentación de SLA de grupo de Zendesk.

Una vez que tenga estos requisitos previos, aquí le mostramos cómo configurar una política de SLA de grupo con objetivos de tiempo de propiedad:

Paso 1: Navegue a la configuración de SLA Vaya a Centro de administración > Objetos y reglas > Reglas de negocio > Acuerdos de nivel de servicio. Haga clic en la pestaña "SLA de grupo" en la parte superior de la página.

Paso 2: Cree una nueva política Haga clic en "Agregar política" y asígnele un nombre descriptivo. Algo así como "SLA de escalamiento de ingeniería" u "Objetivos de propiedad de nivel 2". Los nombres claros ayudan cuando administra varias políticas más adelante.

Paso 3: Defina las condiciones Esto determina a qué tickets se aplica la política. Puede dirigirse a grupos específicos, conjuntos de grupos o tickets que coincidan con ciertos criterios. Las condiciones comunes incluyen:

• El grupo es "Ingeniería" O "Producto"
• La prioridad es Alta o Urgente
• El estado del ticket es menor que Resuelto

Paso 4: Establezca los objetivos de tiempo de propiedad Aquí es donde define cuánto tiempo tiene cada grupo. Zendesk le permite establecer diferentes objetivos según la prioridad:

Paso 5: Elija horas hábiles o de calendario Seleccione si el temporizador debe funcionar continuamente (horas de calendario) o solo durante las horas de trabajo (horas hábiles). Recuerde que las horas hábiles requieren que tenga horarios hábiles configurados en Zendesk.

Paso 6: Guarde y ordene sus políticas El orden de las políticas importa. Zendesk aplica la primera política coincidente y deja de verificar. Coloque sus políticas más específicas y restrictivas en la parte superior y las políticas generales de captura en la parte inferior.

Comprensión de las métricas de tiempo de propiedad e informes

Una vez que sus SLA de grupo estén en funcionamiento, querrá realizar un seguimiento del rendimiento. Zendesk proporciona varias formas de monitorear las métricas de tiempo de propiedad.

Vistas de tickets con columnas de SLA Agregue columnas de SLA de grupo a sus vistas de tickets para ver el riesgo de incumplimiento de un vistazo. Puede ordenar los tickets por lo cerca que están de incumplir, lo que ayuda a los agentes a priorizar el trabajo que necesita atención inmediata.

Paneles de Zendesk Explore El panel de SLA de grupo en Zendesk Explore proporciona informes agregados. Verá métricas como:

• % Logrado: El porcentaje de tickets que cumplieron con su objetivo de tiempo de propiedad
• Tiempo de resolución promedio: Cuánto tiempo suelen permanecer los tickets con cada grupo
• Tasa de incumplimiento: Con qué frecuencia los grupos no cumplen con sus objetivos

Informes basados en instancias frente a informes basados en tickets Los informes basados en instancias rastrean cada vez que un ticket ingresa a un grupo, incluso si el mismo ticket ingresa al mismo grupo varias veces. Los informes basados en tickets analizan el tiempo total que un ticket pasó con un grupo en todas las instancias. La mayoría de los equipos utilizan informes basados en instancias para las revisiones operativas, ya que capturan cada transferencia por separado.

Al revisar sus métricas, busque patrones:

• ¿Ciertos grupos están incumpliendo constantemente? Es posible que necesiten más recursos o diferentes objetivos.
• ¿Los tickets rebotan entre grupos repetidamente? Sus criterios de escalamiento podrían necesitar aclaración.
• ¿Hay un patrón de hora del día? Es posible que tenga brechas de cobertura durante ciertas horas.

Mejores prácticas para la implementación de SLA de grupo

Después de trabajar con docenas de equipos de soporte en sus configuraciones de SLA, hemos identificado varios patrones que separan las implementaciones exitosas de las frustrantes.

Configure primero los disparadores de prioridad Antes de que los SLA de grupo puedan funcionar, los tickets necesitan prioridades. Cree disparadores que establezcan automáticamente la prioridad en función de la selección del formulario, el tipo de solicitud o las palabras clave. Si los agentes establecen las prioridades manualmente, obtendrá resultados inconsistentes y datos de SLA poco confiables.

Diferencie los canales de conversación frente a los canales de tickets Las conversaciones de chat y mensajería tienen ritmos diferentes a los de los tickets de correo electrónico. Un objetivo de propiedad de 4 horas tiene sentido para un ticket de correo electrónico. Para un chat en vivo que podría tardar 10 minutos en resolverse, ese mismo objetivo no tiene sentido. Considere políticas separadas o diferentes métodos de cálculo para los canales síncronos.

Utilice la regla 2-4-8-16 como punto de partida Muchos equipos encuentran el éxito con objetivos escalonados basados en la gravedad:

• Urgente: 2 horas
• Alta: 4 horas
• Normal: 8 horas
• Baja: 16 horas

Ajuste esto en función de la capacidad real de su equipo y las expectativas del cliente. Es mejor comenzar con indulgencia y apretar que establecer objetivos imposibles que todos ignoren.

Ordene las políticas de la más restrictiva a la menos restrictiva Zendesk aplica la primera política coincidente y se detiene. Si tiene una política específica para "Tickets de ingeniería de alta prioridad" y una política general para "Todos los tickets de ingeniería", coloque la específica primero.

Cree vistas basadas en SLA para los agentes Dé a cada grupo una vista dedicada que muestre solo sus tickets, ordenados por riesgo de incumplimiento. Esto ayuda a los agentes a ver lo que es urgente sin tener que revisar los tickets que no se aplican a ellos.

Maneje los flujos de trabajo de varios equipos con cuidado Cuando los tickets deben moverse a través de varios grupos secuencialmente (Soporte → Ingeniería → QA → Soporte), considere si necesita políticas separadas para cada transferencia o una sola política que cubra todo el flujo.

Cree responsabilidad sin culpa Los SLA son herramientas de entrenamiento, no mecanismos de castigo. Cuando un equipo incumple regularmente, la conversación debe ser sobre restricciones de recursos, mejoras de procesos u objetivos poco realistas, no sobre el desempeño del agente.

Desafíos y soluciones comunes de SLA de grupo

Incluso con una planificación cuidadosa, los equipos se encuentran con desafíos específicos con los SLA de grupo. Estos son los más comunes y cómo abordarlos.

Desafío: Confusión entre asignación y escalamiento Los agentes a veces "escalan" simplemente reasignando el ticket a otro grupo sin ninguno de los contexto o documentación adecuados. El grupo receptor recibe un ticket sin historial y el reloj de SLA comienza a correr en algo que no entienden.

Solución: Cree grupos separados para tickets de primera línea y escalados. Use macros que requieran campos específicos (como el motivo del escalamiento o el impacto en el cliente) antes de permitir la reasignación a grupos especializados. Capacite a los agentes para que la reasignación sin contexto sea una falla del proceso, no una solución.

Desafío: Escalamientos externos ¿Qué sucede cuando escala a un equipo fuera de Zendesk? Tal vez cree un ticket de Jira para Ingeniería o inicie un hilo de Slack con el equipo de Producto. El ticket de Zendesk se queda con su grupo de Soporte mientras espera respuestas externas, pero el SLA de grupo sigue corriendo.

Solución: Cree grupos de marcadores de posición como "Ingeniería pendiente" o "Esperando producto". Cuando escale externamente, reasigne el ticket al grupo de marcadores de posición. Esto pausa el reloj de SLA del grupo original e inicia uno nuevo para la dependencia externa. Algunos equipos incluso crean automatización que reasigna los tickets después de un tiempo establecido para evitar que desaparezcan en las colas externas.

Desafío: Tiempo de propiedad del soporte de primera línea Los equipos de primera línea a menudo tienen dificultades con los objetivos de tiempo de propiedad porque están esperando información de los clientes. Un ticket podría permanecer inactivo durante 24 horas porque el cliente no ha respondido, luego el agente lo recoge y lo resuelve en 10 minutos. El SLA muestra un incumplimiento aunque el agente no haya hecho nada malo.

Solución: Establezca objetivos realistas basados en el tiempo de resolución esperado, no solo en el tiempo de respuesta. Considere usar horas hábiles para que las horas fuera de horario no cuenten en contra de su equipo. Algunos equipos crean un estado de "Cliente pendiente" que pausa los SLA, aunque esto requiere una configuración cuidadosa del disparador.

Desafío: Conflictos de políticas y problemas de ordenación Los tickets que coinciden con varias políticas de SLA de grupo pueden producir resultados confusos. Un ticket que está en "Ingeniería" Y tiene prioridad "Alta" podría coincidir con dos políticas diferentes, y solo se aplica la primera de la lista.

Solución: Audite sus políticas con regularidad. Documente a qué condiciones se dirige cada política. Pruebe los casos extremos (tickets que podrían coincidir con varias políticas) para ver cuál se aplica. Considere usar condiciones "TODAS" en lugar de condiciones "CUALQUIERA" para que las coincidencias sean más específicas.

Ir más allá de los SLA nativos con soluciones impulsadas por IA

Los SLA de grupo son poderosos para rastrear la responsabilidad interna, pero tienen limitaciones. Miden el tiempo. No mejoran los procesos que consumen ese tiempo. Rastrean las transferencias, pero no las reducen. Identifican los cuellos de botella, pero no los resuelven.

Aquí es donde los compañeros de equipo de IA pueden aumentar su estrategia de SLA.

En eesel AI, hemos creado un compañero de equipo de IA para equipos de soporte que se conecta directamente a Zendesk. Si bien no reemplaza los SLA de grupo, aborda muchas de las causas fundamentales que hacen que los objetivos de tiempo de propiedad sean desafiantes en primer lugar.

AI Triage para el enrutamiento automático de tickets Nuestro producto AI Triage lee los tickets entrantes y los enruta al grupo correcto automáticamente. En lugar de que los tickets reboten entre los equipos mientras los agentes averiguan quién debe manejarlos, la IA asigna correctamente la primera vez. Esto reduce el número total de transferencias y garantiza que el tiempo de propiedad comience cuando debería, no después de un día de ping-pong interno.

AI Agent para la resolución autónoma Nuestro AI Agent maneja los tickets de soporte de primera línea de principio a fin. Para los tickets que puede resolver (generalmente del 60 al 80% de las solicitudes comunes), no hay escalamiento, ni transferencia, ni tiempo de propiedad para rastrear. La IA resuelve el problema y cierra el ticket. Sus SLA de grupo se vuelven relevantes solo para los casos extremos complejos que realmente necesitan experiencia humana.

Información de rendimiento en tiempo real Si bien los informes de Zendesk muestran el rendimiento histórico de SLA, nuestra IA proporciona visibilidad en tiempo real de lo que está sucediendo en este momento. Puede ver qué tickets corren el riesgo de incumplir antes de que realmente lo hagan e intervenir de manera proactiva en lugar de revisar los incumplimientos después del hecho.

La combinación funciona bien: los SLA de grupo rastrean las transferencias que ocurren, mientras que la IA reduce el número total de transferencias necesarias. Los equipos que usan ambos generalmente ven que sus métricas de tiempo de propiedad mejoran no porque estén trabajando más rápido, sino porque la IA está manejando el trabajo sencillo que solía obstruir sus colas.

Si está interesado en explorar cómo la IA podría complementar su estrategia de SLA de Zendesk, puede obtener más información sobre nuestra integración de Zendesk aquí o ver nuestros precios para comprender cómo nuestro modelo de tarifa plana se compara con las licencias por agente.

Cómo aprovechar al máximo sus SLA de Zendesk

El tiempo de propiedad del objetivo de SLA de grupo es una herramienta valiosa para la responsabilidad interna, pero es solo una pieza de una operación de soporte bien administrada. Estas son las conclusiones clave:

Comience con objetivos realistas basados en la capacidad real del equipo, no en objetivos ambiciosos. Los SLA inalcanzables se ignoran. Los alcanzables impulsan la mejora.

Supervise sus métricas con regularidad, pero utilícelas como herramientas de entrenamiento en lugar de clubes de rendimiento. La pregunta siempre debe ser "¿Cómo mejoramos esto?" no "¿Quién es responsable del incumplimiento?"

Considere el aumento de la IA para flujos de trabajo complejos. Si está rastreando el tiempo de propiedad en cinco grupos diferentes para un ticket típico, el problema podría ser su proceso, no su gente. Los compañeros de equipo de IA como eesel AI pueden manejar el trabajo de rutina que actualmente requiere múltiples transferencias, permitiendo que sus equipos humanos se concentren en lo que realmente necesita su experiencia.

Recuerde que los SLA son un medio para un fin. El objetivo no es el logro perfecto del SLA. Es resolver los problemas de los clientes de forma rápida y eficaz. A veces, eso significa que un incumplimiento es el resultado correcto, si significa resolver el problema correctamente en lugar de apresurarse a cumplir con una fecha límite arbitraria.

Si está listo para explorar cómo la IA podría ayudar a su equipo a alcanzar sus objetivos de manera más consistente, pruebe eesel AI gratis y vea cómo un compañero de equipo de IA puede transformar sus operaciones de soporte.