¡Esta es una revisión vieja del documento!


2. Gestión de tickets (Ticketing)

Integria IMS implementa un sistema de gestión de tickets o ticketing. Se puede utilizar en proyectos de desarrollo de software, como herramienta de helpdesk o adaptado a sus necesidades para atender cualquier necesidad de interacción con clientes o usuarios. Una serie de elementos comunes unen a todas esas actividades, para Integria IMS esos elementos comunes son las referencias a otros tickets, las referencias a uno o varios objetos del inventario y la vinculación única de un usuario con un ticket.

Un ejemplo del flujo de ticketing con Integria IMS

Nuestro equipo de soporte, está formado por tres personas (Tomás, Javi, Luis) y un “jefe” de equipo (Ramón). Tenemos varios tipos de clientes. Los que trabajan en equipo y los que van “por libre”. Los que operan también en “equipo”, es decir, un cliente que tiene a varias personas trabajando simultáneamente, y que pueden 'ver' los tickets de sus compañeros, o bien para aportar algo, o bien para hacerse cargo de ellos. Los que van por libre, solo ven lo suyo, y son la única persona que puede verlo. El primer tipo de cliente, tendrá un grupo propio, y usuarios asignados a ese grupo. Mientras que el segundo tipo de cliente, pertenecerá a un grupo “general” y tendrá el bit de “modo externo” activado, de forma que aunque pertenece a un grupo solo podrá ver “lo suyo”. Cuando un cliente de los que trabajan en grupo, abre un ticket. Automáticamente, ya que ese grupo está definido así, se asigna a una cuenta genérica de integria llamada “Support”. Generando un email que va a “[email protected]”.

Esa cuenta de email, automáticamente envía una copia a cada uno de los miembros del equipo de soporte. Esa semana, está de “guardia” Javi, quien ve el correo y pincha en el enlace para ir a Integria. Vería algo como lo siguiente:

En integria IMS ve un ticket nuevo, en color rojo. Se puede ver el usuario creador así como otros datos. Ante un ticket nuevo, como el que está en rojo, podemos añadir la primera respuesta. Cuando a un ticket nuevo se le añade una Unidad de Trabajo (o nota), ésta automáticamente se le asigna al usuario que escribe la unidad de trabajo, se le cambio a estado “Asignado”. Haciendo clic en el ticket que está en rojo entramos en la pantalla principal de gestión del ticket. Podemos cambiar su estado, o navegar por las solapas del ticket para ver su histórico, notas asociadas a el ticket (workunits), ficheros, etc. Nos interesa dar la primera respuesta al problema, ya que desde que se abre, se calcula cuanto tiempo pasa sin respuesta. Si pasa el margen de tiempo establecido por la SLA asociada al grupo de esa ticket, saltará una alarma. Cuando se añade una Unidad de trabajo (una nota) o un fichero o se cambia su estado, se le envía una notificación por email a todos los usuarios “suscritos” a ese ticket. En este caso, Javi va a poner una nota que dice “Veo lo que me cuentas y voy a intentar reproducirlo para determinar el origen del problema”.

Al crear la WU, mi ticket ha cambiado de estado. Al autor del ticket le llegará la nota que Javi ha metido en el sistema.

Pasan los días y el problema no se soluciona. Julio, el cliente que creó el ticket, vuelve a preguntar por el tema. Pero ese dia Javi no está en la oficina. Un compañero suyo, Luis, al cargo de los tickets, ve que el ticket está actualizada por el cliente, y le contesta, añadiendo una Unidad de Trabajo él mismo. A partir de ese momento, queda suscrito a el ticket, recibiendo todas las notificaciones sobre cambios en el ticket. Podemos ver en el menú de la izquierda, los usuarios que participan en el ticket: el creador, el usuario “dueño” del ticket (javi), y los que han participado en ella.

Un usuario sin permisos de “Gestión” en el sistema de tickets, pero con permisos de escritura, puede añadir unidades de trabajo, pero no puede “cambiar” al dueño del ticket, ni cerrarlo, si no es suyo. Si es un “gestor” de tickets, puede cambiar el dueño del ticket. Si el usuario es dueño del ticket, puede “reasignarsela” a otra persona. Este proceso se conoce como escalar un ticket. Finalmente, Javi pudo cerrar el ticket, puso en el campo “Epilogo” el resumen de la solución al problema, y cambia el ticket a estado “Resolved”. De esta forma, los tickets “resueltos” o “cerrados” ya no se ven en la vista por defecto de tickets, aunque por supuesto, se pueden buscar si se desean.

Usuarios y permisos en un ticket

Es muy importante primero conocer que permisos disponemos para los tickets. Existen varios roles diferentes en un ticket:

  • Creador del ticket

Es el autor original del ticket. Es quien establece el responsable de ese ticket (a no ser que esto se haga automáticamente), el grupo al que pertenece el ticket (idem) y otros parámetros como su criticidad, nivel de resolución, descripción, elementos de inventario a los que está vinculado, etc. El autor original una vez que crea un ticket, ya no puede “gobernarlo”, es decir, no podrá cerrarlo hasta que usuario responsable del ticket no lo decida. Tampoco podrá reabrirlo. Como cualquier usuario con acceso a el ticket, el usuario creador puede añadir ficheros y unidades de trabajo (UT o WU en inglés).

  • Responsable del ticket

Es el usuario asignado al ticket, también llamado “dueño” del ticket (owner). En la definición de grupos se asigna un usuario predeterminado, que será el usuario asignado por defecto, en función del grupo seleccionado por el usuario creador del ticket.


Documentación de Integria