Plantillas de respuesta y de ticket

Las plantillas viven en «Settings → Templates». La línea que hay bajo el encabezado dice lo que hacen y lo que no: «Reply templates fill the comment editor and suggest field actions. Nothing is sent automatically.» Una plantilla es un movimiento preparado, no una máquina: el envío siempre lo haces tú.

Hay dos tipos y eliges uno al crearla: «Add reply template» para la respuesta en un ticket abierto y «Add ticket template» para el formulario de ticket nuevo. El tipo no se puede cambiar después, porque decide qué campos muestra el formulario. La etiqueta que hay sobre cada plantilla te dice cuál estás mirando: «Reply template» en azul, «Ticket template» en verde.

Una plantilla de respuesta se compone del texto de la respuesta («Reply text»), la casilla «Internal note» y cualquier número de acciones. Hay seis acciones: «Set the status», «Set the priority», «Assign to a user», «Remove the assignee», «Hand over to another team» y «Set a follow-up».

La lista de «Assign to a user» empieza con la entrada «The agent who applies it». Elige esa cuando varias personas compartan la plantilla: el ticket pertenece entonces a quien la aplicó y no a una persona fija de la lista. «Set a follow-up» pide una cantidad y una unidad (minutos, horas, días, minutos laborables, horas laborables, días laborables) y la nota que después te dirá por qué ha vuelto el ticket.

El recuadro azul del final de cada plantilla escribe en una frase lo que hará, por ejemplo «Inserts the text as a public comment, sets status to Waiting for Service Provider Response, assigns to the applying agent, sets a follow-up in 3 days.» La frase se reconstruye mientras editas. Es tu contraprueba: si dice algo distinto de lo que pretendías, hay un ajuste mal.

El texto no es obligatorio. «Pasa esto al equipo de red sin escribir una palabra» es una plantilla válida; la frase dice entonces «Suggests actions without a reply text». La acción «Set the status» sigue las mismas reglas que un cambio de estado a mano. Aplicada a varios tickets a la vez, la plantilla omite los tickets bloqueados e indica el motivo.

La ventana «Close ticket» también ofrece plantillas de respuesta, en el campo «Template». Solo muestra las plantillas cuya acción activa «Set the status» fija un estado que cuenta como resuelto o cerrado. Las plantillas internas no se ofrecen ahí. Si eliges una, la ventana adopta su texto como comentario. Si la plantilla envía un correo y la ventana ofrece el envío de correo, solo adopta el destinatario si es «Requester» o una dirección fija. Las demás acciones de la plantilla no se ejecutan ahí, y sus adjuntos no se añaden. El ticket se cierra como de costumbre.

En un ticket abierto, el botón «Template» está encima del editor de comentarios. Un clic abre la búsqueda con sugerencias («Search templates…») y, al elegir una, se rellena el editor de comentarios. No ocurre nada más, y la línea de debajo lo dice: «Nothing happens until you add the comment.»

Cada acción de la plantilla se convierte en una etiqueta junto al botón, en lenguaje llano y no en jerga: «sets status to Waiting for Service Provider Response», «assigns to the applying agent», «sets a follow-up in 3 days». Al pulsar una etiqueta queda tachada: se descarta y no se ejecutará. Otro clic la devuelve.

Las acciones descartadas quedan tachadas, no eliminadas. Así sigue viéndose lo que la plantilla habría propuesto, y la decisión sigue siendo reversible mientras no hayas enviado.

Qué etiquetas empiezan activas lo decide la plantilla: en los ajustes, cada acción lleva un interruptor «Suggested». Ese interruptor es la propuesta para todos los casos; la etiqueta del ticket es la decisión para este.

La «×» que hay tras las etiquetas retira de nuevo la plantilla. El texto se queda en el editor, porque es probable que ya lo hayas reescrito; solo desaparece el efecto, es decir, las acciones, el correo y los adjuntos.

Envías con el botón de comentario de siempre. Solo entonces se crea el comentario, y solo después se ejecutan las acciones que sigan activas.

El texto de la respuesta puede usar cinco marcadores; la lista está debajo del campo: «{requesterName}, {ticketId}, {ticketTitle}, {ticketRef}, {agentName}». Escríbelos entre llaves, exactamente como aparecen ahí.

«{ticketRef}» es la referencia del ticket con la forma «[TICKET-8-…]». Es por lo que el sistema reconoce la respuesta de un cliente cuando vuelve por correo. «{ticketId}», en cambio, es solo el número pelado.

Se resuelven al APLICAR la plantilla, no al guardarla: la página de ajustes sigue mostrando «{requesterName}» y el editor de comentarios del ticket muestra el nombre real. El motivo es práctico: resolverlos al guardar grabaría para siempre en la plantilla los valores de UN ticket.

Así lees el texto terminado antes de que nada salga de la empresa. Si el saludo no encaja, lo cambias en el editor como cualquier otro texto.

Quién cuenta como «quien solicita» lo decide el ticket, no la cuenta: la persona registrada en el ticket va por delante de la cuenta que lo presentó. Si un agente presenta un ticket para un compañero tras una llamada, la respuesta saluda igualmente al compañero y no al agente.

Un marcador mal escrito se rechaza al guardar, y se nombra: «Reply text: unknown placeholders {requesterNam}. Available here: {requesterName}, {ticketId}, {ticketTitle}, {ticketRef}, {agentName}.» Así lo notas mientras escribes la plantilla y no con un cliente.

El asunto del correo tiene su PROPIA lista, más corta («{originalSubject}, {ticketTag}, {ticketId}»), y por eso se imprime allí una segunda vez. «{ticketRef}» también funciona ahí y significa lo mismo que «{ticketTag}». «{requesterName}», «{ticketTitle}» y «{agentName}» no funcionan en el asunto y se rechazan igualmente.

El interruptor «Send the comment as e-mail» convierte el comentario también en el correo. A propósito no hay un segundo campo de texto para ello: lo que está en el ticket es lo que lee el cliente, porque dos textos acabarían separándose.

En «Recipient» eliges entre «Requester», «Assignee», «Observers» y «Fixed address». Quién es quien solicita lo resuelve el servidor al aplicar la plantilla, porque una plantilla todavía no conoce el ticket. A la propia cuenta del buzón de entrada no se le escribe nunca; sería un mensaje a nosotros mismos. Si el campo «User» contiene un nombre sin dirección, no sale ningún correo a quien solicita. Tampoco se envía en su lugar a quien registró el ticket.

El asunto puede llevar «{originalSubject}», «{ticketTag}» y «{ticketId}». Mantén ahí «{ticketTag}»: esa referencia es por la que el sistema reconoce la respuesta del cliente y la añade al mismo ticket. Sin ella, cada respuesta se convierte en un ticket nuevo.

El correo sale como texto sin formato. La negrita, las listas y los enlaces se eliminan antes del envío; de lo contrario, el cliente leería el marcado en bruto. Dentro del ticket, el comentario conserva su formato.

En el ticket, el correo es una etiqueta más junto a las acciones («E-mail to Requester») y se puede descartar igual que ellas. Así, una plantilla nunca envía nada sin que lo hayas visto. La etiqueta solo aparece cuando el buzón del equipo envía correos en las acciones de ticket.

Los adjuntos de una plantilla («Attachments») son copias propias de los archivos. Al aplicar la plantilla se añaden al TICKET, con su propia fila en el historial; no forman parte del correo. Llevar adjuntos en una plantilla no necesita licencia Professional; enviarlos sí. Una plantilla con la marca «Internal note» no añade archivos.

La mayoría de las plantillas no nacen en un tablero de diseño, sino en el momento en que escribes la misma respuesta por segunda vez. Por eso, cada comentario de un ticket lleva a la derecha un pequeño icono de hoja con el nombre «Make template». Toma exactamente ese comentario como texto de partida, también el comentario de un compañero. Solo quien puede gestionar plantillas ve el icono.

Si el ticket tiene adjuntos, un diálogo pregunta primero cuáles deben acompañarla: «Tick only the attachments the template should carry — one of them may be a customer's screenshot. Nothing is ticked by default.» No hay nada marcado de antemano, y es a propósito.

Después llegas a la página de plantillas con un borrador que todavía NO está guardado. Arriba está la banda ámbar «Draft from ticket #… — name it and review the text (it may contain customer details), then save.» El nombre está vacío: tienes que ponerle uno, si no, no se guarda.

Lo que se traslada: el texto, la casilla «Internal note», el equipo del ticket y el estado del ticket como propuesta, con su estado y su prioridad ya puestos como dos acciones. Lo que no se traslada: quien solicita, la dirección y el título. Eso pertenece a ese caso concreto.

Lee el texto antes de guardar. Procede de un caso real y puede contener el nombre de una persona, un número de pedido o una sala. Nada se anonimiza por ti; la banda lo dice, pero hacerlo es cosa tuya.

Solo «Save» crea la plantilla; los adjuntos marcados se copian entonces y se confirma con un mensaje.

«Applies to» decide a quién se le ofrece la plantilla: a un equipo concreto o a «All teams». Una plantilla nueva empieza con un equipo concreto; «All teams» es una elección que alguien tiene que hacer, no un valor silencioso de fábrica.

En un ticket se te ofrecen las plantillas del equipo responsable más las globales. Si el ticket pasa a otro equipo tras un traspaso, la lista se mueve con él: puedes elegir entre las plantillas del nuevo equipo.

El interruptor «Draft» convierte la plantilla en tu taller: «Only you can see this template until you publish it.» El borrador de otra persona no aparece en ninguna lista y tampoco se alcanza por su dirección, ni siquiera para los administradores. Una plantilla nueva empieza como borrador; solo cuando lo desactivas y guardas la ven los demás.

Dos plantillas no pueden compartir nombre si pueden coincidir: una global choca con cualquier plantilla del mismo nombre, en cualquier equipo. Una plantilla de respuesta y una de ticket sí pueden compartir nombre, porque nunca aparecen juntas en la misma lista.

«Duplicate» hace una copia, y la copia es siempre un borrador: «Duplicated. The copy is a draft only you can see.» Es la vía cómoda hacia una variante sin que a nadie se le ofrezca la versión a medio terminar.

Una plantilla de ticket rellena el formulario «Create new ticket». No tiene texto de respuesta, ni acciones, ni correo: en ese momento no existe ningún ticket sobre el que actuar. Por eso el formulario muestra campos distintos que en una plantilla de respuesta, y el marco verde te dice que estás viendo una plantilla de ticket.

Puedes rellenar de antemano «Ticket title», «Owning team of the new ticket», «Main category», «Subcategory», «Priority» y la «Ticket description». Cualquier campo puede quedarse en «Not prefilled»; lo que quede vacío lo rellenará después quien use el formulario.

Fíjate en la diferencia entre los dos campos de equipo: «Applies to», arriba, dice QUIÉN ve la plantilla. «Owning team of the new ticket» dice ADÓNDE va el ticket nuevo. Son dos preguntas distintas y pueden tener respuestas distintas.

Las categorías están agrupadas por equipo, porque una categoría pertenece a un equipo. Si eliges una de otro equipo, el formulario te avisa y se rechaza el guardado: en el formulario de ticket nuevo del equipo de destino, esa categoría no se ofrecería siquiera, así que el relleno previo quedaría en nada.

Aquí no hay marcadores, y la indicación de debajo del texto lo dice: «No placeholders here: the template only prefills the form, nothing is resolved or sent.» Un «{requesterName}» acabaría literalmente en el ticket nuevo, y por eso se rechaza al guardar.

El recuadro azul resume también aquí lo que hace la plantilla: «Prefills the new ticket with title 'New notebook for a colleague' · category Notebook / New request · priority Medium · team Helpdesk · the description.»

En el propio formulario eliges la plantilla con el botón «Template»; al lado dice «Prefills the form - nothing is created until you submit.» Todo lo rellenado de antemano se puede seguir cambiando, y no se crea nada hasta que envías.

El sistema trae una plantilla de ejemplo: «Example: create accounts for a new colleague». Muestra la forma del asunto y por sí sola no hace nada; recréala a tu gusto o bórrala.

El interruptor «Offer this template to customers» está desactivado de fábrica. La indicación de al lado dice las dos cosas que necesitas saber: «Customers can pick this template when they create a ticket. A draft stays hidden either way.»

Por qué está desactivado de fábrica: una plantilla suele llevar nombre en vocabulario interno y estar escrita para compañeros. Hacerla visible a los clientes es una declaración hacia fuera, y alguien debería hacerlo a propósito y no por accidente.

El cliente ve el mismo botón «Template» encima del formulario de ticket nuevo, pero solo las plantillas liberadas. Un borrador sigue oculto incluso con el interruptor activado: las dos reglas están una detrás de otra, no una al lado de otra.

Lo importante no es la comodidad, sino el primer contacto: una solicitud que llega completa ahorra la ronda de preguntas que si no costaría dos días. Pon esas preguntas en la descripción de la plantilla; el cliente las responde mientras crea el ticket.

Puedes ir más allá con «Fields to ask for». La plantilla decide entonces qué campos personalizados pide el formulario, en qué orden y cuáles de ellos son obligatorios. Esa selección SUSTITUYE a los campos habituales del equipo, no se suma a ellos. Ese es justo su propósito. Los campos personalizados en sí forman parte de Professional; su tarjeta se llama «Campos personalizados». Liberar una plantilla a los clientes funciona en todas las ediciones.

Un campo oculto a los clientes sigue oculto aunque una plantilla lo enumere. La selección de campos es una herramienta de orden y de recorte, no una vía para saltarse los ajustes de los campos.

Cada uso que hace algo más que insertar texto escribe UNA entrada en el historial, bajo el nombre de campo «Template». Nombra la plantilla. Las acciones ejecutadas escriben sus propias filas. Sin ella no habría forma de explicar después por qué un ticket saltó de repente a «In Progress»: las acciones concretas sí escriben sus propias filas, pero ninguna nombra la plantilla.

En la imagen se lee: «Template ‘First reply: we have your ticket’ applied». Lo que hizo la plantilla está en las filas de sus propias acciones, como el cambio de estado.

Las acciones descartadas no aparecen: no ocurrieron. Un fallo sí aparece, y se nombra como tal, detrás de la palabra «failed». Una plantilla de solo texto, sin acciones, correo ni adjuntos, no deja ninguna entrada «Template» en un ticket individual. Solo ha insertado texto. Aplicada a varios tickets a la vez, la entrada se escribe siempre, junto con la fila interna «Bulk».

La entrada es INTERNA: quien solicita no la ve. El nombre de una plantilla es vocabulario interno («rechazo estándar»), y el historial está abierto también a quien creó el ticket. Los cambios de campo en sí siguen siendo visibles para esa persona; solo su origen en una plantilla no lo es.

El autor es el agente, no «system» ni la plantilla. Es a propósito: aplicarla fue su decisión. A diferencia de una regla de automatización, lo que consta en el ticket aquí es una persona.