Gestión de tickets

Un ticket nuevo se crea con «New Ticket» en la barra de la izquierda. El formulario se llama «Create new ticket». Como agente también registras con él las solicitudes de otras personas: para eso está el campo «User», que dice para quién es el caso y no quién lo teclea.

Todo lo que lleva un asterisco es obligatorio: «Title», «User», «Main category» y «Description». Hay uno más que es fácil pasar por alto: el formulario no se guarda sin una subcategoría, aunque «Subcategory» no lleve asterisco; una categoría principal y una subcategoría van juntas y se definen siempre en pareja.

Qué campos son obligatorios se define en «Settings → Ticket Settings». La tarjeta «Admin / Agent Field Settings» solo tiene para ello el interruptor «Field is mandatory». La tarjeta «Customer Field Settings» tiene además «Is hidden for Customer» e «Is not editable». Por eso un cliente puede ver un formulario más corto que el tuyo sin que nadie tenga que mantener dos formularios. «Title» y «Description» son siempre obligatorios. Eso no se puede desactivar.

Después puedes cambiar casi todo: a la derecha del ticket está la tarjeta «Details» con la persona que solicita, el teléfono, el correo, la sede, la categoría y el número de referencia; cambias el campo y confirmas con el «Save» de debajo. El estado, la asignación, la prioridad, el canal y los observadores están una tarjeta más arriba, en «Actions». El estado y la asignación surten efecto de inmediato. La prioridad, el canal y los observadores solo se guardan con el «Save» de la tarjeta «Details».

Solo los agentes y los administradores pueden cambiar esto. Quien solicita puede leer el caso, comentarlo y adjuntar archivos, pero no cambiar la clasificación sobre la que se construyen tus informes.

Un efecto secundario que conviene conocer una vez: si editas un ticket que todavía no es de nadie, después es tuyo. El sistema te anota como agente y mueve el estado de «Open» a «Assigned», y ambas cosas quedan en el historial. Si no querías eso, asígnalo después a otra persona.

Cada uno de estos cambios queda en el historial del ticket, con nombre, hora, valor anterior y valor nuevo. Para eso no hay que activar nada.

Queda la pregunta de cómo deshacerse de los tickets. En «Settings → Archive» eliges un periodo, ves con «Preview» cuántos tickets cerrados contiene y creas un archivo ZIP con «Create archive»: tickets, comentarios, historial, campos personalizados y adjuntos, todo en un solo archivo. Crearlo no elimina nada. Los tickets solo salen de la base de datos en marcha con el paso aparte «Delete from live DB» en la lista «Existing archives», y desde ese mismo archivo se pueden restaurar.

La descripción y los comentarios no son simples cajas de texto. Cada una tiene encima una barra de herramientas, y los botones dicen lo que hacen cuando apuntas a ellos: «Bold», «Italic», «Underline», «Strikethrough», «Text color», «Highlight color», «Bullet list», «Numbered list», «Quote», «Link» y «Clear formatting».

Así se crea un enlace: selecciona el texto, pulsa «Link» y escribe la dirección en la pequeña ventana. Una entrada vacía elimina de nuevo el enlace. Se admiten direcciones web y de correo (http, https, mailto); todo lo demás se descarta al guardar, de modo que un comentario no pueda colar nada a nadie.

Las imágenes entran por el portapapeles: haz una captura y pégala directamente en el editor con Ctrl+V. Al principio, el texto solo muestra una marca como «[inline-image:1]». Al guardar, el sistema sube la imagen y la muestra exactamente ahí, y además llega a la pestaña «Attachments», donde viven todos los archivos del caso. Pegar imágenes funciona en la descripción de un ticket existente y en un comentario nuevo. No funciona en el formulario «Create new ticket» ni mientras editas un comentario.

Lo que ves es lo que ven los demás: el formato, las listas y los enlaces se conservan en el ticket, y también en el correo a quien solicita. El marcado ajeno, por ejemplo de una página web copiada o de un correo entrante, se recorta a este conjunto permitido. Con ello no se pierde nada de tu texto, solo el envoltorio.

Un comentario puede marcarse como interno con «Internal note (not visible to the customer)». Lleva entonces la marca «Internal» y es invisible para quien solicita; ni siquiera la búsqueda lo saca a la luz.

Cada uno puede cambiar y borrar sus propios comentarios. Lo que escribió un cliente solo puede cambiarlo o borrarlo ese cliente o un administrador. Eso incluye sus correos. Los comentarios de compañeros los puede cambiar y borrar cualquier agente que pueda trabajar en el ticket. Eso incluye a un equipo que tuvo el ticket antes.

Los archivos pertenecen al caso, no a un comentario concreto. En el ticket, la pestaña «Attachments» lleva a la lista: «Upload file» añade uno, y cada fila nombra el archivo, su tamaño y su fecha. Cualquier persona implicada en el ticket puede adjuntar algo, también quien solicita; así nadie tiene que enviarte su captura por correo. Un cliente solo puede borrar los adjuntos que haya subido él mismo. Cuando se cierra un subticket, sus adjuntos se copian al ticket principal, donde llevan la marca «Internal». Los agentes los ven; los clientes ni los ven ni los descargan.

Un clic en el nombre abre la vista previa sin que tengas que descargar el archivo. En las imágenes puedes acercar, alejar y girar ahí mismo, algo útil para una pantalla fotografiada de lado. Un PDF se muestra en la misma ventana, con vista de páginas, zoom e impresión. Los archivos de texto se muestran como texto. Con «Open in new tab» abres el archivo en una ventana propia.

Un adjunto pertenece al caso y viaja con él: aparece en el historial («File uploaded: …»), sobrevive a un traspaso a otro equipo y acaba dentro del archivo comprimido cuando el ticket se archiva.

La pestaña «History» del ticket responde a la pregunta que hay detrás de cada seguimiento: ¿quién cambió qué y cuándo? Cada fila nombra a la persona, el campo, el valor anterior tachado, el nuevo detrás y la hora al segundo. La entrada más reciente está arriba.

Las entradas se escriben sin que hagas nada: en los cambios de estado, prioridad, asignación, categoría, sede, observadores, título y descripción, así como en la creación («Ticket opened»), en cada comentario y en cada archivo subido. El número de la pestaña te dice de antemano cuánto movimiento tuvo el caso.

El historial no se puede editar ni desactivar. Precisamente eso es lo que lo hace útil: es la razón por la que un ticket no se puede borrar uno a uno, y viaja al archivo comprimido cuando el ticket se archiva.

De un comentario, el historial solo registra que se añadió, editó o eliminó. El texto está en la pestaña «Comments». Un comentario interno también aparece en el historial, pero solo para agentes y administradores.

El estado dice en qué punto está un ticket ahora mismo. El sistema trae doce estados: Open, Assigned, In Progress, Waiting for User Response, Resolved, Closed y algunos más. Los encuentras en «Settings → General Settings», en la sección «Drop-down lists», detrás de la pestaña «Status»; «+ Add status» crea uno propio y «Edit status» abre uno existente.

Lo importante es la diferencia entre el nombre y el significado. En el editor de un estado, bajo «Meaning of this status», hay tres interruptores: «Counts as resolved», «Counts as closed» y «Waiting for the requester». Solo estos interruptores le dicen al sistema cómo tratar un estado.

Puedes renombrar cualquier estado, también los que trae el sistema: al final del editor, en «Translations», hay un campo «Name» por idioma; pon ahí lo que deba leer tu gente. El nombre técnico que hay detrás queda intacto, y justo por eso no se rompe nada: la automatización, los informes y los interruptores de arriba cuelgan de ese nombre y no de tu etiqueta. Así, «Resolved» puede convertirse en «Hecho».

Borrar, en cambio, no funciona con todos. Ocho estados llevan la marca «Mandatory» en la lista: Open, Assigned, In Progress, Resolved, Closed, Reopened, Waiting for approval y Rejected. Se pueden renombrar y reordenar, pero no eliminar; intentarlo termina con un mensaje claro. Eso no está para fastidiarte: de ellos cuelgan procesos que si no dejarían de funcionar sin decir nada, por ejemplo el cierre automático, que necesita un estado «resuelto» como punto de partida.

Dos estados pertenecen al propio sistema: «Waiting for approval» y «Rejected» llevan la marca «System only». Salen de un proceso de aprobación, y nadie debería poder afirmar a mano que se ha rechazado algo que nunca se sometió a decisión.

Lo que hacen los tres: un estado que cuenta como resuelto cierra el ticket por sí solo al cabo de 24 horas. Un estado que cuenta como cerrado es el estado final al que se lleva el ticket. Y «Waiting for the requester» significa exactamente eso: esperamos a quien solicitó, no a otro equipo ni a un proveedor. Esa es la marca en la que se detiene el reloj del SLA, si lo configuras así.

Debajo está «Allowed transitions to new status». Aquí marcas qué estados se pueden alcanzar desde este. Si lo dejas todo vacío, no hay restricción; si marcas algo, todos los demás caminos quedan cerrados. Así construyes un flujo que no se puede saltar: por ejemplo, desde «Open» solo se puede ir a «In Progress» o a «Assigned», pero no directamente a «Closed».

Los interruptores restantes del editor son detalles con un gran efecto: el color para la lista, «Sort order» para el orden, «Show status in new ticket form» (¿debe poder elegirse este estado al crear un ticket?), «Requires comment in dialog» (obligar a dar un motivo) y «System only» para los estados que solo puede fijar el propio sistema.

Hasta cuatro estados aparecen en el ticket como botones bajo «Change Status to:». Los eliges en el editor con el interruptor «Set as primary status (max. 4)». Con el ajuste de fábrica son In Progress, Waiting for User Response, Waiting for Service Provider Response y Resolved. Todos los demás estados están en «More statuses».

Todo lo que aparece como lista desplegable en un ticket es tuyo. En «Settings → General Settings» está la tarjeta «Drop-down lists» con seis pestañas: «Department», «Position», «Location», «Role», «Status» y «Priority». El manejo cambia de una lista a otra.

Una a una: escribe el nombre en inglés en el campo vacío y pulsa el botón de al lado, que lleva el nombre de la lista, como «+ Add location» o «+ Add department». Las filas de debajo son las entradas existentes. En «Department», «Position» y «Location», ahí es donde cambias un nombre y lo confirmas con el «Save» de al lado.

Para muchas entradas de una vez, «Department», «Position» y «Location» ofrecen además «Export JSON» e «Import JSON». En un sistema recién instalado descargas la estructura vacía con «Export JSON», la rellenas y la vuelves a importar. No es una vía para renombrar: la propia tarjeta lo dice.

Algunas entradas llevan la marca «Mandatory». Entre ellas están los tres roles «Admin», «Agent» y «Customer», ocho de los estados que trae el sistema y un marcador de posición en las listas de sede, puesto y departamento («None selected or available»). Ninguna de ellas se puede borrar: de ellas cuelgan permisos y procesos que si no dejarían de funcionar sin decir nada. Los estados sí se pueden renombrar en su editor. Los roles y los marcadores de posición no se pueden renombrar. Lo que está permitido depende de la lista. «Role» está bloqueada: no se puede añadir ni renombrar ningún rol. En «Priority» añades y borras entradas, pero no hay archivo ni se puede renombrar. «Status» tiene su propio editor y tampoco tiene archivo.

Aquí no traduces a los demás idiomas: eso se hace de una vez en la página de traducciones. Aquí basta con el nombre en inglés, que es el ancla a la que se enganchan después las traducciones.

El estado es la única entrada con un editor propio, porque de él cuelga más que un nombre; tiene su propia tarjeta más abajo.

Las categorías son lo que elige quien solicita o el agente al crear un ticket, y aquello por lo que después agrupas tus informes. Cada equipo tiene las suyas: un helpdesk clasifica por cosas distintas que un departamento de redes, y ninguno ve las listas del otro equipo.

Las encuentras en «Settings», en la entrada «<nombre del equipo> Categories». En el ejemplo, el equipo se llama «Helpdesk», así que la entrada dice «Helpdesk Categories».

La página tiene tres tarjetas: «Main categories», «Subcategories» y «Links». El arranque más rápido: escribe el nombre en inglés en el campo «EN (required)» y pulsa «+ New main category» o «+ New subcategory». Todo lo demás lo traduces después de una vez en la página de traducciones; para eso no hay que preparar nada aquí.

Si tienes muchas categorías por delante, usa la vía del archivo: «Export JSON» descarga la estructura y, en un sistema recién instalado, el archivo está vacío y solo te muestra la disposición. Lo rellenas (a mano o con ayuda de una IA), lo guardas y lo vuelves a subir con «Import JSON». No es una vía para renombrar: un nombre se cambia en el campo de esa categoría y se confirma con el «Save» de al lado, tal y como indica la propia página.

La tercera tarjeta, «Links», es donde ocurre el trabajo de verdad. Elige arriba una categoría principal, marca debajo las subcategorías que le pertenecen y guarda con «Save links». El truco: una subcategoría puede colgar de varias categorías principales. Así solo necesitas «Avería» una vez y la reutilizas para impresora, red, sala de reuniones y portátil.

A partir de ahí, las categorías están disponibles en el ticket. Borrar puede fallar mientras haya tickets que usen una categoría; es a propósito, porque si no, los tickets antiguos perderían su clasificación. Si quitas una vinculación, los tickets que usan ese par se pueden seguir guardando. Solo una categoría elegida de nuevo se comprueba contra las vinculaciones.

Si pasas un ticket a otro equipo, su clasificación se mantiene, incluso cuando el nuevo equipo no tiene esas categorías. Queda entonces en el campo junto con su origen, por ejemplo «Meeting-Room · from Helpdesk», y aparece atenuada: el nuevo equipo puede ver bajo qué clasificación iba el caso hasta ahora, pero no puede asignar esa entrada por su cuenta. Para reclasificarlo se elige de la propia lista, y el sistema pedirá entonces una categoría principal y una subcategoría juntas.

Cada ticket lleva un canal. Está en el formulario y después en la tarjeta «Actions», bajo «How the request came in», y responde a una pregunta que en los informes se vuelve importante enseguida: ¿el trabajo llega por el portal o por teléfono?

Solo puedes elegir lo que sabe una persona y no sabe el sistema: «Phone» y «Entered by an agent». Los otros dos valores los pone el propio sistema: «Self-service» cuando quien solicita creó el ticket en el portal, y «E-mail» cuando nació de un correo entrante. Cuando un agente crea un ticket, el formulario empieza con «Entered by an agent».

Un canal que ha puesto el sistema no lo puede cambiar nadie después. El campo dice entonces: «Recorded by the system. It cannot be changed.» Si no, el campo perdería justo la afirmación por la que existe. Al revés, en un ticket registrado por teléfono sí puedes cambiar todo lo demás.

Solo un agente o un administrador puede fijar el canal. Para quien solicita sería una afirmación sobre su propio caso, y los informes dependerían de que todo el mundo fuera sincero.

«E-mail» requiere un buzón conectado, que forma parte de la edición Professional. Los otros tres canales existen en ambas ediciones.

Encima de cada lista de tickets está el campo «Search tickets…». No busca solo en los títulos, sino en todo el caso: título, descripción, nombre de quien solicita, dirección de correo y teléfono, sede, número de ticket de referencia, todos los comentarios y los valores de texto de tus propios campos personalizados.

El ejemplo lo muestra: «coffee» no aparece en ningún título, solo en la descripción de un ticket, y aun así se encuentra. Así que no tienes que recordar cómo se tituló un ticket; basta con una palabra del caso.

Las mayúsculas y minúsculas dan igual. La búsqueda se aplica siempre a la lista en la que estás y puede combinarse con «Filter», que está al lado; «Reset» borra de nuevo la búsqueda y los filtros. La lista recuerda tus filtros, por separado para cada lista de equipo. Siguen puestos cuando vuelves de un ticket, recargas la página o inicias sesión en otro ordenador. El texto de búsqueda no lo recuerda. Para los clientes hay un límite que no se ve pero conviene conocer: no buscan en los comentarios internos, porque si no podrían deducir de la lista de resultados lo que se ha hablado internamente. Tampoco buscan en los campos personalizados ocultos para los clientes.

Cada persona compone su propia lista de tickets. Para ello, el botón «Columns» está junto a «Filter». Abre el diálogo «Choose columns».

En el diálogo marcas cada columna que quieres ver. Las flechas de al lado fijan el orden. «#» y «Title» siempre están incluidas. El ancho de una columna lo cambias en la propia lista, arrastrando el borde de su encabezado.

«Save» guarda tu elección con tu cuenta de usuario. Por eso se aplica en cualquier ordenador y se mantiene después de cerrar sesión. «Default columns» devuelve la lista a su ajuste de fábrica.

Cuando no hay sitio para todas las columnas, las que están más a la derecha desaparecen primero. «#», «Title» y «Status» se quedan siempre. Por eso pones delante lo que más te importa.

Con Professional también se ofrecen tus campos personalizados. Aparecen en el diálogo con su propio nombre, aquí por ejemplo «Asset tag».

Los clientes pueden configurar su lista de la misma manera, pero se les ofrecen menos columnas. «Team», «Created by», «Last activity», «Status changed at», «Deadline», «Follow-up» y «Time» no están disponibles para ellos. Los campos que has ocultado a los clientes tampoco aparecen como columna.

En un móvil el botón no se muestra. Allí la lista muestra las columnas que caben.

Para esto, el ticket ofrece dos botones uno junto al otro, y la diferencia está impresa debajo en letra pequeña. «Involve another team»: tú sigues siendo el responsable y el otro equipo trabaja a tu lado en un ticket enlazado. «Escalate to another team»: el otro equipo se hace cargo.

Cuando traspasas, la responsabilidad cambia de manos sin que nazca un segundo ticket. Tu equipo conserva el acceso de lectura y puede seguir comentando, pero ya no puede cambiar nada, que es exactamente lo que te dice el diálogo antes de confirmar. Ahí eliges el equipo de destino y puedes añadir un motivo.

Cuando involucras a un equipo, tu ticket se queda en tus manos y recibe un subticket en el otro equipo. El tuyo pasa al estado «Waiting for other team»; cuando el otro equipo cierra el suyo, el tuyo vuelve como «Back from other team». Así no tienes que preguntar si ha pasado algo por allí. Los adjuntos del subticket se copian a tu ticket con la marca «Internal», y el cliente no los ve.

En cuanto a la clasificación: las categorías del equipo que traspasa se quedan en el ticket, incluso cuando el nuevo equipo no las tiene; aparecen allí con su origen y atenuadas. Así el nuevo equipo puede ver bajo qué clasificación iba el caso y, si hace falta, reclasificarlo en su propia lista.

Solo quien sea responsable en ese momento puede pasar un ticket. Una estación anterior sigue viendo el caso, pero no puede volver a pasarlo. Puede comentar, pero no puede volver a quedarse con el ticket.

En la lista de tu equipo, el ticket muestra entonces «Waiting for other team» mientras el otro equipo trabaja en él. La casilla «Also show tickets this team handed over» viene marcada de fábrica, y se guarda la elección propia de cada usuario. Para el otro equipo, el ticket empieza como «Open».

Quien traspasa un ticket se convierte en su observador. El diálogo lo dice antes de que confirmes. Como observador recibes un correo cuando cambia el estado, se cierra el ticket o alguien comenta. Como cualquier observador, te quitas con «Stop observing».

Cuando a tus tickets les falta un dato —el número de inventario, el fin de la garantía, el centro de coste— lo añades tú. En «Settings → Ticket Settings», al final, está la tarjeta «Custom fields»; el botón se llama «Add custom field».

En el diálogo pones un nombre y un tipo de campo: «Text», «Multiline text», «Integer», «Decimal», «Date» o «Yes / No». El tipo decide qué se puede introducir: un campo de fecha no acepta «la semana que viene», y justo por eso después puedes hacer informes con él.

En «Scope» decides dónde se aplica el campo: «All teams (including new ones)» o «Selected teams only». La primera opción abarca también equipos que todavía no existen, del tipo de diferencia que solo se nota medio año después.

Los tres interruptores de «Defaults» son «Mandatory by default», «Hidden for customer by default» y «Not editable by customer by default». Solo se aplican a un campo mientras no se haya guardado nada para ese campo en los ajustes del campo de esa misma página. En cuanto lo defines ahí, deciden los ajustes del campo.

En el ticket, los campos personalizados están en una tarjeta propia, «Additional information», entre la descripción y los comentarios. Sin plantilla, el formulario muestra todos los campos personalizados del equipo. Si al crear un ticket eliges una plantilla, muestra exactamente los campos que esa plantilla enumera, en su orden: «solo los campos que necesita este caso».

Una plantilla puede además hacer obligatorio un campo. Lo que el administrador ocultó a los clientes sigue oculto, aunque una plantilla lo incluya. Un campo obligatorio que una plantilla no incluye no se pide, así que esa exigencia no se aplica a los tickets creados con esa plantilla.

Cuántos campos personalizados puede tener un equipo se define en «Settings → General Settings», en la tarjeta «Custom fields limit». De un campo te deshaces con «Deactivate»: desaparece del formulario, pero sus valores se quedan en los tickets antiguos; el interruptor «Show deactivated» lo devuelve a la lista.

A veces alguien debe seguir un caso sin trabajar en él: el responsable del equipo en un asunto delicado, el compañero que se hará cargo la semana que viene. Para eso están los observadores. En el ticket, el campo «Observers» está en la tarjeta «Actions» y el botón se llama «Add observer»; el formulario «Create new ticket» tiene el mismo campo. En el ticket, un cambio ahí se guarda con el «Save» de la tarjeta «Details».

Solo se puede elegir a agentes y administradores del equipo al que pertenece el ticket. Un cliente no puede ser observador, porque si no recibiría correo sobre el trabajo interno.

Un observador recibe un correo cuando pasa algo en el ticket: un comentario nuevo, un cambio de estado, una nueva asignación, campos modificados. No se envía de inmediato, sino agrupado: tras el último cambio, el sistema espera un minuto y envía UN correo con todo lo ocurrido en ese tiempo. Así, trabajar un ticket de una sentada no dispara siete correos. Si en ese tiempo llegan varios comentarios, todos van en el correo.

Quién observa forma parte del historial: un cambio queda registrado como cualquier otro, con el estado anterior y el nuevo.

Introducir observadores forma parte de Basic. El correo a los observadores forma parte de Professional, porque necesita el envío de correo. Sin él puedes introducir observadores, pero no sale nada. Un observador puede quitarse a sí mismo con el botón «Stop observing». Para eso no necesita permiso para cambiar el ticket.

Un observador también se añade automáticamente: quien pasa un ticket con «Escalate to another team» se convierte en observador. Así se entera de lo que el otro equipo hace con él.

Cuando dos personas trabajan en el mismo ticket al mismo tiempo, el guardado posterior podría sobrescribir el anterior, y nadie lo notaría. Por eso el ticket muestra quién más lo tiene abierto. Además, rechaza un guardado que se basa en una versión desactualizada.

El aviso está en la cabecera del ticket. «Marco Rossi is viewing this ticket» significa que Marco tiene el ticket abierto. «Marco Rossi is actively editing this ticket» significa que Marco tiene datos sin guardar en él. Puede ser una respuesta empezada, un comentario que se está cambiando, el título o la descripción en modo de edición, un seguimiento, un campo personalizado o un registro de tiempo. También cuentan los campos cambiados en las tarjetas «Actions» y «Details», mientras no se hayan guardado con «Save». Una ventana abierta en el ticket también cuenta. Son las ventanas «Involve another team?», «Escalate to another team?», «Close ticket», «Resolve incident» y «Start a workflow», además de la ventana para el comentario de un cambio de estado. Tras dos minutos sin escribir nada, el aviso vuelve a mostrar «viewing», aunque el borrador siga ahí.

Si varios compañeros tienen el ticket abierto, el aviso los resume, por ejemplo «Marco Rossi and 2 more are viewing this ticket». Señala el aviso para ver todos los nombres. En cuanto alguien edita activamente, la línea solo cuenta a las personas que están editando. A ti mismo no te ves nunca. Si tienes el ticket abierto en dos pestañas, cuentas una sola vez. Si el ticket solo está abierto en una pestaña oculta, desapareces del aviso de los demás tras aproximadamente un minuto.

Cuando un compañero guarda un cambio, el aviso dice «Marco Rossi changed this ticket», con el botón «Refresh» al lado. Un comentario nuevo de otra persona muestra «Marco Rossi added a comment». Si el cambio no lo hizo ninguna persona, por ejemplo una regla de automatización o un correo entrante, el aviso dice «This ticket was changed». El aviso se mantiene hasta que recargas.

«Refresh» carga la versión actual del ticket, como el estado, la asignación, los campos y el historial. No recarga la página entera. Tus datos sin guardar se quedan. Una respuesta empezada se queda en el cuadro de respuesta, y un título o una descripción abiertos conservan tu texto. Si el texto guardado ha cambiado mientras tanto, debajo del campo aparece «The saved text has changed in the meantime.». Si guardas entonces, tu texto sustituye al guardado. El botón «Refresh» de la cabecera del ticket hace lo mismo.

Si guardas de todos modos sobre una versión desactualizada, el guardado se rechaza. Se abre la ventana «Ticket changed in the meantime». Si el cambio lo hizo una persona, la ventana la nombra. Tu cambio no se ha guardado. Haz clic en «Refresh», compara tu cambio con la versión actual y vuelve a guardar. Esto vale para cualquier cambio en el propio ticket, por ejemplo el estado, la asignación, la prioridad, la tarjeta «Details» y los campos personalizados.

Los comentarios no se rechazan nunca. Dos respuestas no se sobrescriben entre sí. Ambas acaban en el ticket. Lo mismo vale para los adjuntos y los registros de tiempo. Las acciones en lote en la lista de tickets y las reglas de automatización tampoco se comprueban contra la versión. Cambian el ticket directamente. Quien lo tenga abierto ve el aviso después.

Los clientes no ven nada de esto. No aparecen en el aviso. Tampoco ven quién está trabajando en su ticket.

Quién tiene un ticket abierto solo se guarda en la memoria del servidor. Aproximadamente un minuto después de que la persona haya dejado el ticket, la entrada desaparece. Nada de ello se escribe en un registro. El ticket guarda quién lo cambió por última vez. Esa entrada forma parte de la exportación de datos de esa persona. Cuando la persona se anonimiza, se elimina.

El canal de correo es un camino con dos sentidos, y van juntos: un correo entrante se convierte en un ticket, tu respuesta sale como correo y la contestación de quien solicitó llega como comentario al mismo ticket, no a un segundo.

La asignación no se hace a ojo: una respuesta solo llega al ticket existente cuando el correo lleva la referencia del caso en el asunto o trae consigo las cabeceras de respuesta del programa de correo. Un correo sin ninguna de las dos cosas empieza un caso nuevo: mejor un ticket de más que dos casos sin relación fusionados solo porque el asunto coincidía.

Todo lo necesario está en «Settings → E-Mail Settings». La tarjeta superior, «SMTP settings», es el camino de salida: servidor, puerto, «Use SSL», usuario y contraseña, además de la dirección y el nombre del remitente. Con «Send test e-mail» te envías una muestra a ti mismo; primero guardar y después probar, como indica la propia tarjeta.

La tarjeta «IMAP settings» es el camino de entrada: servidor, puerto, el intervalo de consulta y las dos carpetas. No tienes que adivinar el nombre de la carpeta: «Read from server» recupera las carpetas que existen de verdad en tu buzón y «Create on server» crea una nueva. El campo toma entonces la ruta que usa tu servidor de correo para ella: un servidor escribe «INBOX/Processed» y el siguiente «INBOX.Processed», y ambos significan lo mismo.

La «Processed folder» recoge los correos que el sistema aparta: correos de remitentes bloqueados, correos generados automáticamente y correos que un flujo de trabajo mueve con «Move to folder» sin carpeta propia. Si la dejas vacía, se quedan en la bandeja de entrada. Debajo defines cuándo se ejecuta la limpieza («Hour», «Minute») y qué antigüedad puede alcanzar un mensaje («Retention (days)»), porque si no el buzón crece en silencio.

Los buzones pertenecen al equipo, no al sistema: en «Team mailboxes», cada equipo introduce su propia dirección con una contraseña. Esa dirección es al mismo tiempo el remitente de los correos de ese equipo, de modo que quien solicita responde al mismo sitio del que se recoge el correo.

Y ahora la parte sin la cual no ocurre nada de esto: el flujo de trabajo. Un buzón configurado, por sí solo, no hace nada. Si un equipo no tiene un flujo activado, el buzón ni siquiera se consulta: ningún ticket, ninguna confirmación, los correos se quedan ahí. La respuesta automática a tus clientes existe únicamente aquí, y la configuras tú. Es a propósito: un sistema que escribiera sin que nadie se lo pidiera a cualquier dirección de remitente sería peor que uno que se queda callado.

En «E-Mail workflows» eliges arriba el equipo y creas un flujo con «+ Add workflow». Recibe un nombre (solo para ti), un interruptor «Enabled» y dos indicaciones sobre cuándo se aplica: «Match» decide si deben cumplirse todas las condiciones («All conditions») o basta con una, y «Stop after match» termina la ejecución en cuanto este flujo ha coincidido, con lo que un flujo posterior ya no llega a su turno. El orden lo cambias con las flechas de al lado.

Bajo «When?» está la condición en sí. «Every e-mail in this mailbox» toma todos los correos; «Only when subject or text contains» exige una palabra en el asunto o en el cuerpo. «Advanced» lo hace preciso: ahí eliges qué se mira («Subject or body», «Subject», «Body», «Sender (From)» o «Recipient (To/Cc)») y cómo se compara: «Contains», «Equals» o «Regex». Así separas, por ejemplo, los avisos a una dirección compartida de todo lo demás.

Debajo hay cinco acciones como interruptores. Son el contenido real del flujo: lo que no esté activado, no ocurre:

«Create or append ticket» convierte el correo en un ticket, o lo añade como comentario a uno existente cuando la referencia está en el asunto. Sin esta acción, un correo nunca se convierte en un caso.

«Set fields» fija la prioridad, el estado, la categoría principal y la subcategoría, el equipo responsable y la persona asignada justo al crear el ticket. Todo lo que se deje en «— Keep default —» se queda como estaría sin flujo de trabajo.

«Auto-reply» es la confirmación al remitente. Con este interruptor desactivado, tu cliente no recibe ninguna confirmación, por bien configurado que esté todo lo demás. «Send mail» también puede escribir al remitente, como muestra la acción siguiente.

«Send mail» envía un correo adicional: al remitente del correo entrante o a miembros del equipo elegidos y a direcciones fijas. Tiene sus propias «Send conditions»; si las dejas vacías, sale en cada ejecución de este flujo.

«Move to folder» archiva el correo procesado en una carpeta. Si dejas el campo vacío, se aplica la «Processed folder» general de los ajustes de IMAP de más arriba.

La acción «Auto-reply» en detalle: el asunto lo construyes con bloques. «Original subject {originalSubject}» adopta el asunto del correo entrante y «Ticket reference {ticketTag}» inserta la referencia del caso; juntos dan algo como «Printer problem [TICKET-99-a1b2c3]».

La referencia no se añade sola. Aparece únicamente donde tú pongas {ticketTag}. {ticketId} solo inserta el número sin más, y el sistema no reconoce una respuesta por él. Sin la referencia en el asunto, una respuesta se sigue asignando si lleva las cabeceras de respuesta de la confirmación. Solo un correo sin ninguna de las dos cosas se convierte en un ticket nuevo.

El texto de debajo es tu mensaje de confirmación. Escríbelo en inglés: pasa por la misma exportación e importación que cualquier otro texto, y solo así puede traducirse a los demás idiomas. Si lo dejas vacío, el sistema envía su propio mensaje de fábrica. Aquí se admiten los mismos marcadores.

«Reply language» decide en qué idioma salen el asunto y el texto: «Standard English» usa el inglés, «Fixed language» un idioma que elijas, «Assigned agent's language» el idioma del agente asignado y «Team default language» el idioma predeterminado del equipo. Las traducciones en sí se mantienen en la página de idiomas.

Un consejo que el sistema imprime también encima de la tarjeta: todo lo que pertenece a un mismo caso pertenece a UN solo flujo de trabajo. Únicamente las acciones dentro del mismo flujo conocen el ticket recién creado; por eso la confirmación puede nombrar su número y una acción de un segundo flujo no puede.

Todo el canal de correo, de entrada y de salida, forma parte de la edición Professional. En Basic, el sistema ni envía ni recibe correo; allí los tickets se crean por el portal, por teléfono y por el agente.