Políticas de SLA en atención al cliente, explicadas

Un acuerdo de nivel de servicio (SLA) es un compromiso sobre la rapidez con la que vas a responder y resolver las solicitudes. Una política de SLA es la forma en que tu helpdesk hace cumplir ese compromiso en cada ticket. La mayoría de las políticas tienen las mismas partes:

• Condiciones: a qué tickets se aplica la política, por ejemplo según el cliente, el canal o el tipo de solicitud
• Objetivos: límites de tiempo para la primera respuesta, las respuestas posteriores y la resolución, normalmente fijados por prioridad
• Horario: si el reloj cuenta horas laborables u horas naturales
• Reglas de pausa: qué estados detienen el reloj
• Acciones ante incumplimientos: recordatorios antes de que se incumpla un objetivo y escalados después

El orden importa cuando tienes varias políticas. Zendesk ejecuta primero los triggers, luego compara el ticket con sus políticas de SLA de arriba abajo y aplica la primera cuyas condiciones se cumplen. Coloca las políticas específicas, como una para clientes enterprise, por encima de las generales. Zendesk también exige que la prioridad del ticket esté en el campo de prioridad predeterminado del sistema; un campo de prioridad personalizado no hará coincidir ninguna política.

Zendesk define 'next reply time' como el tiempo entre el comentario del cliente sin contestar más antiguo y el siguiente comentario público de un agente. También ofrece una métrica de actualización periódica, que mide el tiempo entre comentarios públicos de agentes. Para la resolución, Zendesk tiene tres métricas y recomienda elegir solo una por política: 'requester wait time' (tiempo en 'New', 'Open' y 'On-hold'), 'agent work time' (tiempo en 'New' y 'Open') y 'total resolution time' (todo el ciclo de vida, desde la creación hasta que el ticket se resuelve).

Freshdesk fija objetivos de primera respuesta, de cada respuesta y de resolución por prioridad dentro de cada política de SLA. En Jira Service Management, cada SLA es un temporizador con nombre: defines cuándo empieza, se pausa y se detiene, y luego añades objetivos que usan JQL para elegir a qué solicitudes se aplican, con tiempos objetivo escritos como 4h 30m.

Las horas laborables solo cuentan el tiempo dentro de tu horario de trabajo; las horas naturales cuentan todas las horas de todos los días. Zendesk te permite elegir horas laborables o naturales para cada prioridad dentro de una política. Freshdesk pregunta si cada SLA debe usar el horario laboral que has configurado u horas naturales (24x7). Jira Service Management asocia a cada objetivo un calendario con zona horaria, días y horas laborables y festivos.

Un objetivo de 4 horas laborables en un ticket creado el viernes a última hora puede no vencer hasta el lunes. Es justo para tu equipo, pero no es lo que vive el cliente, así que usa horas naturales en cualquier prioridad en la que prometas cobertura las 24 horas.

La pausa es la otra mitad. El tiempo que se pasa esperando al cliente normalmente no debería contar en tu contra, y cada herramienta lo gestiona de forma distinta:

• Zendesk: 'requester wait time' se pausa en 'Pending'; 'agent work time' se pausa en 'Pending' y 'On-hold'; 'total resolution time' no se pausa con ningún cambio de estado hasta que se resuelve el ticket.
• Freshdesk: el estado 'Pending' pausa los temporizadores de SLA, y puedes desactivar el temporizador de SLA para cualquier estado, incluidos los personalizados como 'Waiting on Third Party'. Los tickets con el temporizador desactivado aparecen como 'On Hold', y cuando el cliente responde, el ticket vuelve a 'Open' y el reloj se reanuda.
• Jira Service Management: un SLA puede tener condiciones de pausa, por ejemplo mientras esperas la respuesta del cliente, junto con sus condiciones de inicio y parada.

Un SLA solo sirve si alguien actúa antes de que se incumpla. Configura un aviso antes del plazo y un escalado después:

• Zendesk: crea una automatización con la condición 'Hours until next SLA breach' para avisar a un equipo o a una persona cuando un ticket esté a punto de incumplirse. Las automatizaciones se ejecutan una vez por hora, así que el aviso puede llegar hasta una hora antes o después del umbral, nunca en el momento exacto. El ejemplo de Zendesk añade una etiqueta en la misma automatización para que solo se active una vez por ticket.
• Freshdesk: cada política de SLA puede recordar a los agentes, desde 5 minutos hasta 4 horas antes, que vence un objetivo de primera respuesta o de resolución, y escalar cuando se incumple un objetivo al agente asignado o a otras personas que elijas, como un jefe de equipo. Ambas cosas se configuran en Admin > Workflows > SLA Policies.
• Cualquier herramienta: envía los avisos de incumplimiento donde tu equipo mira de verdad, como un canal de Slack, y no solo al correo.

• Zendesk: crea políticas de SLA con condiciones y objetivos por prioridad, elige horas laborables o naturales para cada prioridad y ordena la lista para que las políticas específicas vayan primero. Añade una automatización para los avisos de incumplimiento inminente.
• Freshdesk: en Admin > Workflows > SLA Policies, fija objetivos de primera respuesta, de cada respuesta y de resolución por prioridad, elige horas laborables o naturales y luego añade recordatorios y escalados. Decide en la configuración de estados de ticket qué estados desactivan el temporizador de SLA.
• Jira Service Management: crea cada SLA con condiciones de inicio, pausa y parada. Varias condiciones de inicio funcionan como OR, y el SLA se detiene en cuanto se cumple cualquier condición de parada. Después añade objetivos que seleccionen solicitudes con JQL, fija un tiempo objetivo y elige un calendario.

Sea cual sea la herramienta, empieza con una política y unas pocas prioridades, déjala funcionar unas semanas y luego compara los tiempos reales de primera respuesta y de resolución con los objetivos antes de ajustarlos.

TascaLab configura automatizaciones relacionadas con los SLA sobre Zendesk, Freshdesk y Jira: enrutamiento que fija la prioridad para que se aplique la política correcta, avisos de incumplimiento en Slack e informes de SLA programados. Los precios de proyecto puntual relevantes son Ticket Routing & Categorization (690 €), Automated Reports (620 €) y Custom Automation (desde 1070 €). Los proyectos incluyen documentación básica, 30 días de soporte tras el lanzamiento y ningún coste oculto, y la mayoría llevan 1–3 semanas. Empieza con una llamada de Health Check gratuita de 30 minutos.