Ciclo de vida del estado de los tickets de Zendesk: Una guía completa para 2026

Stevia Putri
Written by

Stevia Putri

Reviewed by

Stanley Nicholas

Last edited 25 febrero 2026

Expert Verified

Imagen del banner para el ciclo de vida del estado de los tickets de Zendesk: Una guía completa para 2026

Cada ticket de soporte técnico pasa por un recorrido. Desde el momento en que un cliente presiona "enviar" hasta que el problema se resuelve por completo, cada ticket pasa por distintas etapas. Comprender el ciclo de vida del estado de los tickets de Zendesk no se trata solo de saber qué hacen los botones. Se trata de mantener a su equipo organizado, a sus clientes informados y su operación de soporte funcionando sin problemas.

Si alguna vez se ha preguntado por qué algunos tickets parecen desaparecer de las vistas, o por qué los clientes pueden volver a abrir tickets "cerrados" mientras que no pueden tocar los "resueltos", esta guía aclarará las cosas. Repasaremos cada estado, explicaremos cuándo usarlos y le mostraremos cómo optimizar su flujo de trabajo. También veremos cómo herramientas como eesel AI pueden ayudar a automatizar y mejorar este proceso.

Página de inicio de Zendesk que muestra la interfaz de servicio al cliente de la plataforma
Página de inicio de Zendesk que muestra la interfaz de servicio al cliente de la plataforma

¿Qué es el ciclo de vida del estado de los tickets de Zendesk?

El ciclo de vida del ticket es la ruta que sigue cada solicitud de soporte desde la creación hasta el cierre. Piense en ello como el latido del corazón de su operación de soporte. Cada estado representa un estado específico de progreso, y mover los tickets a través de estos estados correctamente mantiene a todos en la misma página. Para obtener documentación oficial, consulte la guía de Zendesk sobre los estados de los tickets.

¿Por qué es esto importante? Para empezar, los estados de los tickets impulsan sus informes. Determinan qué tickets aparecen en qué vistas. Controlan los temporizadores del SLA (Service Level Agreement). Y quizás lo más importante, comunican el progreso a los clientes sin requerir una actualización manual cada vez que algo cambia.

Cuando administra bien los estados, los agentes saben exactamente qué necesita su atención. Los clientes comprenden dónde se encuentra su solicitud. Y los gerentes obtienen datos precisos sobre el rendimiento del equipo y los cuellos de botella.

Los seis estados estándar de los tickets de Zendesk explicados

Zendesk viene con seis estados estándar listos para usar. Cada uno tiene un propósito específico, un indicador visual y un conjunto de reglas que rigen su comportamiento. Puede leer más sobre cómo funcionan los tickets en Zendesk.

Los seis estados estándar de los tickets de Zendesk desde Nuevo hasta Cerrado
Los seis estados estándar de los tickets de Zendesk desde Nuevo hasta Cerrado

Nuevo

El estado "Nuevo" es donde comienza cada ticket. Cuando un cliente envía una solicitud a través de cualquier canal (correo electrónico, formulario web, chat o API), Zendesk asigna automáticamente el estado "Nuevo".

El indicador visual es naranja. Esto hace que los nuevos tickets se destaquen en las vistas, lo que indica que necesitan una evaluación inicial o asignación.

Aquí está la regla crítica sobre Nuevo: una vez que el estado de un ticket cambia de Nuevo, nunca puede volver atrás. Incluso si desasigna el ticket más tarde, no volverá a Nuevo. Esto es por diseño. Nuevo está destinado a capturar ese estado inicial "no visto".

Abierto

Cuando un agente comienza a trabajar en un ticket, debe marcarse como "Abierto". El indicador visual rojo indica que este ticket se está manejando activamente.

Use Abierto cuando:

  • Un agente está asignado y trabajando activamente en el ticket
  • Está esperando una investigación interna
  • La próxima acción está en su equipo, no en el cliente

¿El error más común? Dejar los tickets en estado Abierto cuando en realidad está esperando que el cliente responda. Esto desordena las vistas de los agentes y hace que sea más difícil ver lo que realmente necesita atención.

Pendiente

"Pendiente" significa que está esperando al cliente. El indicador azul es su señal visual de que la pelota está en la cancha del solicitante.

Cuando establece un ticket en Pendiente:

  • Pausa los temporizadores del SLA (dependiendo de su configuración)
  • Por lo general, elimina el ticket de las vistas de "necesita atención"
  • Señala al cliente que ha respondido y está esperando su respuesta

Aquí hay algo importante: cuando un cliente responde a un ticket Pendiente, se restablece automáticamente a Abierto. Esta es una regla del sistema que no se puede desactivar. Está diseñado para llamar su atención sobre el ticket en el momento en que el cliente interactúa.

En espera

El estado "En espera" (On-hold) es opcional. Su administrador debe habilitarlo primero. Una vez activado, sirve para un propósito específico: rastrear los tickets en los que está esperando a alguien que no sea el cliente.

Tal vez esté esperando:

  • Que un proveedor envíe una pieza de repuesto
  • Que el equipo de ingeniería corrija un error
  • Que un servicio de terceros resuelva un problema

El indicador gris oscuro los distingue de los tickets Pendientes. Y aquí está la clave: los clientes nunca ven "En espera". Para ellos, se muestra como "Abierto". Esto los mantiene informados de que se está trabajando en el problema sin revelar dependencias internas.

Resuelto

Cuando cree que ha resuelto el problema del cliente, marque el ticket como "Resuelto". El indicador gris claro muestra que este ticket está esencialmente completo, a la espera de la confirmación del cliente.

Resuelto es diferente de Cerrado en una forma crucial: los clientes pueden volver a abrir los tickets Resueltos simplemente respondiendo. Este es el período de "enfriamiento" donde el cliente puede decir "en realidad, eso no lo solucionó" y el ticket vuelve a Abierto.

La mejor práctica es mantener los tickets en Resuelto durante 3 a 5 días antes de que pasen a Cerrado. Esto les da a los clientes un plazo razonable para responder si algo aún está mal.

Cerrado

"Cerrado" es el destino final. Una vez que un ticket está Cerrado, está bloqueado. Los clientes no pueden volver a abrirlo. Los agentes no pueden modificarlo (con raras excepciones). El ticket se vuelve de solo lectura.

Esto es lo que sorprende a muchas personas: no puede establecer manualmente un ticket en Cerrado. Siempre se hace por automatización. Zendesk incluye una automatización predeterminada que cierra los tickets 4 días después de que se establecen en Resuelto. Puede ajustar este tiempo (desde 1 hora hasta 28 días), pero no puede deshabilitar el cierre automático por completo. Después de 28 días, el sistema cerrará los tickets resueltos independientemente de su configuración.

Cuando un cliente responde a un ticket Cerrado, Zendesk crea un nuevo ticket de "seguimiento" que hace referencia al original. Esto preserva el historial al tiempo que inicia una nueva conversación.

Cómo se mueven los tickets a través del ciclo de vida

Ahora que entendemos cada estado, veamos cómo se conectan. Aquí hay un flujo típico:

Flujo del ciclo de vida de los tickets de Zendesk desde el estado Nuevo hasta el estado Cerrado
Flujo del ciclo de vida de los tickets de Zendesk desde el estado Nuevo hasta el estado Cerrado

  1. Nuevo - El cliente envía el ticket
  2. Abierto - Agente asignado, comienza la investigación
  3. Pendiente - El agente pide al cliente más información
  4. Abierto - El cliente responde con detalles
  5. Resuelto - El agente proporciona la solución
  6. Cerrado - La automatización cierra el ticket después del período de espera

Pero los tickets no siempre siguen una línea recta. Podrían rebotar entre Abierto y Pendiente varias veces. Un ticket podría pasar de Abierto a En espera mientras consulta con ingeniería, luego volver a Abierto, luego a Pendiente mientras explica la solución al cliente.

El sistema tiene reglas integradas que rigen estas transiciones:

  • Las respuestas del cliente a Pendiente, Resuelto o En espera establecen automáticamente el ticket en Abierto
  • Los tickets no se pueden cerrar manualmente (solo automatización)
  • Una vez que se cambia Nuevo, nunca puede regresar
  • Los tickets no se pueden establecer en Resuelto sin un cesionario (el sistema asigna automáticamente al agente que resuelve)

Mejores prácticas para gestionar los estados de los tickets

Gestionar correctamente los estados puede transformar su operación de soporte. Estas son las prácticas que marcan la mayor diferencia.

Domine la distinción entre Abierto y Pendiente

Este es el hábito más importante que deben desarrollar los agentes. Cuando un ticket está Abierto, aparece en las vistas centradas en el trabajo que necesita la atención del agente. Cuando está Pendiente, desaparece de esas vistas.

Si los agentes dejan los tickets Abiertos cuando en realidad están esperando a los clientes, esos tickets desordenan las colas de trabajo activas. Otros agentes podrían dedicar tiempo a revisar tickets que no necesitan acción. Y los verdaderos tickets de "necesita atención" quedan enterrados.

Capacite a su equipo para que pregunte: "¿Estoy esperando al cliente?" Si es así, establézcalo en Pendiente. Si no, manténgalo Abierto.

Use En espera para dependencias internas

Si su administrador ha habilitado En espera, utilícelo. Le brinda una mejor visibilidad de los tickets bloqueados por factores fuera del equipo de soporte. Puede crear vistas específicamente para tickets En espera y configurar automatizaciones para recordar a los equipos internos cuando los tickets los están esperando.

Sin En espera, los agentes a menudo usan incorrectamente Pendiente para esperas internas. Esto es confuso para los clientes (piensan que está esperando por ellos cuando no lo está) y arruina sus métricas (los temporizadores del SLA se comportan de manera diferente para Pendiente vs En espera).

Configure la automatización de bump-solve

Una de las automatizaciones más útiles en Zendesk es el flujo de trabajo "bump-solve". Funciona así:

  1. El ticket ha estado Pendiente durante 48 horas
  2. La automatización envía un recordatorio amistoso al cliente
  3. Todavía no hay respuesta después de otras 48 horas
  4. La automatización resuelve el ticket con un mensaje cortés

Esto mantiene su backlog limpio sin requerir que los agentes persigan manualmente a los clientes que no responden. Los clientes que aún necesitan ayuda pueden simplemente responder para volver a abrir el ticket.

Evite el cierre prematuro

No apresure los tickets a Cerrado. Sí, un backlog limpio se siente bien, pero cerrar demasiado rápido frustra a los clientes que necesitan hacer un seguimiento. Tendrán que crear un nuevo ticket, volver a explicar su problema y empezar de nuevo. Esto perjudica la satisfacción del cliente y crea más trabajo para los agentes.

Apéguese a la ventana de 3 a 5 días en estado Resuelto. Logra el equilibrio adecuado entre mantener su cola manejable y dar a los clientes tiempo para verificar que su problema esté realmente resuelto.

Automatización de las transiciones de estado en Zendesk

Zendesk proporciona dos herramientas para automatizar los cambios de estado: disparadores (triggers) y automatizaciones. Comprender cuándo usar cada uno le ayuda a construir flujos de trabajo eficientes.

Los disparadores se activan instantáneamente cuando se crea o actualiza un ticket. Son perfectos para acciones inmediatas como:

  • Establecer un ticket en Abierto cuando se asigna a un agente
  • Cambiar el estado en función de palabras clave o etiquetas específicas
  • Enrutar los tickets a grupos específicos en función del contenido

Las automatizaciones se ejecutan según un horario (generalmente por hora) y verifican las condiciones basadas en el tiempo. Son ideales para:

  • Cerrar los tickets después de que hayan estado Resueltos durante X días
  • Escalar los tickets que han estado Abiertos durante demasiado tiempo
  • Enviar recordatorios para los tickets Pendientes

Para una inmersión más profunda en este tema, consulte nuestra guía sobre automatizaciones vs disparadores de Zendesk para eventos del ciclo de vida.

Mejora de la gestión del estado con IA

Si bien las herramientas nativas de Zendesk son poderosas, se basan en reglas que configura manualmente. Cada nuevo escenario requiere un nuevo disparador o automatización. Aquí es donde la IA puede ayudar.

Panel de simulación de eesel AI que muestra las tasas de automatización predichas para Zendesk
Panel de simulación de eesel AI que muestra las tasas de automatización predichas para Zendesk

eesel AI se integra directamente con Zendesk y aprende de sus datos históricos de tickets. En lugar de escribir reglas para cada escenario posible, eesel AI comprende el contexto y la intención. Puede:

  • Sugerir o establecer automáticamente el estado correcto en función del contenido del ticket
  • Enrutar los tickets al equipo correcto sin evaluación manual
  • Identificar cuándo un ticket debe estar Pendiente vs En espera en función de la conversación
  • Reconocer el sentimiento y la urgencia que las reglas podrían pasar por alto

Esto reduce la carga cognitiva de los agentes, que ya no necesitan administrar manualmente el estado de cada ticket. También detecta casos extremos que las reglas rígidas podrían pasar por alto.

Errores comunes y cómo evitarlos

Incluso los equipos de soporte experimentados cometen estos errores de gestión de estado. Esto es lo que debe tener en cuenta.

Dejar los tickets en el estado incorrecto. El problema más común es que los tickets se encuentran en Abierto cuando deberían estar Pendientes (o viceversa). Esto generalmente se debe a que los agentes no tienen clara la distinción. La capacitación regular y las auditorías de vista ayudan a detectar esto.

Cerrar los tickets demasiado rápido. Cuando los equipos se miden en el tiempo de resolución, existe la presión de cerrar los tickets rápidamente. Resista esto. Es mejor tener una métrica de "tiempo para cerrar" ligeramente más larga que clientes frustrados que crean tickets de seguimiento.

No usar En espera para dependencias de terceros. Sin En espera, los agentes usan incorrectamente Pendiente (confundiendo a los clientes) o dejan los tickets Abiertos (inflando las colas de trabajo activas). Si su plan lo admite, habilite En espera y capacite a los agentes para que lo usen.

Uso inconsistente del estado en todo el equipo. El "Abierto" de un agente podría ser el "Pendiente" de otro. Documente los estándares de su equipo y revise las muestras de tickets con regularidad para garantizar la coherencia.

Optimice el ciclo de vida del estado de los tickets de Zendesk con eesel AI

La gestión manual de los estados de los tickets funciona bien a pequeña escala. Pero a medida que su equipo crece y aumenta el volumen de tickets, la sobrecarga se acumula. Los agentes gastan energía mental decidiendo qué estado usar. Los administradores escriben reglas cada vez más complejas para manejar los casos extremos. Y los tickets aún se escapan por las grietas.

Aquí es donde podemos ayudar. eesel AI se integra con Zendesk para brindar automatización inteligente al ciclo de vida de sus tickets. Nuestro Agente de IA aprende de sus tickets anteriores para comprender cómo funciona su equipo. Puede sugerir estados óptimos, enrutar los tickets de manera inteligente e incluso manejar las transiciones de estado de rutina automáticamente.

Para los equipos que desean mantener a los agentes en control, nuestro producto AI Triage proporciona recomendaciones al tiempo que deja la decisión final a los humanos. Y nuestro AI Copilot ayuda a los agentes a redactar respuestas que conducen naturalmente al siguiente estado correcto.

El resultado es un backlog más limpio, un uso más consistente del estado y agentes que pueden concentrarse en resolver problemas en lugar de administrar los estados de los tickets.

Preguntas Frecuentes

La mejor práctica es de 3 a 5 días. Esto les da a los clientes tiempo suficiente para verificar que la solución funciona y responder si no es así. La automatización predeterminada de Zendesk cierra los tickets después de 4 días, lo que se alinea bien con esta recomendación.
No. El estado Cerrado solo puede ser establecido por automatizaciones o reglas del sistema. Esto es por diseño para evitar cierres accidentales y garantizar datos consistentes. Puede ajustar el tiempo de la automatización de cierre (desde 1 hora hasta 28 días), pero no puede cerrar los tickets manualmente.
La respuesta crea un nuevo ticket de 'seguimiento' que hace referencia al ticket cerrado original. El ticket original permanece cerrado y sin cambios. El ticket de seguimiento comienza de nuevo en estado Nuevo, aunque incluye un enlace a la conversación anterior para contextualizar.
Esto suele suceder porque un disparador (trigger) está anulando el cambio de estado. Consulte el registro de eventos del ticket para ver qué disparadores se activaron en la respuesta del cliente. Otra posibilidad es que la respuesta provenga de alguien que también es un agente en su sistema. Cuando los agentes responden a los tickets en los que son el solicitante, el estado no cambia automáticamente.
Pendiente significa que está esperando al cliente. En espera significa que está esperando a otra persona (equipo interno, proveedor, tercero). Los clientes ven Pendiente como 'esperando por usted' y En espera como 'Abierto'. En espera también mantiene los temporizadores del SLA en funcionamiento en la mayoría de las configuraciones, mientras que Pendiente normalmente los pausa.
Sí, en ciertos planes. Los estados personalizados existen dentro de las categorías de estado estándar (Nuevo, Abierto, Pendiente, En espera, Resuelto, Cerrado). Por ejemplo, podría crear 'Esperando QA' como un estado personalizado dentro de la categoría En espera. Los estados personalizados conservan sus nombres incluso después de que se cierran los tickets, lo que le brinda mejores informes sobre cómo se resolvieron los tickets.

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.