Ir al contenido

Tickets

Si necesita instrucciones paso a paso, consulte Crear y gestionar tickets y Configurar tickets. La lista completa de campos y estados está en la Referencia de tickets.

Los tickets son la mesa de ayuda dentro de UNIO24. Un ticket registra una solicitud o un incidente, recorre una cadena de estados y se cierra cuando el asunto queda resuelto.

Los tickets son el punto único de recepción de todo lo relacionado con el funcionamiento del equipo y su mantenimiento: averías, incidentes, solicitudes de reparación o configuración, preguntas de los empleados. Cada solicitud se convierte en un ticket con número, responsable y plazo, por lo que nada se pierde y siempre se ve en qué etapa está la resolución.

Junto con la gestión de activos, los tickets convierten a UNIO24 en un sistema de gestión del mantenimiento de activos (CMMS): la solicitud se vincula a un activo concreto y en su ficha se ve todo el historial de problemas. Cuando un ticket requiere trabajos físicos (reparación, reemplazo, mantenimiento programado), a partir de él se crea una orden de trabajo. Así se separan la solicitud (qué pasó) y el trabajo asociado (qué hacer), y el ticket sigue siendo el canal por el que los problemas llegan al mantenimiento.

Página del ticket: en el encabezado el número del ticket, la insignia de estado y el indicador de SLA con cuenta regresiva, los botones «Editar» y «Asignar a»; en el centro las pestañas «Comentarios», «Historial», «Adjuntos» y «Órdenes de trabajo»; a la derecha un panel lateral con los bloques «Asignar», «Contexto» (prioridad, tipo), «Tiempo» y «Meta»

Un ticket tiene dos partes. El Solicitante es quien originó la solicitud: un empleado del directorio o una persona externa. El Asignado es el usuario del sistema que lleva el ticket. Al ticket se le pueden vincular uno o varios activos a los que se refiere, por lo que el historial de solicitudes también se ve en la ficha del activo.

El ticket no se mueve entre estados de forma arbitraria, sino según un flujo de trabajo configurado. Desde el estado actual solo están permitidas las transiciones a determinados estados, por eso en el menú de cambio de estado ve una lista limitada y no todos los estados a la vez.

De forma predeterminada el sistema tiene siete estados:

  • Nuevo — el ticket acaba de llegar y aún no se ha tomado en trabajo.
  • Abierto — el ticket se aceptó, pero el trabajo aún no ha empezado.
  • En progreso — el responsable se está ocupando del ticket.
  • En espera — el trabajo está en pausa: por ejemplo, se espera la respuesta del solicitante, un repuesto o la decisión de un tercero.
  • Resuelto — el asunto está resuelto y espera confirmación o cierre.
  • Cerrado — el ticket está finalizado. Estado final.
  • Cancelado — el ticket se canceló o se rechazó, no se resolverá. Estado final.

Recorrido típico de un ticket: Nuevo → En progreso → Resuelto → Cerrado, con la pausa «En espera», la reapertura y la cancelación

La lógica del flujo estándar es la siguiente:

  • desde Nuevo o Abierto el ticket pasa En progreso, se pone en pausa (En espera), se marca directamente como Resuelto o se Cancela;
  • En progreso y En espera alternan entre sí mientras avanza el trabajo;
  • un ticket Resuelto se Cierra (final) o se devuelve a En progreso si el asunto vuelve a aparecer;
  • Cerrado y Cancelado son estados finales, no tienen transiciones de salida.

Algunas transiciones requieren una razón y un comentario. Por ejemplo, al poner el ticket en pausa o al rechazarlo, el sistema pide indicar por qué. La razón y el comentario quedan en el historial del ticket, así que después se ve qué cambió y por qué.

El SLA son los plazos de respuesta acordados. En UNIO24 hay dos: el tiempo hasta la primera respuesta y el tiempo hasta la resolución. Los plazos se definen para cada prioridad y se calculan según el horario laboral de la empresa, no por días naturales.

Mientras el ticket está abierto, en él se ve una insignia de SLA. Muestra cuánto tiempo queda, advierte a medida que se acerca el plazo y cambia a «SLA incumplido» si el plazo venció. Así queda claro qué tickets requieren atención primero.

Los plazos de SLA los define el administrador en la página Configurar tickets, en la pestaña SLA, una política por cada prioridad.

  1. Abra Configuración → Configuración de tickets y vaya a la pestaña SLA.
  2. Haga clic en Agregar SLA.
  3. Seleccione la Prioridad para la que define los plazos.
  4. Indique el tiempo hasta la Primera respuesta (min) y hasta la Resolución (min).
  5. Active Solo en horario laboral para que el plazo se cuente según el horario laboral de la empresa y no las 24 horas.
  6. Guarde. Repita para cada prioridad que necesite plazos.

El horario laboral y los días no laborables según los que se calcula el SLA se definen aparte: las horas de la jornada en la sección Configuración → Horario de trabajo, y los días no laborables en la página Días festivos. La configuración completa se describe en la sección Configurar tickets.

Para no tener que distribuir manualmente los nuevos tickets, funciona el enrutamiento: las reglas de enrutamiento asignan el ticket automáticamente en cuanto se crea.

Cada regla consta de dos partes:

  • Condiciones — los criterios por los que se activa la regla: Tipo, Prioridad y Categoría. El ticket debe coincidir con todas las condiciones definidas; una condición vacía significa «cualquiera».
  • Asignación — a quién va el ticket que coincide: a un grupo, a un usuario concreto o a un grupo junto con un usuario.

Las reglas se recorren en orden y se activa la primera regla habilitada que coincida. Si ninguna coincide, el ticket queda sin responsable: se ve en la vista Sin asignar. Las reglas se configuran en la página Configurar tickets.

Pestaña «Enrutamiento» en la configuración de tickets con la ventana «Asignar regla» abierta: campo «Nombre», condiciones «Tipo», «Prioridad» y «Categoría» y el bloque de asignación «Asignar a grupo» / «Asignar a usuario» con la casilla «Regla activada»

Lo más habitual es que el enrutamiento asigne el ticket a un grupo — un grupo de servicio, es decir, un equipo-cola formado por varios usuarios. Los grupos se crean aparte, en la sección Configuración → Grupos, donde a cada uno se le define un nombre y una lista de integrantes.

Un ticket asignado a un grupo entra en la cola común de ese equipo, y el responsable concreto se elige después, entre los integrantes del grupo (en la lista de selección solo aparecen ellos). Se puede indicar también un usuario de inmediato, pero no es obligatorio: el sentido del grupo es que el ticket llegue al equipo correcto aunque el responsable aún no esté definido.

En qué se diferencia un ticket de una orden de trabajo

Sección titulada «En qué se diferencia un ticket de una orden de trabajo»

Un ticket y una orden de trabajo se confunden con facilidad, pero son cosas distintas: el ticket es una solicitud, y la orden de trabajo es el trabajo asociado.

TicketOrden de trabajo
Qué esSolicitud, incidente o pedidoTrabajo de mantenimiento o reparación
Responde a la preguntaQué pasó o qué se necesitaQué y cómo hacer
Quién participaSolicitante y responsableResponsable o grupo de trabajo
Qué hace seguimientoEstados, SLA de primera respuesta y resolución, enrutamientoTareas, materiales, tiempo real, fecha límite

No toda orden de trabajo nace de un ticket: el mantenimiento programado se registra directamente como orden de trabajo. Y al revés, un ticket se puede cerrar sin orden de trabajo si no se necesitan trabajos. Cuando una solicitud requiere trabajos físicos, a partir del ticket se crea una orden de trabajo y se conserva el vínculo entre ambos.

Si un ticket requiere trabajos, a partir de él se crea una orden de trabajo: los datos se transfieren automáticamente y el vínculo se ve desde ambos lados. Esto separa la solicitud (ticket) del trabajo en sí (orden de trabajo), sin perder el vínculo entre ellos.