Condiciones de filtro de la política de SLA de Zendesk: Una guía completa

Stevia Putri
Written by

Stevia Putri

Reviewed by

Stanley Nicholas

Last edited 20 febrero 2026

Expert Verified

Imagen de banner para las condiciones de filtro de la política de SLA de Zendesk: Una guía completa

Equivocarse con las políticas de SLA en Zendesk significa ahogar a su equipo en objetivos inalcanzables o dejar que los tickets críticos se escapen. Ambos escenarios terminan de la misma manera: clientes frustrados y agentes estresados.

Las condiciones de filtro que establezca para cada política de SLA determinan a qué tickets se aplican los acuerdos de nivel de servicio. Si lo hace bien, su equipo tendrá objetivos claros y alcanzables. Si lo hace mal, estará prometiendo demasiado o entregando muy poco.

Esta guía lo guiará a través de todo lo que necesita saber sobre las condiciones de filtro de la política de SLA de Zendesk. Aprenderá los tipos de condiciones disponibles, cómo estructurarlas para diferentes escenarios y las mejores prácticas que mantienen sus SLA funcionando para usted en lugar de en su contra.

¿Qué son las condiciones de filtro de la política de SLA de Zendesk?

Las condiciones de filtro de la política de SLA son las reglas que determinan a qué tickets se aplica un acuerdo de nivel de servicio en particular. Piense en ellas como los guardianes: cuando un ticket coincide con las condiciones, la política de SLA se activa y comienza a rastrear sus objetivos.

Cada condición de filtro en Zendesk sigue la misma estructura: un campo para verificar, un operador para comparar y un valor para coincidir. Así es como se ve:

{ "field": "type", "operator": "is", "value": "incident" }

Los filtros se organizan en dos matrices lógicas:

MatrizLógicaLo que significa
allANDCada condición en esta matriz debe ser verdadera para que el ticket coincida
anyORAl menos una condición en esta matriz debe ser verdadera para que el ticket coincida

El orden de sus políticas de SLA importa. Zendesk las evalúa de arriba a abajo y aplica la primera política cuyas condiciones coincidan. Esto significa que sus políticas más específicas deben estar en la parte superior, con políticas más amplias y generales en la parte inferior.

Las métricas de política definen lo que realmente está midiendo: tiempo de primera respuesta, tiempo de próxima respuesta, tiempo de resolución, etc. Cada métrica puede tener diferentes objetivos según la prioridad del ticket. También puede elegir si contar solo las horas hábiles o las horas del calendario durante todo el día.

Tipos de condiciones de filtro de la política de SLA de Zendesk disponibles

Zendesk proporciona una amplia gama de condiciones para la segmentación de tickets. Estas se dividen en dos categorías: condiciones compartidas entre las reglas de negocio (disparadores, automatizaciones, vistas y SLA) y condiciones específicas de las políticas de SLA. Para obtener detalles técnicos completos, consulte la Referencia de condiciones de Zendesk.

Condiciones compartidas

Estas condiciones funcionan en políticas de SLA, disparadores, automatizaciones y vistas:

CampoOperadoresLo que filtra
group_idis, is_notTickets asignados a grupos de agentes específicos
assignee_idis, is_notTickets asignados a agentes específicos
requester_idis, is_notTickets de solicitantes específicos
organization_idis, is_notTickets de organizaciones específicas
current_tagsincludes, not_includesTickets con o sin etiquetas específicas
via_idis, is_notTickets creados a través de canales específicos
recipient-La dirección de correo electrónico a la que se envió el ticket
custom_fields_{id}is, is_notValores de campo de ticket personalizados

Condiciones específicas de SLA

Estas condiciones solo están disponibles en los filtros de la política de SLA:

CampoOperadoresLo que filtra
ticket_type_idis, is_notPregunta (1), Incidente (2), Problema (3) o Tarea (4)
current_via_idis, is_notCanal utilizado para la actualización más reciente
exact_created_atless_than, greater_than, etc.Marca de tiempo de creación del ticket
custom_status_idis, is_notValores de estado de ticket personalizados

Vale la pena señalar la distinción entre via_id y current_via_id. La condición via_id verifica cómo se creó originalmente el ticket, mientras que current_via_id verifica cómo se realizó la actualización más reciente. Esto importa si desea diferenciar entre los tickets que comenzaron como correo electrónico versus los que se movieron al chat, por ejemplo.

Cómo crear condiciones de filtro de la política de SLA de Zendesk eficaces

La creación de políticas de SLA que realmente funcionen requiere planificación. Aquí hay un enfoque práctico.

Paso 1: Planifique la estructura de su política

Antes de tocar Zendesk, trace su estructura de soporte:

  • ¿Qué segmentos de clientes necesitan diferentes tiempos de respuesta? (VIP, empresa, nivel gratuito)
  • ¿Qué canales tienen diferentes expectativas? (chat versus correo electrónico)
  • ¿Los diferentes tipos de tickets justifican diferentes tratamientos? (incidentes versus preguntas)
  • ¿Qué equipos manejan qué tipo de trabajo?

Este mapeo se convierte en la estructura de su política. Cada combinación única tiene su propia política.

Flujo de trabajo visual para planificar la estructura de la política de SLA basada en segmentos de clientes y canales
Flujo de trabajo visual para planificar la estructura de la política de SLA basada en segmentos de clientes y canales

Paso 2: Navegue al constructor de políticas de SLA

En su Centro de administración de Zendesk, vaya a Objetos y reglas > Reglas de negocio > Acuerdos de nivel de servicio. Haga clic en Crear política para comenzar a construir. Para obtener instrucciones de configuración detalladas, consulte la documentación oficial de la política de SLA de Zendesk.

Paso 3: Configure sus condiciones de filtro

Comience con las condiciones "Todas". Estos son sus criterios obligatorios. Por ejemplo, si esta política se aplica solo a clientes VIP, agregue: Organización es "Clientes VIP".

Luego agregue condiciones "Cualquiera" para criterios opcionales. Es posible que desee que la política se aplique si el ticket está etiquetado como "urgente" O proviene de una organización específica.

Las combinaciones de condiciones comunes incluyen el filtrado basado en la organización para los SLA de nivel de cliente, el filtrado basado en grupos para los SLA internos específicos del equipo, el filtrado basado en canales para diferentes expectativas de respuesta y el filtrado basado en etiquetas para el enrutamiento flexible.

Paso 4: Configure sus métricas de política

Elija qué métricas rastrear para esta política:

MétricaMejor para
Tiempo de primera respuestaReconocimiento inicial del cliente
Tiempo de próxima respuestaCapacidad de respuesta de la conversación en curso
Tiempo de espera del solicitanteTiempo total de espera del cliente
Tiempo total de resoluciónResolución completa del problema
Tiempo de actualización periódicaMantener a los clientes informados durante largas investigaciones

Establezca objetivos para cada nivel de prioridad. Un punto de partida común es:

PrioridadPrimera respuestaPróxima respuesta
Urgente15 minutos30 minutos
Alta1 hora2 horas
Normal4 horas8 horas
Baja24 horas48 horas

Elija las horas hábiles si su equipo no brinda soporte las 24 horas, los 7 días de la semana. Esto asegura que solo esté contando el tiempo cuando los agentes estén realmente disponibles para trabajar.

Ejemplos comunes de condiciones de filtro de la política de SLA de Zendesk

La teoría es útil, pero los ejemplos concretos facilitan la implementación. Aquí hay cuatro escenarios comunes.

Cuatro configuraciones comunes de políticas de SLA para diferentes escenarios de soporte
Cuatro configuraciones comunes de políticas de SLA para diferentes escenarios de soporte

Ejemplo 1: Política de clientes VIP

Para clientes con contratos de soporte premium:

Todas las condiciones:

  • La organización es "Clientes VIP" O las etiquetas incluyen "soporte-premium"

Métricas:

PrioridadPrimera respuestaPróxima respuesta
Urgente15 minutos30 minutos
Alta30 minutos1 hora
Normal1 hora2 horas

Coloque esta política en la parte superior de su lista para que los tickets VIP se detecten antes que sus políticas generales.

Ejemplo 2: Políticas específicas del canal

Diferentes canales tienen diferentes expectativas. Una conversación de chat exige una respuesta más rápida que un correo electrónico.

Política de mensajería (Todas las condiciones):

  • Vía es "Chat" O Vía es "Mensajería"

Política de correo electrónico (Todas las condiciones):

  • Vía es "Correo electrónico"

Establezca sus objetivos de mensajería de manera más agresiva que el correo electrónico. Los clientes esperan una respuesta casi instantánea en el chat, pero son más pacientes con el correo electrónico.

Ejemplo 3: SLA de equipo interno con SLA de grupo

Los SLA de grupo rastrean el rendimiento del equipo interno en lugar de las métricas orientadas al cliente. Están disponibles solo en los planes Enterprise.

Filtro de SLA de grupo:

  • El grupo es "Soporte de nivel 2"

La única métrica disponible para los SLA de grupo es el tiempo de propiedad del grupo, que mide cuánto tiempo permanece un ticket con ese grupo antes de ser resuelto o reasignado.

Ejemplo 4: Ruta de escalamiento para incidentes

Los incidentes críticos necesitan un seguimiento estricto:

Todas las condiciones:

  • La prioridad es "Urgente" Y el tipo es "Incidente"

Agregue objetivos de actualización periódica para garantizar que los clientes reciban actualizaciones de progreso incluso antes de la resolución.

Mejores prácticas y solución de problemas para las condiciones de filtro de la política de SLA de Zendesk

Incluso las políticas de SLA bien planificadas pueden tener problemas. Aquí le mostramos cómo evitar errores comunes.

Orden de las políticas

El error más común es el orden incorrecto de las políticas. Recuerde: Zendesk aplica la primera política coincidente y deja de buscar. Si tiene una política específica para clientes VIP, debe aparecer antes de su política general de "todos los tickets".

Orden recomendado:

  1. Políticas de clientes VIP/empresa
  2. Políticas específicas del canal (chat, teléfono)
  3. Políticas específicas del tipo de ticket (incidentes)
  4. Políticas generales (de captación)

El orden adecuado garantiza que los tickets correctos obtengan los niveles de servicio correctos.

Uso de disparadores con SLA

Un patrón eficaz es usar disparadores para establecer la prioridad del ticket antes de la evaluación del SLA. Esto simplifica sus condiciones de SLA.

Por ejemplo, cree un disparador que establezca la prioridad en "Urgente" si:

  • El asunto contiene "interrupción" O
  • La organización es "Clientes VIP"

Luego, sus políticas de SLA pueden simplemente filtrar por prioridad en lugar de administrar combinaciones de condiciones complejas.

Pruebas antes de la puesta en marcha

Siempre pruebe las nuevas políticas de SLA con tickets de muestra antes de activarlas. Compruebe que:

  • Los tickets correctos coinciden con las políticas correctas
  • Las políticas se aplican en el orden correcto
  • Los objetivos son realistas según los datos históricos

Problemas y soluciones comunes

ProblemaCausa probableSolución
La política no se aplicaOrden incorrecto o error lógicoCompruebe que las políticas más específicas aparezcan primero; verifique la lógica AND/OR
Parece que se aplican varias políticasSolo cuenta la primera coincidenciaRevise el orden; considere si las condiciones son demasiado amplias
El reloj de SLA parece incorrectoConfiguración incorrecta de las horas hábilesVerifique la asignación de horarios y la configuración de las horas hábiles
Conflictos de SLA de grupoConfusión entre los SLA regulares y los de grupoRecuerde que se rastrean por separado; los SLA de grupo solo miden el tiempo de propiedad

Para obtener consejos adicionales para la solución de problemas, consulte estas mejores prácticas de la política de SLA.

Gestión de SLA a escala con IA

A medida que crece su operación de soporte, la gestión manual de las políticas de SLA se vuelve más difícil. Necesita monitorear el rendimiento, detectar tendencias y ajustar los objetivos en función de datos reales.

Aquí es donde las herramientas impulsadas por IA pueden ayudar. En eesel AI, nos especializamos en hacer que las operaciones de soporte sean más eficientes a través de la automatización inteligente.

Nuestra IA puede analizar el contenido de su ticket y sugerir automáticamente ajustes de prioridad antes de la evaluación del SLA. En lugar de depender únicamente de los disparadores manuales, la IA lee el contexto del ticket para identificar señales de urgencia que podrían pasarse por alto.

Para los equipos que tienen problemas con los incumplimientos de SLA, nuestra plataforma proporciona alertas proactivas antes de que se incumplan los objetivos, no después. Esto les da a los agentes tiempo para priorizar los tickets correctos en lugar de reaccionar a los incumplimientos.

Nos integramos directamente con Zendesk, por lo que sus políticas de SLA existentes continúan funcionando mientras la capa de IA agrega inteligencia en la parte superior. Si está interesado en explorar cómo la IA puede optimizar su gestión de SLA, puede obtener más información sobre nuestras capacidades de Agente de IA.

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

Las políticas de SLA bien configuradas transforman la forma en que opera su equipo de soporte. Reemplazan las instrucciones vagas de "responder rápidamente" con objetivos claros y medibles. Le dan a los líderes visibilidad del rendimiento. Y establecen las expectativas del cliente que su equipo puede cumplir de manera constante.

Las condiciones de filtro que establezca son la base. Tómese el tiempo para planificarlas correctamente, probarlas a fondo y revisarlas periódicamente en función de los datos de rendimiento.

Si está buscando llevar su operación de soporte más allá, considere cómo la IA puede aumentar su configuración existente de Zendesk. Creamos eesel AI para ayudar a los equipos a manejar volúmenes de soporte crecientes sin aumentar proporcionalmente el número de empleados. Puede probar eesel gratis o reservar una demostración para ver cómo funciona con su flujo de trabajo específico.

Preguntas frecuentes

Zendesk aplica la primera política coincidente y se detiene. Esta es la razón por la que el orden de las políticas es tan importante. Coloque sus políticas más específicas en la parte superior y sus políticas generales de captación en la parte inferior.
Sí. Puede hacer referencia a campos de ticket personalizados utilizando el formato custom_fields_{field_id}. El ID del campo está visible en la configuración de su campo de ticket. Esto es útil para filtrar por atributos personalizados como el nivel del cliente, la línea de productos o la región.
Los SLA de grupo tienen sus propios filtros separados que solo admiten condiciones group_id. Se evalúan independientemente de las políticas de SLA estándar, por lo que un ticket puede tener un SLA estándar y un SLA de grupo activos simultáneamente.
via_id verifica el canal a través del cual se creó originalmente el ticket. current_via_id verifica el canal utilizado para la actualización más reciente. Use via_id para el enrutamiento basado en cómo comenzó el ticket. Use current_via_id si necesita rastrear cómo ha evolucionado la conversación.
No, Zendesk no admite condiciones de disparador basadas en el estado de incumplimiento del SLA. Puede usar automatizaciones con condiciones de 'Horas hasta el próximo incumplimiento del SLA' o 'Horas desde el último incumplimiento del SLA', pero estas se ejecutan según un cronograma en lugar de activarse inmediatamente cuando ocurre un incumplimiento.
Revise trimestralmente como mínimo. Verifique sus tasas de cumplimiento de SLA en Zendesk Explore. Si su equipo constantemente no alcanza los objetivos, ajuste los objetivos o investigue si sus condiciones de filtro están capturando los tickets correctos. Si está alcanzando el 100% de cumplimiento, sus objetivos podrían ser demasiado conservadores.

Compartir esta entrada

Stevia undefined

Article by

Stevia Putri

Stevia Putri is a marketing generalist at eesel AI, where she helps turn powerful AI tools into stories that resonate. She’s driven by curiosity, clarity, and the human side of technology.