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

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 (Work unit shared with), 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 un cuadro de diálogo con los siguientes campos:

• Time dedicated (hours): 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.
• Add to project`s cost: Para indicar que se debe tener en cuenta para cálculos de coste del servicio (proyectos).
• Internal workunit: Para marcar si el comentario no será visible para el creador de la incidencia.
• 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 de ellos 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 Advanced parameters:

El editor es el usuario de la aplicación que crea el ticket y siempre consta por motivos de auditoría y registro (no se puede cambiar). Lo mismo ocurre con el Creator group. Son campos “fijos” que luego se podrán 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 ello está el campo 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, tal que luego se pueda tener una trazabilidad de a cuáles 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 solamente tenemos su dirección de correo electrónico y que ni siquiera tienen acceso a Pandora ITSM. Así 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 o un selector de lista. Incluso se pueden encadenar varios selectores y que en función de la selección del usuario se desplieguen unos valores u otros.

Es posible configurar que cierto tipo de tickets estén disponibles solamente para determinados grupos: Si tiene un grupo de soporte técnico y un grupo de soporte al usuario, los tipos de ticket “Incidencia técnica” (que requieren de rellenar muchos campos detallados) estaría disponible para el grupo “técnicos”. Así otros tipos de ticket que son sin conocimientos técnicos estarían disponibles para cualquiera.

Cuando se define un tipo de ticket se podrá establecer uno o varios campos personalizados. Puede que se necesite definir un campo común para todos los tipos de tickets personalizados (para ahorrar trabajo editando todos de una vez): Para eso existe el Global field.

Otras opciones permiten que el campo personalizado sea mostrado en la lista de incidencias y si es necesario especificar su valor o no.

Están disponibles los campos de tipo texto (una línea), de 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 llamado Combo y los campos relacionados llamados Linked.

Se debe agregar un campo personalizado y escoger la opción Combo. Los valores posibles se deben separar con comas y el sistema los mostrará en un selector.

Son campos enlazados entre sí, un principal y un secundario. Dependiendo de la elección en el campo principal el campo secundario mostrará distintos valores.

Si se necesita atender las incidencias de hardware en los accesorios periféricos de teclado y ratón se puede crear un campo principal con esas dos opciones y luego un campo secundario con los tipos de conexión al ordenador de dichos periféricos.

Creación del campo principal:

1. Agregar un campo personalizado.
2. En Field name ingresar Peripherals.
3. En Type seleccionar Linked.
4. En Parent, por ser el campo principal, dejarlo con el valor por defecto Select parent.
5. En Linked value insertar ,Keyboard,Mouse.
6. Pulsar el botón Create para guardar el campo principal.

Creación del campo secundario:

1. En Field name ingresar Peripheral connection type.
2. En Type seleccionar Linked.
3. En Parent, por ser el campo secundario, seleccionar Peripherals.
4. En Linked value insertar ,Keyboard|USB,Keyboard|Bluetooth,Keyboard|PS/2,Mouse|USB,Mouse|Bluetooth.
5. Pulsar el botón Create para guardar el campo secundario.

Al crear un nuevo ticket y escoger su tipo resultará algo similar a esto:

Existe una solapa dentro de los detalles del ticket que los mostrará todos a modo de resumen. Se puede ampliar esta información con los informes detallados de tickets y en general se tiene aquí todo lo que se 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 crear partes de trabajo definiendo una plantilla y luego hacer que se rellene automáticamente para cada incidencia usando macros.

Algunos de esos campos se rellena con datos del ticket (macros), otros se podrían rellenar usando campos personalizados (macro con el nombre del campo) y otros se dejan en blanco para rellenar manualmente por el cliente u operador de manera presencial.

Luego se accede a la edición del ticket, opción Work order y se pulsa el botón New Work order:

Una vez creado el parte de trabajo a partir de la plantilla correspondiente se puede descargar el documento:

También se puede validar (Validate work order) subiendo una versión de ese mismo documento firmado por el cliente (escaneado o fotografiado) para que quede constancia.

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.

De manera predeterminada este ciclo está libre al usuario y se puede modificar sin requisito previo.

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 de manera obligatoria por diferentes fases antes de ser cerrado.

Las combinaciones entre los distintos estados son muchas, se muestra uno de los casos más sencillos: Un ticket nuevo (estado inicial) solamente podrá pasar a estar asignado. Luego de ser trabajado solamente puede estar pendiente por cerrar y luego de revisar ser cerrado con dos opciones: solucionado o incompleto. En caso de estar incompleto tiene la posibilidad de ser reabierto y de allí se pueden agregar más condiciones.

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ú 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):

1. 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”.
2. Third party SLA (SLA de terceros): Solamente se tendrán en cuenta los tickets que estén en estado “Pendiente de terceros”.
3. Both (Ambos): Se tendrán en cuenta los tickets que estén en cualquier estado que no sea “Cerrado”. Versión 106 o posterior: Al seleccionar ambos aparecerá la opción Max. ticket inactivity (in hours) for Third party SLA para poder configurar unos parámetros por SLA Normal y otros parámetros por SLA de terceros y se aplicarán dependiendo del estado del ticket, de una forma u otra.

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

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ú Setup → Setup → Issue setup → Ticket behavior → Disable ticket score.

A nivel de grupo, en el menú 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, y el total de tickets activos para un usuario. Son dos límites diferentes que se pueden configurarse conjuntamente:

• Total ticket limit: Si se trata de un usuario agrupado, muestra el número máximo de tickets para el grupo que un usuario puede tener en total (abierto o cerrado). Si se trata de un usuario independiente, muestra el número máximo de tickets para un usuario, para ese grupo, que un usuario puede tener en total (abierto o cerrado).
• Open ticket limit: Si se trata de un usuario agrupado, muestra un número máximo de tickets para este grupo que un usuario puede haber abierto al mismo tiempo. Si se trata de un usuario independiente, muestra el número máximo de tickets para este grupo y para un usuario que un usuario puede haber abierto al mismo tiempo.

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 y que permita crearlos. Para trabajar sin límites, se debe dejar 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 (incluyendo las columnas elegidas con Set custom columns), 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.

Una vez se hayan establecido los criterios de filtrado se guarda pulsando la opción Add custom filter. Se preguntará el nombre del filtro y se guardará con el botón Save custom filter.

Para futuras búsquedas con filtros personalizados, solamente se debe hacer clic en el botón Load custom filters y pulsar en el correspondiente Load preset. En dicho cuadro de diálogo también se podrá seleccionar uno o varios filtros y borrarlos con Delete selected presets.

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

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_”.

• 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.
• La lista de campos a mostrar en la lista de incidencias viene preconfigurado y puede ser modificado en la sección Default custom columns.

Cada item tiene un selector individual o un selector de todos los elementos mostrados a fin de realizar una misma operación sobre la selección realizada. La interfaz es mostrada a todos los usuarios sin embargo al ordenar la ejecución de los cambios se comprobarán los permisos y, si procede, se guardarán las modificaciones solicitadas.

Se puede modificar de manera masiva el estado de cada ticket, prioridad, estado de resolución, etiqueta de la tarea, grupo, asignar un ticket como padre de los seleccionados, o cambiar su propietario. Por último, y se debe utilizar con cuidado, está la opción de borrar los elementos seleccionados.

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