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).

  • Propietario 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. El creador del ticket puede cambiar este usuario y seleccionar otro perteneciente al grupo al que asigna el ticket. El usuario responsable del ticket es el único que puede actualizar sus detalles y cambiar su estado. Cuando un “gestor” cambia el responsable del ticket decimos que hay un “escalado manual” del ticket.

  • Usuario con acceso de escritura al ticket

El ticket siempre pertenece a un grupo. Todos los usuarios con el flag de acceso “IW” pueden escribir UT (Unidades de Trabajo o Workunit en ingles) sobre un ticket. Estas UT son como “notas” que se van quedando adjuntas a el ticket. Este tipo de usuario no puede modificar ningún otro detalle del ticket, tal como estado o criticidad, ni alterar la descripción principal del ticket.

  • Usuario con acceso de lectura al ticket

Cualquier usuario que pertenezca al grupo de trabajo de un ticket y tenga el flag de acceso “IR” podrá leer los detalles del ticket, aunque no podrá modificar nada, ni agregar una UT o fichero.

  • Usuario con acceso de gestión al ticket

Un usuario con el bit de acceso IM sobre el grupo al que pertenece un ticket puede operar con el como si fuera el propietario del mismo. Esto implica que puede «escalar» el ticket apropiándoselo o traspasar la responsabilidad del mismo a otro usuario. Por supuesto puede agregar UT o ficheros e incluso cerrar el ticket.

  • Usuario que cierra el ticket

Es el responsable del cierre del ticket, que puede no ser el mismo que ejecuta la acción. Por ejemplo, el usuario 'tecnico' cierra un ticket por orden del usuario 'admin'. En este caso, el usuario que cierra el ticket sería el usuario 'admin'.

  • Usuario adscrito a un ticket

Es cualquier persona “externa” al sistema. Se pone su email en el campo avanzado “Direcciones de email adicionales”, si hay varios, se separan por comas. Si dicho email es parte del sistema (en el sistema de contactos) se visualizarán algunos de sus datos, como nombre y empresa, sino simplemente su email. En la solapa “Contactos” podemos ver la lista completa de las personas que participan en un ticket.

A continuación vamos a ver las opciones principales que podemos hacer con los tickets de Integria.

Creando un Tipo de ticket

Antes de crear un ticket es muy importante definir los tipos. A un ticket se le puede asignar un tipo. Cada tipo de ticket puede tener asociados campos personalizados según convenga. Estos campos puede ser de varios tipos: texto, combo, área de texto, numérico o linkados. Si se elige el tipo combo o linkado, habrá que especificar los valores que tendrán éstos controles. A continuación, vemos un ejemplo de creación de tipo combo:

Ahora creamos un campo personalizado asociado al tipo anterior:

Los campos marcados con el check “Mostrar en la vista general” son campos que se pueden usar en búsquedas y que se muestran en la visualización de lista. En los campos de tipo textarea no se puede usar esta casilla. Vista general:

Creando un ticket

Ahora que tenemos una ligera noción de los usuarios y los tipos de clientes estamos listos para crear nuestro primer ticket. Vamos a seguir los siguientes pasos. Pulse en el menú superior de ‘Soporte’ → ‘Tickets’, después vaya a la sección de la izquierda y haga clic en el botón ‘Crear ticket’. Aquí podrá rellenar toda la información de alta de la incidencia, asignar el ticket, darle una prioridad, añadir ficheros adjuntos, etc.

Creando una Unidad de Trabajo (UT)

Bien, el ticket ha sido creado por un usuario (llamémosle A) y asignado a otro usuario (llamémosle B). ¿Ahora qué?. Al crear el ticket, el sistema habrá enviado un email al usuario A y otro al usuario B, informando sobre la creación del ticket. Al usuario A, este mensaje le sirve como confirmación de que el ticket ha sido registrado por el sistema. El usuario B, puede contestar ese mismo correo, que lleva un código especial y enviar su primera UT, algo así como “He recibido el ticket”. También puede conectarse al sistema, con la URL suministrada para poder agregar manualmente una UT a el ticket. En el momento que el ticket en estado “Nuevo” recibe una WU, automáticamente se cambia su estado a “Asignado”, es una forma de decir “se ha empezado a trabajar” con el ticket. Independientemente de la manera en que se añada la Unidad de trabajo siempre podremos consultarla en el detalle del ticket en su pestaña de comentarios.

Consultando los tickets generados

Las búsquedas de tickets es la herramienta básica de control de tickets. Se puede usar la vista de búsqueda básica para encontrar los tickets que queremos, o acceder directamente al número de ticket en el menú de la izquierda. Las búsquedas por defecto muestran todos los tickets no cerrados y no solucionados. Las búsquedas son un listado y una información estadística básica sobre los resultados de esta búsqueda. En el menú lateral izquierdo podemos hacer clic sobre ‘Buscar tickets’. En esta pantalla podremos ver los tickets a los que tenemos acceso así como la posibilidad de poder filtrar por diferentes opciones como su estado, responsable, fecha, etc.

Búsquedas de tickets personalizadas

Un ticket es un concepto genérico, pero esto se puede aplicar a un fallo de software (un bug), a un problema de comunicaciones, o a un problema de un cliente con un pedido. En un caso tendrá una serie de campos “personalizados”, y en otros otra. Por ello, la posibilidad de definir búsquedas de tickets personalizadas permite esta flexibilidad de poder guardar una selección con unos filtros concretos. Para ellos, dentro de Buscar Tickets primero filtramos por los campos que necesitemos y pinchamos sobre el el botón de Búsqueda personalizada. Después le damos un nombre a esa búsqueda y ya tenemos guardada la Búsqueda personalizada con los filtros que hemos definido.

Informes / Estadísticas de un ticket

Las Búsquedas personalizadas además se pueden usar como fuente para informes de tickets. Si pulsamos en Informes en el menú lateral izquierdo podemos acceder a la sección donde podemos usar una de esas búsquedas personalizadas guardadas previamente y visualizarlas en pantalla o bien guardarlas en pdf.

Reglas de Workflow

Esta opción permite definir reglas personalizadas que serán aplicadas en la gestión de tickets, es decir, cuando un ticket que no está cerrado cumple alguna condición asociada a una regla, se ejecutan ciertas acciones definidas. Por ejemplo: Cuando un ticket del grupo Soporte lleva 48 horas sin respuesta, se envía un email al usuario responsable informando de esta situación. Cada regla tiene condiciones asociadas que se deberán cumplir para ejecutar las acciones. Si una regla tiene más de una condición, habrán de darse todas las condiciones para que se dispare la acción. Para poder acceder a ellas tenemos que tener permisos de administrador y luego ir al menú lateral izquierdo Reglas de workflow. Para modificar la regla o acceder a sus condiciones y acciones, hay que hacer click sobre la descripción.

En esta ejemplo en la pestaña Condiciones hemos definido las características que debe cumplir el ticket. El grupo debe ser Soporte, la prioridad debe ser Media y el estado Asignado. El campo condición elegido es Match all fields porque queremos que se cumplan todas. Si quisiéramos que se cumpliera alguna, el campo condición seleccionado sería Match any field y si queremos que no se cumpla ninguna, el operador debe ser Not match.

A continuación, vemos las acciones que se ejecutarán si se cumplen las condiciones anteriores en la pestaña Acciones.

Algunos ejemplos de uso serían:

  • “Para cualquier incidencia del grupo Clientes, que lleve más de 10 horas sin actualizar, se envía un email al propietario del ticket con el texto “No se está contestando la incidencia (titulo) del grupo Clientes. Revisad el tema urgentemente”.
  • “Para cualquier incidencia, que lleve más de 21 días abierta, con prioridad “Alta” se le cambia la prioridad a “Media” y se le añade la WU que diga “Repriorizada automáticamente por el sistema”.
  • “Necesita enviar un email de aviso a un coordinador, cuando una incidencia de prioridad muy alta y de un grupo determinado lleva más de 5 días sin actualizaciones.“

Gestión de tickets por email

Integria permite la creación y actualización de tickets mediante el envío de mails. Esta es una característica que permite agilizar la gestión de tickets usando el cliente de correo electrónico.

La creación de tickets y workunits por email usa los mismos principios de ACLs que 
el interfaz gráfico.

Internamente la gestión de tickets por email funciona de la siguiente manera:

Supongamos que tenemos habilitada la siguiente dirección de correo para recibir los email: [email protected] y configurado el parámetro 'Cola de emails de un grupo con el correo [email protected] Además enviaremos un email con los siguientes datos:

  1. Una vez el email está en el inbox de la dirección [email protected] se comprobará si corresponde con alguna cola de correo configurada.
    1. Si no encuentra ninguna cola de correo el email se desecha.
    2. Si encuentra una cola de correo entonces se usaran los parámetros por defecto configurados en esa cola de correo para gestionar el ticket.
  2. Ahora la aplicación procesará el email, en este punto pueden suceder dos cosas:
    1. El email no se corresponde con ningún ticket actual. En este caso se creará un nuevo ticket.
    2. El email se corresponde con un ticket creado en el sistema. En este caso se creará una nueva workunit y se actualizarán los datos del ticket.

La siguiente imagen explica el flujo de gestión de colas de emails de una forma resumida:

Crear un ticket por email

Para crear un nuevo ticket a través del email sólo tiene que enviar un correo al mailbox configurado y que además coincida con una cola de correo configurada en el sistema. Los parámetros del email deben ser:

  • From: <dirección de correo usuario Integria> (si el usuario no existe se creará)
  • To: <mailbox configurado para POP en Integria>, <direcciones de colas de correo>, …
  • CC: <otras direcciones en copia>
  • Subject: <título del ticket>
  • Body: <descripción del ticket>
  • Adjuntos: <archivos adjuntos al email>

Un ejemplo de email para crear un ticket sería:

Este email creará un ticket como el de la siguiente imagen:

Además si añade archivos adjuntos al email, estos serán añadidos de forma automática.

Añadir nueva workunit

Si tiene activado el sistema de envío de emails para seguir las novedades en los tickets de Integria, recibirá emails con las novedades de sus tickets. En algunos de ellos verá que en el título tiene asignado un ticket ID, respondiendo a estos emails podrá añadir nuevas workunits al ticket correspondiente.

Para añadir una nueva workunit sólo tiene que contestar el email añadiendo en el cuerpo el contenido de la workunit. Como resultado aparecerá una nueva workunit en el ticket. Si por ejemplo responde al email con el siguiente cuerpo “Thanks. Please close the incident all its ok. Javi” aparecerá el siguiente workunit.

Al igual que la creación de tickets por email, la creación de workunits añade los archivos adjuntos en los emails a el ticket correspondiente.


Documentación de Integria