Ticketing y soporte

Se puede entender un ticket como una incidencia genérica a un equipo de soporte, una pregunta, para reportar un problema, etcétera.

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.

Hay muchos otros campos opcionales y todos los que el administrador defina para el tipo de ticket (campos personalizados).

En un ticket cada usuario tiene un rol específico:

1. Usuario creador del ticket: Es la persona que identifica el problema e inicia la gestió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. Solamente puede haber una persona ya que el problema se puede escalar (pasar la propiedad del ticket) a otra persona, pero el propietario únicamente puede ser una sola 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. 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 pestaña de Contacts se 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. Este equipo de soporte está formado por tres personas y un jefe de equipo.

Existen 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.
• 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 este entorno, cuando un cliente de tipo agrupado abre un ticket, se asigna a un jefe de equipo. 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 se podrán elaborar acciones mucho más complejas, como enviar un mensaje a Telegram cada vez que reciba una incidencia de prioridad alta o poder asignar un ticket a cierto tipo de usuarios dependiendo de ciertos criterios. Luego llegará un mensaje de correo electrónico tanto al creador del ticket como al receptor del ticket.

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 Pandora ITSM, 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 se entra en la pantalla principal de gestión del ticket. Se puede así cambiar su estado, o navegar por las pestañas 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 ese momento 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.

Solamente el propietario de un ticket puede cambiar los estados del mismo.

Existen otros estados importantes en un ticket, tal como PENDIENTE DE TERCERA PERSONA (Pending on a third person), que pone el ticket en modo de “pausa” con respecto 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 sin propósito 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étera). Un ticket CERRADO se puede bloquear para impedir su reapertura.

El estado REABIERTO (Reopened) es similar al estado ASIGNADO, pero indica que ha sido activado desde el estado CERRADO.

El equipo de personas que trabajan sobre el ticket (el cliente, el operador, los técnicos de segundo nivel, etcétera), interactúan entre sí añadiendo notas de texto (o unidades de trabajo, workunits, en terminología de Pandora ITSM). 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.
• Desde la versión 103 OUM se puede mencionar a cualquier otro usuario, de acuerdo a la visibilidad ACL que tenga el usuario al interactuar con una workunit, y el usuario o usuarios mencionado(s) recibirá(n) un mensaje de correo electrónico para su información.
• 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, y permite que los comentarios privados solamente 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 se agrega 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).

Los valores posibles se deben separar 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, se 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

Existe una solapa dentro de los detalles del ticket que mostrará todos los detalles, a modo de resumen. Se puede ampliar esta información con los informes detallados de tickets (ver informes), pero en general se tiene aquí todo lo que necesita saber. En función del historial de esa incidencia verá más o menos datos.

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

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 u operador de manera presencial. Se puede descargar el documento, y si se quiere se puede validar 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. Se recomienda que se edite la plantilla por defecto para entender cómo funciona.

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

El SLA (Service Level Agreement) es la forma de “comprobar” que la gestión de tickets funciona bajo unos criterios específicos. Pandora ITSM cuenta con funcionalidades de gestión automática de SLA. El SLA se procesa conforme unos parámetros y se configura en el menú 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): Solamente 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.
• 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.
• 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 cuál SLA se aplicará a los tickets de grupo.

Utilizando el sistema de SLA, en la vista del ticket se puede ver 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 porcentaje 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.

La valoración solamente 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. Únicamente los usuarios con permisos de Q/A y el usuario que creó el ticket pueden acceder a esos datos.

La valoración de los tickets de soporte por defecto se encuentra activado a nivel general en el menú Configuración → Configuración → Configuración de incidencias → Comportamiento del ticket → Desactivar puntuación de tickets (Setup → Setup → Issue setup → Ticket behavior → Disable ticket score).

A nivel de grupo, en el menú Personas → Gestión de Grupos (People → Groups management) se cuenta con el token Enviar correo electrónico de satisfacción del cliente (Send customer satisfaction email) activado de manera predeterminada.

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 en el menú Personas → Gestión de grupos (People → Groups management) 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 en 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, establezca criterios de búsqueda y visualice los resultados.

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

Para futuras búsquedas con filtros personalizados, solamente debe hacer clic en el botón Cargar filtro personalizado (Load custom filters) y se visualizarán 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 el menú Configuración → Configuración → Configuración de plantillas de correo electrónico (Setup → Setup → Email templates setup).

Las plantillas de correo se aplican a las incidencias y 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 poseer conocimientos sobre HTML.

Macros para plantillas de correo electrónico, introducen:

• _author_: Creador del incidente.
• _creation_timestamp_: Fecha y hora de la creación del incidente.
• _creatorcompany_: Compañía del creador del ticket.
• _epilog_: Resumen de cierre de 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 quien ha cerrado el ticket.
• _incident_id_: Identificador del incidente.
• _incident_main_text_: Descripción del incidente (texto principal).
• _incident_title_: Título del incidente.
• _fullname_: Nombre completo del usuario.
• _group_: Grupo asignado al incidente.
• _owner_: Usuario quien gestiona el incidente.
• _ownercompany_: Compañía del propietario del ticket.
• 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_”.
• _priority_: Prioridad del incidente.
• _resolution_: Resolución del incidente.
• _status_: Estado del incidente.
• _sitename_: Nombre de la página, tal y como está definido en la configuración.
• _time_used_: Tiempo de vida total del ticket.
• _ticket_satisfaction_: Cuando se cierra un ticket, esta macro se reemplaza por un enlace a la pantalla de satisfacción del ticket.
• _type_tickets_: Tipo de ticket.
• _url_: URL del incidente.
• _update_timestamp_: Última vez que el incidente fue actualizado.
• _username_: Nombre del usuario.
• _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.

Menú Configuración → Configuración → Configuración de incidencias (Setup → Setup → Issue setup).

En cada una de las secciones de Estado y Resolución existen una serie de campos que pueden ser modificados según necesidad e idioma. Para el caso de los idiomas justo al lado de las dos secciones existe un botón de recargar valores por defecto en el idioma que utilice el usuario que está configurando la Personalización.

En el apartado de Día especial se pueden agregar y retirar los días festivos y marcar si dichos festivos son laborables.

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 Pandora ITSM 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.

Volver al índice de documentación de Pandora ITSM