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

Stevia Putri

Stanley Nicholas
Last edited 20 febrero 2026
Expert Verified
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:
| Matriz | Lógica | Lo que significa |
|---|---|---|
| all | AND | Cada condición en esta matriz debe ser verdadera para que el ticket coincida |
| any | OR | Al 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:
| Campo | Operadores | Lo que filtra |
|---|---|---|
| group_id | is, is_not | Tickets asignados a grupos de agentes específicos |
| assignee_id | is, is_not | Tickets asignados a agentes específicos |
| requester_id | is, is_not | Tickets de solicitantes específicos |
| organization_id | is, is_not | Tickets de organizaciones específicas |
| current_tags | includes, not_includes | Tickets con o sin etiquetas específicas |
| via_id | is, is_not | Tickets 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_not | Valores 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:
| Campo | Operadores | Lo que filtra |
|---|---|---|
| ticket_type_id | is, is_not | Pregunta (1), Incidente (2), Problema (3) o Tarea (4) |
| current_via_id | is, is_not | Canal utilizado para la actualización más reciente |
| exact_created_at | less_than, greater_than, etc. | Marca de tiempo de creación del ticket |
| custom_status_id | is, is_not | Valores 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.
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étrica | Mejor para |
|---|---|
| Tiempo de primera respuesta | Reconocimiento inicial del cliente |
| Tiempo de próxima respuesta | Capacidad de respuesta de la conversación en curso |
| Tiempo de espera del solicitante | Tiempo total de espera del cliente |
| Tiempo total de resolución | Resolución completa del problema |
| Tiempo de actualización periódica | Mantener a los clientes informados durante largas investigaciones |
Establezca objetivos para cada nivel de prioridad. Un punto de partida común es:
| Prioridad | Primera respuesta | Próxima respuesta |
|---|---|---|
| Urgente | 15 minutos | 30 minutos |
| Alta | 1 hora | 2 horas |
| Normal | 4 horas | 8 horas |
| Baja | 24 horas | 48 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.
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:
| Prioridad | Primera respuesta | Próxima respuesta |
|---|---|---|
| Urgente | 15 minutos | 30 minutos |
| Alta | 30 minutos | 1 hora |
| Normal | 1 hora | 2 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:
- Políticas de clientes VIP/empresa
- Políticas específicas del canal (chat, teléfono)
- Políticas específicas del tipo de ticket (incidentes)
- 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
| Problema | Causa probable | Solución |
|---|---|---|
| La política no se aplica | Orden incorrecto o error lógico | Compruebe que las políticas más específicas aparezcan primero; verifique la lógica AND/OR |
| Parece que se aplican varias políticas | Solo cuenta la primera coincidencia | Revise el orden; considere si las condiciones son demasiado amplias |
| El reloj de SLA parece incorrecto | Configuración incorrecta de las horas hábiles | Verifique la asignación de horarios y la configuración de las horas hábiles |
| Conflictos de SLA de grupo | Confusión entre los SLA regulares y los de grupo | Recuerde 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
Compartir esta entrada

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.


