Ticketing y soporte

Volver al índice de documentación de Pandora FMS

Integria IMS propone una visión de la gestión del soporte adaptable a diferentes necesidades: se puede entender un ticket como una incidencia genérica a un equipo de soporte, una pregunta, para reportar un problema, un bug de software o una intervención planificada con una hoja de trabajo adjunta. Integria IMS se puede usar en un call center para que los operadores introduzcan las incidencias en el sistema, o se puede ofrecer en línea, agregado a un formulario en su web para que los clientes puedan crear consultas directamente desde internet. Integria IMS tiene muchos posibles usos.

Los tickets tienen una serie de características básicas como son la urgencia o criticidad del asunto, un título, el grupo asignado, y los usuarios que intervienen en él y su estado y características avanzadas como el campo Description que soporta elementos HTML como texto enriquecido, enlaces web e imágenes o el campo File upload para poder almacenar y compartir ficheros relacionados con la incidencia (documentos PDF, de texto, etcétera).

Luego hay muchos otros campos opcionales y por supuesto, todos los que el administrador defina para el tipo de ticket (campos personalizados).

Cuando hablamos de usuarios tenemos que entender que cada usuario tiene un rol específico, así pues, tenemos:

1. Usuario creador del ticket. Es la persona que identifica el problema o que lanza la cuestión. Será la persona a la que hay que ayudar en el proceso de gestión de incidencias. Aunque el creador del ticket tenga definido un grupo y luego el grupo del ticket sea cambiado, el creador del ticket siempre tendrá visibilidad del ticket (mientras no lo cambien como creador), esto está diseñado de esa manera y el resto de las ACL siguen funcionando igual.
2. Usuario propietario del ticket . Es la persona encargada de solucionar el problema. Sólo puede haber una ya que el problema se puede escalar (pasar la propiedad del ticket) a otra persona, pero el propietario sólo puede ser una persona. Ese propietario es la única persona que puede cerrar un ticket.
3. Usuario editor del ticket. Puede ser diferente del creador, alguien simplemente encargado de introducir el ticket en el sistema. Piense que si el sistema es manejado a través de una línea de operadores, la persona que recoge la llamada e introduce el ticket no es ni el creador del ticket ni la persona que va a solucionarlo.
4. Usuario con acceso al ticket , y que aporta información, pero que no es ni el que lo creó, ni el que lo va a solucionar: puede ser simplemente un técnico que aporta algo de información.
5. Usuario asociado a un ticket : cualquier persona que haya participado en algún momento durante la vida del ticket, realizando modificaciones o añadiendo comentarios. También recibirá notificaciones con las actualizaciones que se produzcan en el ticket.

En la solapa Contacts podrá ver la lista completa de las personas que participan en un ticket y su rol.

Los usuarios a su vez pertenecen a empresas y a grupos, y la visibilidad de los tickets va definida en función de los permisos asignados a esos usuarios. Existen bits de acceso que definen quién puede VER, EDITAR o GESTIONAR tickets. Así pues se necesita el permiso de EDICIÓN para poder crear tickets, y para que un usuario pueda ver el ticket de otro usuario deberá tener visibilidad sobre ese grupo.

A través de un ejemplo se mostrará la operativa de gestión de tickets. 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 actúan de forma independiente. Los que operan en equipo, tendrán a varias personas trabajando simultáneamente que podrán visualizar los tickets de sus compañeros, o bien para aportar algo, o bien para hacerse cargo de ellos. Los clientes o usuarios independientes sólo pueden ver sus propios tickets, y nadie más tiene acceso a éstos.

El primer tipo de cliente tendrá un grupo propio y varios usuarios asignados a ese grupo, los usuarios de este grupo serán de tipo “agrupado”, y sus privilegios se basarán en el perfil que tengan asociado para su grupo de trabajo. Mientras que el segundo tipo de cliente actuará de forma individual y su usuario será de tipo “independiente”, de forma que únicamente visualizará su propio contenido.

En nuestro entorno, cuando un cliente de tipo agrupado abre un ticket, se asigna a un usuario llamado “Ramón”. Ese usuario será quien reciba el ticket y luego podrá escalarlo si procede a otros usuarios. También se podría enviar a un usuario genérico que actúe como una lista de correo. Como se verá más adelante, con los workflows podrá elaborar acciones mucho más complejas, como enviar un mensaje a Telegram cada vez que reciba una incidencia de prioridad alta, poder asignar un ticket a cierto tipo de usuarios dependiendo de ciertos criterios y muchas otras acciones.

Llegará un mensaje de correo tanto al creador del ticket como al receptor del ticket, algo parecido a este correo:

Se puede contestar el correo y dicha respuesta se añadirá al “hilo” de comentarios del ticket. Otra opción es continuar su gestión a través de la interfaz web de Integria IMS, lo cual permitirá hacer muchas más cosas que simplemente poner un comentario.

Cuando un usuario crea un ticket y este se queda en estado “NUEVO” se verá con un fondo ligeramente rojizo, similar al siguiente:

Haciendo clic en el número de ticket o su descripción entra en la pantalla principal de gestión del ticket. Puede cambiar su estado, o navegar por las solapas del ticket para ver su histórico, notas asociadas al ticket (workunits), ficheros, etcétera.

El estado de un ticket comienza en un estado NUEVO (New) y a partir de ahí el contador de tiempo se pone en marcha. La gestión de SLA (Service Level Agreement) cuenta el tiempo desde que se abre un ticket hasta que se empieza a gestionar y cambia de estado de NUEVO a ASIGNADO (Assigned). También cuenta el tiempo que pasa desde que el creador del ticket escribe y recibe respuesta y el tiempo total que se tarda en resolver una incidencia. Solo el propietario de un ticket puede cambiar los estados del mismo.

Existen otros estados importantes en un ticket, como PENDIENTE DE TERCERA PERSONA (Pending on a third person), que pone el ticket en modo “pausa” de cara al SLA, ya que generalmente se refiere a una situación por la cual es necesario esperar a que alguien proporcione algo de información para proseguir con la resolución del ticket.

También existen dos estados especiales: PENDIENTE DE CIERRE (Pending to be closed) y SIN CONFIRMAR (Unconfirmed) que son estados temporales por los que marcar un ticket que está pendiente de cierre o ha sido recibido pero que todavía no se ha clasificado. Sirven sobre todo para identificar el ticket en un estado que luego se pueda procesar con reglas de workflow, pero no tiene otro propósito de cara a su incidencia con la gestión de SLA.

El estado CERRADO (closed) hace referencia expresa al fin de vida y permite añadir un epílogo de resolución y un campo específico para indicar la resolución del mismo (solucionado, rechazado, faltan datos, expirado, etc). Un ticket CERRADO se puede bloquear para impedir su reapertura. El estado REABIERTO (reopened) es similar al estado ASIGNADO, pero indica que ha sido revivido desde el estado CERRADO.

El equipo de personas que trabajan sobre el ticket (el cliente, el operador, los técnicos de segundo nivel, etc.), interactúan entre sí añadiendo notas de texto (o workunits en terminología de Integria IMS). Cada usuario con acceso al ticket aporta información para su resolución. Para ello, basta con contestar uno de los correos del ticket o bien se puede introducir manualmente a través de la interfaz usando la solapa marcada con un bocadillo:

• Las WU (Workunits) permiten escribir un texto y, además, añadir adjuntos, especificar el tiempo dedicado en esa acción (en horas), si ha trabajado conjuntamente con otro miembro del equipo, si se incluye cálculo de costes en función del perfil imputado, etcétera.
• Toda esta información se utilizará luego para los informes de soporte que incluyen todas estas métricas (y muchas otras). La intención es poder hacer un seguimiento pormenorizado del tratamiento de cada incidencia para poder evaluar la calidad del soporte desde todos los ángulos posibles: costes, calidad, tiempos, esfuerzo, perfiles de personal, perfiles de cliente, entre otros.

Al hacer clic en el icono de bocadillo llevará al siguiente cuadro de diálogo:

• Time used: Tiempo empleado, en horas, en el mensaje.
• Private workunit: Aparece si el token New WU are always public está activo en la configuración de unidades de trabajo, permite que los comentarios privados solo sean mostrados a los administradores y al usuario que añadió el comentario.
• Cost: Para indicar que se debe tener en cuenta para cálculos de coste del servicio.
• Internal: Para marcar si el comentario no será visible para el creador de la incidencia.
• Profile: Muestra información adicional acerca del perfil de quien escribe el mensaje.
• Description: Presenta un editor HTML que permite añadir texto enriquecido, enlaces e imágenes.
• Workunit shared with: Compartir la WU con otro usuario de la misma empresa; escriba dos o más letras para buscar usuarios.

Para finalizar agregue la WU con el botón Add.

Véase también “Configuración de tickets” y “Límites a la creación de tickets”.

Un ticket tiene una serie de campos personalizados por el usuario, que están relacionados con el tipo de ticket. Es posible crear diferentes tipos de tickets, y cada uno con sus campos personalizados.

Además de los campos definidos por el administrador, existe una serie de campos especiales, que se pueden ver en la vista de edición, en la caja “Parámetros avanzados” (Advanced parameters):

El editor es el usuario de la aplicación que crea el ticket, y consta por motivos de auditoría y registro, no se puede cambiar. Lo mismo ocurre con el grupo creador. Son campos “fijos” que luego podremos utilizar como filtros en las reglas de workflow.

Se pueden definir jerarquías de tickets anidados, vinculando uno con otro en una relación padre-hijo, para eso está el campo “Ticket padre” (Parent ticket). También se puede vincular un ticket de soporte a un proyecto, a través de la vinculación con una tarea (Task), ya que las tareas son subdivisiones de los proyectos.

De la misma manera, se puede vincular uno o varios objetos de inventario a una incidencia, de manera que luego se pueda tener una trazabilidad de a qué elementos afecta una incidencia y ver también el historial de incidencias que ha tenido un determinado objeto de inventario.

También es posible tener al tanto del flujo de vida de un ticket a un grupo de terceras personas de las cuales sólo tenemos su dirección de correo electrónico, que ni siquiera tienen acceso a Integria IMS. De esta manera les irán llegando copias de todo lo que suceda a través de correo electrónico. Es una manera sencilla de incluir a terceros y mantenerlos informados.

Se pueden definir tickets de diferentes tipos, de manera que cada tipo de ticket tenga sus propios campos. Estos campos podrán ser de tipo texto, fechas, casilla de verificación (checkbox), un selector e incluso hacer que se puedan encadenar varios selectores, y que en función de la selección del usuario se desplieguen unos valores u otros.

Además es posible configurar que cierto tipo de tickets estén disponibles sólo para determinados grupos: por ejemplo si tiene un grupo de soporte técnico y un grupo de soporte al usuario, los tipos de ticket “Incidencia técnica” que requiere rellenar muchos campos detallados, solo estaría disponible para el grupo “técnicos”, mientras que otros tipos de ticket que no requieren conocimientos técnicos están disponibles para cualquiera.

Puede crear o modificar un tipo de ticket personalizado Soporte → Tipos de tickets → Ver tipos de tickets (Support → Tickets Types → View tickets types).

Cuando se define un tipo de ticket podrá establecer uno o varios campos personalizados. Puede que necesite definir un campo común para todos los tipos de tickets personalizados (y así no tener que ir uno por uno, metiéndolo en todos) y para eso está el “campo global” (Global field).

Existen campos de tipo texto (una línea), texto ampliado (una caja de texto libre multilínea), datos de tipo fecha (que mostrará un calendario), de tipo numérico (y que el sistema validará que sea un número) o de tipo “verdadero/falso”.

Existen dos tipos más complejos, como el selector de valores (Combo) y los campos relacionados (Linked).

Simplemente separe los valores posibles con comas y el sistema los mostrará en un selector:

Son campos personalizados relacionados entre sí. Por ejemplo, un técnico IT necesita identificar el elemento a reparar. Para llegar a ello, necesitará primero escoger el tipo de elemento:

• Ordenador portátil (Laptop).
• Ordenador de escritorio (PC).
• Teclado (Keyboard).
• Ratón (mouse).
• Pantalla (Monitor).
• Otro (Other)

Además, en función del tipo elemento, debe escoger unas marcas de fabricantes para cada uno de ellos.

Primero debe crear el campo personalizado “Tipo de hardware” (Hardware type). En este caso, no se selecciona un campo padre (Parent) porque es el primero en la jerarquía. Los valores irán separados por comas:

El segundo campo enlazado, en este caso sería la marca, tendrá como padre al campo “Tipo de hardware” y los valores enlazados tendrán un formato especial:

valor_tipo1|valor_marca1,[valor_tipo2|valor_marca2],[valor_tipo3|valor_marca3]...

De esta manera, siguiendo el ejemplo anterior, se debe definir así:

Laptop|HP,Laptop|Lenovo,Laptop|Mac,PC|HP,PC|Dell,Keyboard|ES,Keyboard|UK,Keyboard|Mac,Mouse|Mac,Mouse|Logi,Mouse|HP,Mouse|Microsoft,Other|Trackball

Esto se ve en la interfaz de creación de tickets de la siguiente manera:

Existe una solapa dentro de los detalles del ticket que mostrará todos los detalles, a modo de resumen. Puede ampliar esta información con los informes detallados de tickets (ver informes), pero en general tiene aquí todo lo que necesita saber. En función del historial de esa incidencia verá más o menos datos. Si, por ejemplo, la incidencia aún no se ha cerrado, tendrá menos información. Ejemplo:

Si en el proceso de la incidencia se necesita generar un documento (PDF) con todos los detalles, en un formato específico, para entregar a un cliente o a un proveedor a modo de albarán o prueba de ejecución de un trabajo, se necesita realizar un parte de trabajo (Work order). Usted puede definir sus propios partes de trabajo usando una plantilla y luego hacer que se rellene automáticamente usando macros.

Para crear un parte de trabajo, vaya al menú Soporte → Tipos de ticket → Plantillas de parte de trabajo ( Support → Tickets Types → Work order templates ) y haga clic en el botón de Crear (Create):

Se creará con la plantilla del sistema (viene una definida por defecto, que se puede personalizar). Automáticamente la dejará accesible para descarga en esa misma ubicación:

Este es un ejemplo de como se ve el PDF generado por esa orden de trabajo:

Algunos de esos campos se han rellenado con datos del ticket, otros se podrían rellenar usando campos personalizados y otros se dejan en blanco para rellenar manualmente por el cliente / operador de manera presencial. Descargue el documento, y si quiere puede “validarlo” subiendo una versión de ese mismo documento firmado por el cliente (escaneado o fotografiado) para que quede constancia.

Se pueden asignar diferentes plantillas de partes de trabajo en función del tipo de ticket. Existe un conjunto de macros que puede usar para reemplazarlas por los datos del ticket. Recomendamos que edite la plantilla por defecto para entender cómo funciona. En el siguiente ejemplo los macros están señalados por recuadros de color rojo:

Las siguientes macros serán reemplazadas por el valor real en las plantillas que las usen:

• _sitename_ : Nombre de la página, tal y como está definido en la configuración.
• _incident_title_ : Título del incidente.
• _username_ : Nombre del usuario.
• _fullname_ : Nombre completo del usuario.
• _incident_id_ : Identificador del incidente.
• _url_ : URL del incidente.
• _creation_timestamp_: Fecha y hora de la creación del incidente.
• _update_timestamp_ : Última vez que el incidente fue actualizado.
• _owner_ : Usuario que gestiona el incidente.
• _group_ : Grupo asignado al incidente.
• _author_ : Creador del incidente.
• _type_tickets_ : Tipo de tickets.
• _priority_ : Prioridad del incidente.
• _status_ : Estado del incidente.
• _resolution_ : Resolución del incidente.
• _time_used_ : Tiempo total usado en el incidente.
• _incident_main_text_ : Descripción del incidente.
• Plantillas de campos personalizados: Esto permite que al crear un tipo de objeto el nombre de los campos que se agregan pueden incluirlos como una macro la cual mostrará el valor de dicho campo: _nombre del campo personalizado_.

Uno de los campos más importantes de los tickets es el estado. Mediante este campo puede hacer un seguimiento preciso del momento de su vida en que se encuentra el ticket. Este ciclo está abierto al usuario y se puede modificar.

Es posible definir un flujo controlado para restringir el orden de los estados por los que un ticket puede pasar mediante la característica del Mapeo de estados. Haciendo uso del mapeo de estados puede definir si un ticket debe pasar por diferentes fases antes de ser cerrado. Esto se configura en Soporte → Flujo de trabajo → Mapeo de estados ( Support → Workflow → Status mapping )

Ejemplo de diferentes estados de un ticket:

Un equipo de operadores es responsable de la gestión de incidencias de clientes. Para asegurar que el orden de resolución es respetado y garantizar una calidad de servicio al cliente, mediante el mapeo de estados se indica que:

1. Un ticket con estado “Nuevo” (New) únicamente puede pasar a los estados “Asignado” (Assigned) o “Pendiente de tercera persona” (Pending on a third person).
2. De cualquiera de estos dos estados únicamente podrá pasar a “Pendiente de ser cerrado” (Pending to be closed).
3. Solamente si está en “Pendiente de ser cerrado” podrá quedar finalmente “Cerrado” (Closed).
4. Además, desde “Cerrado” la única posibilidad será volver a ser “Re-abierto” (Reopened).

La configuración para este caso sería:

Para cada condición inserte una línea con Add row y guarde en el icono de disco flexible. También puede borrar una condición en el icono de papelera (columna Actions) y guardar los cambios para una condición en el icono Update que esta junto a borrar.

El SLA (Service Level Agreement) es la forma de “comprobar” que la gestión de tickets funciona bajo unos criterios específicos. Integria IMS cuenta con funcionalidades de gestión automática de SLA. El SLA se procesa conforme unos parámetros y se configura en Soporte → Ver SLA (Support → View SLA).

Algunos de los campos que requieren explicación son los siguientes:

• SLA Base: Indica relación con otro SLA a nivel informativo.
• SLA Type (Tipo SLA):
  • Normal SLA: Se tendrán en cuenta, a la hora de hacer el cálculo, los tickets que no se encuentren en estado “Cerrado” o “Pendiente de terceros”.
  • Third party SLA (SLA de terceros): Solo se tendrán en cuenta los tickets que estén en estado “Pendiente de terceros”.
  • Both (Ambos): Se tendrán en cuenta los tickets que estén en cualquier estado que no sea “Cerrado”.
• Max. response time (in hours) (Max. Tiempo de respuesta, en horas): Tiempo máximo que puede transcurrir entre una workunit del creador del ticket y otra respuesta. Por ejemplo, si este tiempo son 4 horas, y un ticket nuevo tiene 4 horas y 6 minutos de vida, se disparará el SLA. Si un ticket ya tiene varios días de vida y la última unidad de trabajo o workunit es del creador del ticket, tras 4 horas sin respuesta también se disparará el SLA.
• Max. resolution time (in hours) (Max. Tiempo de resolución, en horas): El máximo tiempo de vida de un ticket. Si un ticket tiene más de ese tiempo y no está cerrado o resuelto, saltará el SLA.
• Max. tickets at the same time (Nº Máx de tickets abiertos al mismo tiempo): Si se supera, saltará el SLA. Tenga en cuenta que todos los SLA se configuran a nivel de grupo.
• Max. ticket inactivity (in hours) (Max. tiempo inactividad, en horas): Tiempo que puede estar el ticket sin una actualización por parte de cualquier usuario con acceso al ticket.
• Start hour to compute SLA (Hora de comienzo para activar el SLA): Hora del día a partir de la cual el SLA se empieza a calcular (p.e: 9 de la mañana).
• Last hour to compute SLA (Hora de fin para una SLA): Hora del día a partir de la cual el SLA ya no se calcula (p.e: 6 de la tarde).
• Disable SLA on weekends (Deshabilitar SLA en fines de semana): Considera sábados y domingos.
• Disable SLA on holidays (Deshabilitar SLA en festivos): los días definidos como festivos no se incluirán en los cálculos de SLA. En la configuración de tickets (ver más adelante) podrá definir los días de calendario que el SLA considerará festivos.

Significa que el sistema enviará una notificación por correo electrónico al propietario del ticket, advirtiendo que el ticket no cumple los criterios establecidos en el conjunto de reglas de SLA asociada al ticket.

Esto dependerá del grupo al que está asociado el ticket, ya que es en la configuración de grupo donde se especifica qué SLA se aplicará a los tickets de grupo:

Utilizando el sistema de SLA, en la vista del ticket puede verse en una escala de tiempo (histograma), cuando el ticket no ha cumplido (en rojo) y cuando ha cumplido (en verde). Además de un indicador del porcentae de cumplimiento del ticket en toda la vida de éste o por rangos de fechas (últimos 15 días, el día de hoy, etcétera).

Las métricas de SLA se pueden obtener mediante API por cada incidente, por cada grupo, por cada operador. También se utilizan en informes. Son las métricas más importantes para medir la calidad del servicio.

El aseguramiento de la calidad ( Quality Assurance o Q/A) y la retroalimentación (feedback) de los tickets bien puede ser configurado.

Por defecto el sistema preguntará al creador del ticket, cuando este se cierre (independientemente de quién lo cierre), cómo se ha cerrado el ticket . Se enviará un mensaje de correo electrónico para que acceda a una pantalla de valoración como la siguiente:

La valoración solo puede ser buena o mala, y en ambos casos se puede añadir un texto explicativo opcional. Dichas valoraciones se asocian al ticket y a la persona dueña del mismo y no son visibles para dicha persona.

Solo los usuarios con permisos de Q/A pueden acceder a esos datos, y también el usuario que creó el ticket. Dicha valoración puede ser vista en el propio ticket de la siguiente manera:

Para activar la valoración de los tickets de soporte debe revisar que no esté desactivado a nivel global, vaya al menú Configuración → Setup → Configuración de soporte ( Setup → Setup → Issue setup )

Y también se configura a nivel de cada grupo:

Se puede limitar, por cada grupo, el total de tickets creados por usuario (Total ticket limit), y el total de tickets activos para un usuario (Open ticket limit). Son dos límites diferentes que pueden configurarse conjuntamente.

Esto se configura en la definición del grupo ( menú Personas → Gestión de grupos) en los campos Open ticket limit y Total ticket limit. Además es posible que el límite de tickets abiertos simultáneos se pueda “forzar” y que no permita crear nuevos tickets o simplemente “avisar” con un mensaje, pero que permita crearlos. Para trabajar sin límites, deje el valor a 0.

Se puede crear una búsqueda personalizada y almacenarla para su uso en informes, en el dashboard y la propia búsqueda de tickets, cargando dicho filtro.

Todas las búsquedas personalizadas guardadas se podrán reutilizar en la vista general de tickets además de ser los datos base para los informes estándar de tickets.

Para ello, primero utilice el buscador de tickets en Support → All tickets y busque resultados:

Y haga clic en Añadir filtro personalizado (Add custom filter). Se le preguntará el nombre del filtro (Filter name), rellene y guarde con el botón Guardar filtro personalizado (Save custom filter):

Para futuras búsquedas con filtros personalizados, solo debe hacer clic en el botón Cargar filtro personalizado (Load custom filters) y visualizará los resultados seleccionados en pocos segundos.

Se pueden personalizar todos los emails que se envían, cambiando su aspecto. Para ello se utilizan un conjunto de macros que se introducen en la plantilla. Las plantillas son ficheros HTML que se pueden editar desde la propia herramienta, en Configuración → Setup en la solapa de Plantilla de correo:

Las plantillas de correo se aplican no sólo a las incidencias, sino también a la gestión de proyectos. Se puede incluso asignar diferentes plantillas en función del grupo:

La edición es simple e intuitiva, y se pueden realizar cambios menores (logo, textos) desde el propio editor sin necesidad de saber HTML.

Macros usados en las plantillas de correo electrónico:

• _sitename_ : Nombre de la página, tal y como está definido en la configuración.
• _incident_title_ : Título del incidente.
• _username_ : Nombre del usuario.
• _fullname_ : Nombre completo del usuario.
• _incident_id_ : Identificador del incidente.
• _incident_title_ : Título del incidente.
• _url_ : URL del incidente.
• _creation_timestamp_ : Fecha y hora de la creación del incidente.
• _update_timestamp_ : Última vez que el incidente fue actualizado.
• _owner_ : Usuario que gestiona el incidente.
• _group_ : Grupo asignado al incidente.
• _author_ : Creador del incidente.
• _type_tickets_ : Tipo de ticket.
• _priority_ : Prioridad del incidente.
• _status_ : Estado del incidente.
• _resolution_ : Resolución del incidente.
• _time_used_ : Tiempo total usado en el incidente.
• _incident_main_text_ : Descripción del incidente (texto principal).
• Plantillas de campos personalizados: Esto permite que al crear un tipo de objeto el nombre de los campos que agregas puedes incluirlos como una macro la cual mostrará el valor de dicho campo: _nombre_del_campo_personalizado_ .
• _creatorcompany_ : Compañía del creador del ticket.
• _ownercompany_ : Compañía del propietario del ticket.
• _id_group_ : Identificador del grupo asignado al ticket.
• _id_priority_ : valor numérico de la prioridad del ticket.
• _id_status_ : Valor numérico del estado del ticket.
• _incident_closed_by_ : Usuario que ha cerrado el ticket.
• _time_used_ : Tiempo de vida total del ticket.
• _wu_user_ : En las plantillas de WU, el usuario que ha escrito la nota.
• _wu_text_ : En las plantillas de WU, el texto de la nota.
• _ticket_satisfaction_ : Cuando se cierra un ticket, esta macro se reemplaza por un enlace a la pantalla de satisfacción del ticket.
• _epilog_ : Epílogo (resumen) de cierre de ticket.

Vaya al menú Configuracion → Setup y acceda a la solapa de configuración avanzada de incidencias:

En esta pantalla hay numerosos chequeos que definen cómo se comporta el sistema:

• Mostrar el creador del ticket y mostrar el dueño del ticket en la vista / listado de búsqueda de tickets.
• Máximo número de tickets por búsqueda: limite los resultados en búsqueda de tickets para evitar impactos en el rendimiento por búsquedas excesivamente grandes. Se recomienda un límite entre 200 y 500.
• Habilitar modo de edición rápida: Permite editar rápidamente algunos elementos del ticket (usuario propietario, criticidad, estado) sin entrar en el modo edición completo.
• Mostrar el nombre de usuario en lugar del identificador en la búsqueda de tickets: nombre real en lugar del ID.
• Dos opciones de formato de fecha: formato largo yyyy/mm/dd h:m:s (opción por defecto) y formato aproximado; ejemplo: 1 día, 2 horas.
• Fecha de realización: Marcar esta opción mostrará el campo Fecha de realización en las workunits de los tickets. Esa fecha puede ser diferente de la fecha de creación del workunit.

• Deshabilitar valoración de las incidencias.
• Habilitar IW para cambiar el creador: Usuarios con ese bit de acceso podrán cambiar el creador del ticket.
• Editor añade WU en la creación del ticket: se añade una WU automáticamente al crear un ticket.
• Permitir cambiar el tipo de ticket: si se desactiva, no se podrá cambiar el tipo una vez creado.
• Permitir definir la hora/fecha del ticket al crearla.
• Ignorar usuario definido por el grupo para el propietario.
• Tipo de incidencia requerida: obliga a elegir un tipo de ticket.
• Ignorar el usuario creador por defecto: deberá ser especificado manualmente.
• Permitir la modificación del usuario creador y el usuario propietario.
• Permitir a usuarios externos (no agrupados) modificar sus tickets.
• Ignorar plantilla de grupo al creador del incidente.
• Usuario creador puede ver todos los usuarios. Con esto podrá ver usuarios de otros grupos.
• Auto asignarse ticket, en base a las reglas de asignación de los grupos.
• Editor del ticket es el primer usuario en editar: si se marca, el usuario editor del ticket siempre se establecerá como el usuario que editó el ticket en primer lugar.

• Auto cierre del ticket: Número de horas tras las cuales un ticket será cerrado de forma automática.
• Tiempo por defecto WU del ticket: valor por defecto utilizado al introducir una unidad de trabajo, en unidades de hora. 0.25 serán 15 minutos.
• Ordenar WU por fecha de realización (en el listado de WU de un ticket).

Los campos serán los siguientes de acuerdo con el el orden lógico establecido por la herramienta (los nombres se han numerado para facilitar el trabajo):

1. Inicio.
2. Cierre.
3. Título.
4. Descripción.
5. Id de usuario.
6. Estado.
7. Prioridad.
8. Id del grupo.
9. Actualización.
10. Identificador del creador.
11. Identificador de la tarea.
12. Resolución.
13. Epílogo.
14. Identificador del padre.
15. SLA deshabilitado.
16. Identificador del SLA afectado.
17. Identificador del tipo de incidencia.
18. Puntuación.
19. Correos en copia.
20. Editor.
21. Identificador del grupo creador.
22. Último estado.
23. Cerrado por (nombre).
24. Extra data.
25. Extra data 2.
26. Bloqueado.
27. Estado antiguo.
28. Resolución antigua.
29. Estado antiguo 2.
30. Resolución antigua 2.
31. Extra data 3.
32. Extra data 4.
33. No mostrar aviso para valorar resolución del ticket.
34. Hash.
35. Valoración (positiva o negativa).
36. Comentario de la valoración.
37. Campos personalizados: deberán existir previamente en el sistema Integria IMS y deberán indicarse en orden, pudiendo elegir un valor, o en caso de no querer darles valor, espacio en blanco. En el caso de los tickets será necesario crear el tipo al que pertenecen los campos y obviamente referenciar ese tipo en el propio ticket.

“2021-01-21 19:24:19, 2021-01-21 19:47:44, Terminal estropeado, Necesita reemplazo, tecnico_soporte, 7, 3, 4, 2021-01-21 19:47:44, admin, 0, 1, 0, ,0, 0, 1, 0, , tecnico_soporte, 1, 0000-00-00 00:00:00, tecnico_soporte, , , 0, 3, 0, 7, 1, , , , 0, , 0, ,valor_campo_personalizado1, valor_campo_personalizado2”[m]

Volver al índice de documentación de Pandora FMS