Solicitudes con tareas y aprobación

«Empieza un compañero nuevo» no es un solo ticket. Es un portátil, dos cuentas, una extensión de teléfono y quizá acceso desde fuera. Cada pieza pertenece a un equipo distinto, y aun así quieres un único caso que te diga cómo va la cosa.

Para eso sirve una solicitud. Es un ticket que crea sus tareas en el momento de presentarse, y cada tarea se convierte en un ticket propio en el equipo que la atiende.

Una solicitud no es una segunda cosa que mantener. Vive sobre una plantilla de ticket: en «Settings → Request workflows» encuentras todas las plantillas de ticket y enganchas las tareas a una de ellas.

Para cada tarea rellenas unos pocos campos. «Task» es el nombre que lee quien solicita, «Handled by» es el equipo que la recibe, y «Ticket title» y «What the team has to do» rellenan el ticket que sale de ella.

Varias tareas pueden apuntar al mismo equipo. Ese equipo recibe entonces varios tickets, no un ticket con una lista dentro.

Una tarea sin equipo ni siquiera se ofrece. El propio campo lo dice: «Not assigned yet — this task is not offered». Así puedes guardar un plan que todavía no está terminado.

Encima de las tareas hay una frase que resume todo el plan: qué se crea de fábrica, cuánto puede cambiar quien solicita y quién lo aprueba. Cambia un ajuste y la frase se reescribe sola.

Delante de «Ticket title» está el texto fijo «Parent ticket title -». El nuevo ticket empieza con el título de la solicitud, seguido de tu título, por ejemplo «New colleague in accounting - Set up notebook and docking station». Así el equipo especializado ve a qué solicitud pertenece una tarea. Si dejas el campo vacío, en su lugar va el nombre de la tarea.

«Main category» y «Subcategory» rellenan de antemano la categoría del nuevo ticket. Solo te aparecen las categorías del equipo de «Handled by», porque es ahí donde se crea el ticket. Si cambias el equipo, los dos campos se vacían. Rellenas los dos o ninguno, y si quedan vacíos, el ticket se crea sin categoría.

El nombre de la solicitud está encima de las tareas. Con el lápiz de al lado le cambias el nombre. El nombre pertenece a la plantilla de ticket, así que también cambia en «Settings → Templates» y en el formulario de ticket nuevo.

Cuando alguien elige la plantilla en el formulario de ticket nuevo, aparece el recuadro «What is needed?» con una línea para marcar por cada tarea.

Hay tres tipos, definidos por tarea. «Selectable, off by default» empieza vacía, «Selectable, on by default» empieza marcada y se puede desmarcar, y «Always — cannot be deselected» se ejecuta siempre.

Una tarea que se ejecuta siempre se muestra igualmente, marcada con «(always included)». Quien solicita debería ver lo que va a ocurrir de todos modos.

Debajo del recuadro lees en qué se convertirá: «Each selected item becomes its own ticket for the team that handles it.»

Un cliente también puede presentar una solicitud, siempre que la plantilla esté liberada para clientes. El interruptor para ello está en la plantilla.

El cliente ve entonces solo su propia solicitud. Los tickets de los equipos especializados le quedan ocultos, aunque su solicitud los haya creado: esos tickets llevan credenciales y notas internas. Sus notas internas tampoco aparecen en el historial de la solicitud. Cuando un equipo especializado cierra su ticket, sus adjuntos se copian a la solicitud con la marca «Internal», y el cliente ni los ve ni los descarga.

Si una solicitud llega por correo, se convierte en un ticket normal. Entonces inicias el flujo después. Para eso está el botón «Start workflow» en la cabecera del ticket.

En el diálogo eliges la plantilla adecuada en «Template». Debajo aparece el mismo recuadro «What is needed?» que en el formulario de ticket nuevo. Marca lo que pide la solicitud.

En «Title» ajustas el título del ticket. Los títulos de las tareas empiezan con él. Debajo encuentras los campos adicionales de la plantilla. Introduce ahí los datos de la solicitud. Los campos obligatorios llevan un asterisco.

Con «Start» las tareas se crean igual que en una solicitud hecha desde el formulario. Si la plantilla necesita una aprobación, el ticket y sus tareas quedan bloqueados hasta que se concede.

En cada ticket solo se puede iniciar un flujo. Después, el botón desaparece. Tampoco aparece en tickets cerrados ni en tickets que son ellos mismos una tarea. Cualquiera que pueda trabajar en el ticket puede iniciarlo.

En la propia solicitud, las tareas se enumeran bajo «Workflow tasks», con el recuento al lado, por ejemplo «1 of 4 done».

Cada fila muestra el nombre de la tarea, el número de su ticket, el equipo y la persona asignada, y el nombre es un enlace a ese ticket.

«Done» sale del estado del ticket, no de una marca aparte. Lo que en la lista de tickets cuenta como cerrado cuenta aquí como hecho; dos formas de contar lo mismo acabarían separándose tarde o temprano.

El bloque solo aparece en una solicitud. Un ticket normal no lo muestra.

Cuando un equipo especializado cierra su ticket, su «Closing comment» llega a la solicitud. Allí aparece como nota interna, y su primera línea indica el número y el nombre de la tarea. El cliente no ve esta nota.

Las credenciales y todo lo que el agente de la solicitud deba transmitir van en el comentario de cierre. Todos los demás comentarios del equipo especializado se quedan en su propio ticket. Si el equipo cierra sin comentario, no se crea ninguna nota.

Una aprobación abarca toda la solicitud, no cada tarea. Ocho aplicaciones son un correo a la persona responsable, no ocho.

Esto se configura en «Approvals», dentro del mismo plan, y la frase de encima enuncia la regla: «One approval covers the whole request. Add a second stage only when single tasks need their own release.» Cada etapa tiene cinco campos: «Name» es el nombre de la etapa, «Covers» dice a qué se aplica, «Decided by» dice de dónde sale quien aprueba, «Approver» contiene a la persona y «Remind after (hours)» fija el recordatorio.

Quien aprueba no necesita cuenta en el sistema de tickets: introduces una dirección de correo y decide mediante un enlace. Un responsable que aprueba dos veces por trimestre no cuesta, por tanto, ningún puesto de agente.

El correo contiene exactamente un enlace a una página. A propósito no hay botones de aprobar o rechazar en el propio correo: un antivirus que abriera todos los enlaces aprobaría.

La página lleva como título el nombre de la etapa. Muestra el número y el título de la solicitud, quién la presenta y, bajo «This decision covers», las tareas a las que se refiere esta decisión, con un campo de comentario y los dos botones debajo.

El enlace no dura eternamente, y la página nombra el plazo: «Please decide by …». Es válido 14 días. Después, la página solo dice que el enlace no es válido o ha caducado, y un administrador vuelve a enviar la solicitud con «Reassign».

Una decisión no se puede retirar, y después la página lo dice: «A decision cannot be changed.»

Algunas tareas necesitan una aprobación propia. El acceso desde fuera no es lo mismo que un portátil.

Para eso añades una segunda etapa y la eliges en la tarea, bajo «Extra approval». Mientras diga «None — the request approval is enough», basta con la aprobación de la solicitud. Ambas etapas se preguntan a la vez, no una detrás de otra. Una etapa solo se pregunta si le afecta alguna de las tareas elegidas. La etapa de toda la solicitud se pregunta siempre.

Una tarea queda liberada cuando todas las etapas que le afectan han dado su conformidad. Una tarea sin etapa propia arranca enseguida, salvo que la etapa de toda la solicitud siga pendiente. Entonces arranca en cuanto se aprueba la solicitud.

Hasta entonces la tarea está bloqueada. Su ticket está en «Waiting for approval» y no tiene persona asignada. En lugar de los botones de estado, la tarjeta dice «This ticket is waiting for approval and cannot be worked on yet.» Antes de eso, ninguna vía le asigna una persona.

El bloqueo vale también para las acciones en lote de la lista de tickets. Si seleccionas ahí un ticket así, lees el motivo: «This ticket is waiting for approval and cannot be worked on yet.»

El ticket se crea igualmente de inmediato, para que el equipo especializado vea lo que viene y nadie tenga que estar pendiente de la solicitud.

Puedes fijar un recordatorio por etapa, indicado en horas.

Si no llega respuesta, pasado ese tiempo vuelve a salir el mismo correo, con el mismo enlace que el primero. Quien haya guardado el primer correo puede seguir usándolo.

Sin recordatorio, la solicitud simplemente espera, sin volver a preguntar.

Lo que no existe es una aprobación por vencimiento. Debajo del campo se dice con todas las letras: «A request is never approved automatically. If nobody reacts, it keeps waiting.» Un plazo que diera su conformidad por sí solo no sería una aprobación, sería un trámite.

Rechazar exige un motivo. Sin texto, la página no acepta el rechazo.

El campo dice adónde va el texto: «Comment (required when you reject — the requester will see it)». Una nota interna no cabe aquí.

Quien solicitó recibe un correo con el motivo y no tiene que preguntar por qué no se mueve nada.

Aprobar no necesita motivo. Es el resultado esperado.

Si rechaza solo una segunda etapa, la negativa afecta únicamente a las tareas de esa etapa. El resto de la solicitud continúa.

Una tarea rechazada recibe el estado «Rejected» y cuenta como terminada, de modo que la solicitud no se queda colgada para siempre de algo que nunca llegará.

En cuanto se rechaza la solicitud, las demás personas que aprueban ya no reciben correos. Su enlace dice entonces «This request has already been rejected. Your decision is no longer needed.» En la lista del ticket, su etapa muestra «No longer needed: the request was rejected.»

En la solicitud, «Approvals» muestra una fila por etapa con quien aprueba, el estado y, en una solicitud abierta, cuánto tiempo lleva esperando.

Tras la decisión, la fila muestra cuándo se tomó y con qué comentario. Eso es la trazabilidad, y se queda con el caso.

Si quien aprueba está de vacaciones, un administrador traslada la solicitud a otra dirección. El botón se llama «Reassign» y solo aparece mientras la solicitud está abierta.

Solo un administrador puede hacerlo. Un agente que pudiera reasignar podría reasignarse a sí mismo y decidir después.

La reasignación crea un enlace nuevo, y el antiguo muere de inmediato, aunque alguien lo hubiera reenviado.

El propio traslado aparece en esa misma lista: quién lo movió, cuándo y de quién a quién.

Nadie puede decidir en nombre de otra persona. El enlace es la única vía, y quién lo recibió queda registrado en el caso.