Manual

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 aparecen y cuáles de ellos son obligatorios se define en «Settings → Ticket Settings», por separado para los agentes y para los clientes. Por eso un cliente ve un formulario más corto que el tuyo sin que nadie tenga que mantener dos formularios.

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 prioridad, la asignación, el canal y los observadores están una tarjeta más arriba, en «Actions», y surten efecto de inmediato, sin guardar aparte.

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. Solo entonces desaparecen esos tickets de la base de datos en marcha, 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.

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 «Only for Admin/Agents». Lleva entonces la marca «Internal» y es invisible para quien solicita; ni siquiera la búsqueda lo saca a la luz.

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

Un comentario aparece ahí abreviado; el texto completo vive 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. Seis estados llevan la marca «Mandatory» en la lista: Open, Assigned, In Progress, Resolved, Closed y Reopened. 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 «Rejected», 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.

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», «Site», «Role», «Status» y «Priority». Detrás de cada una hay el mismo manejo, así que solo tienes que aprenderlo una vez.

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 site» o «+ Add department». Las filas de debajo son las entradas existentes: ahí cambias un nombre y lo confirmas con el «Save» de al lado.

Para muchas entradas de una vez están «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», seis 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»). Se pueden renombrar pero no borrar: de ellos cuelgan permisos y procesos que si no dejarían de funcionar sin decir nada.

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 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 «Email» cuando nació de un correo entrante.

Por eso tampoco puedes cambiar después a «Phone» un canal asignado por el sistema: 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.

«Email» 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. 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.

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

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.

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» se aplican a los tickets nuevos: «Mandatory by default», «Hidden for customer by default» y «Not editable by customer by default». Son valores de partida; los ajustes del campo en esa misma página siguen siendo el lugar donde lo defines con precisión por rol.

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, pero no puede levantar una regla: lo que el administrador ocultó a los clientes o declaró obligatorio sigue así, aunque una plantilla diga otra cosa. De lo contrario, una plantilla sería una vía para escapar de una norma de la casa.

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.

Solo se puede elegir a agentes y administradores de un equipo participante. 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.

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

El aviso es un correo, así que el envío de correo tiene que estar configurado (Professional). Sin él puedes introducir observadores, pero no sale nada.

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.

Los correos procesados se mueven a la «Processed folder»; 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, el único lugar en el que el sistema responde por su cuenta. Con este interruptor desactivado, tu cliente no recibe nunca una respuesta automática, por bien configurado que esté todo lo demás.

«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]».

La referencia no se añade sola. Aparece únicamente donde tú pongas {ticketTag} o {ticketId}, y es exactamente por lo que el sistema reconoce después la respuesta de tu cliente. Sin ella en el asunto, cada réplica empieza un ticket nuevo en lugar de convertirse en un comentario del antiguo.

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.

El registro de tiempos está desactivado de fábrica. Mientras lo esté, no hay campo, ni columna, ni tarjeta en el informe.

Un campo muerto sería peor que ninguno, así que la función desaparece por completo en lugar de quedarse ahí atenuada.

El interruptor está en «Settings → General», en la tarjeta «Time tracking per ticket», y se llama «Enable time tracking».

A partir de ahí participan todos los equipos. Para dejar uno fuera, lo desactivas en el propio equipo, en «Settings → Teams», dentro del recuadro «Team details».

Una empresa con un equipo de TI interno y otro de cara al cliente suele necesitarlo solo para el segundo.

Si más adelante vuelves a desactivar el registro de tiempos, las entradas existentes siguen siendo legibles y exportables: son una base para facturar, no una comodidad. Lo que no se puede es registrar nada nuevo.

El ticket lleva una tarjeta llamada «Time spent». «Log time» abre la entrada.

Junto al campo hay botones rápidos: un clic en «30m» registra treinta minutos. Qué botones aparecen se define en los ajustes.

El campo «Duration» admite también entrada libre: «90» son noventa minutos, «1.5h» es una hora y media, y «1h 30m» también. Un número sin unidad son siempre minutos.

Lo que el sistema no entiende del todo se rechaza. «1h por la tarde» no se convierte en una entrada de una hora: se convierte en un mensaje de error.

En «What for (optional)» escribes para qué fue el tiempo. El texto viaja a la exportación y no aparece en el historial del ticket.

Varios agentes registran tiempo en el mismo ticket. Cada entrada lleva su día, su nota y el nombre de la persona que hizo el trabajo.

El tiempo se registra sobre un día, no sobre una hora concreta. Rellenar lo de ayer es el caso normal, y una hora exacta afirmaría una precisión que la entrada no tiene.

Para las sesiones largas hay un cronómetro en el ticket: «Start timer» lo pone en marcha y «Pause» lo detiene.

El cronómetro no crea nunca una entrada por su cuenta. Propone el tiempo transcurrido, y no se guarda nada hasta que pulsas «Log».

Sustituye al cálculo mental, no al conocimiento. Sin él la función está completa, porque teclear el valor es la vía principal.

Abrir otro ticket pausa el cronómetro en marcha, y el ticket nuevo te dice a qué ticket está enganchado.

Una ventana oculta no es una pausa. El cronómetro sigue corriendo si solo cambias de pestaña.

Contra un cronómetro olvidado toda la noche existe un tiempo máximo de marcha. El valor se recorta, nunca se descarta, y se le comunica al agente.

El cronómetro está desactivado de fábrica. Lo encuentras en los ajustes, en «Stopwatch on the ticket».

Cada entrada lleva una marca «Billable». El tiempo se registra una vez, y la marca decide si va a la factura.

Por eso el ticket muestra dos totales: a la izquierda todo lo registrado y a la derecha la suma facturable.

No hay un tipo aparte para las cortesías. La cortesía, el trabajo en garantía y el rehacer interno se llaman de forma distinta en cada empresa, y el sistema conoce solo la única distinción de la que depende el dinero.

Así se registra una cortesía: introduce el tiempo como siempre, quita la marca y escribe el motivo en la nota.

La entrada lleva entonces de forma visible «not billable». Los minutos siguen en el total registrado, porque el trabajo sí se hizo.

Quien no registra el tiempo pierde justo la cifra que después explica por qué se cobró tan poco a un cliente.

Si la mayor parte de tu trabajo no es facturable, invierte el valor de partida con el interruptor «New entries are billable by default».

De fábrica se factura todo al minuto. Quien factura en cuartos de hora define dos valores.

«Rounding increment (minutes)» es el paso. Cada entrada se redondea al alza hasta el siguiente múltiplo.

«Minimum per entry (minutes)» es el mínimo. Cada entrada se factura al menos con ese valor.

Los dos actúan uno detrás de otro: primero el mínimo y después el paso. Con un mínimo de 20 y un paso de 15, cinco minutos se convierten en treinta, porque el resultado tiene que cumplir ambas cosas.

Debajo de los dos campos hay una frase de ejemplo con tus propios valores. Está calculada, no afirmada.

Solo se redondea el valor facturado, y siempre por entrada, nunca el total. Dos entradas pequeñas se redondean por tanto dos veces.

El tiempo registrado queda intacto. Cambiar después el redondeo no falsea ningún dato antiguo, porque el valor se calcula en el momento de mostrarlo.

En la entrada ves ambos: donde el redondeo cambia el valor, el resultado aparece al lado entre paréntesis.

Un proveedor de servicios suele no querer que se cierre ningún ticket sin tiempo registrado. Para eso hay un interruptor.

Se llama «Require a time entry before resolving or closing» y está desactivado de fábrica.

Se aplica solo cuando una persona cambia el estado. Un agente sin entrada recibe un mensaje y el ticket se queda abierto.

El cierre automático, la fusión y las acciones en lote no se bloquean nunca. De lo contrario habría tickets que ya nadie podría cerrar.

Este es el interruptor más peligroso de toda la función. Actívalo solo cuando tu equipo registre el tiempo de verdad siempre.

La lista de tickets recibe una columna «Time» que muestra cuánto se ha registrado ya en un caso.

No hay que activarla. Aparece en cuanto un ticket de la lista lleva tiempo.

En ventanas estrechas es de las primeras que vuelven a caer. La lista conserva entonces las columnas sin las que no se puede encontrar un ticket.

El tiempo que solo está en un ticket individual no es base para una factura. Por eso la página de informes lleva una tarjeta «Time spent».

Arriba hay cuatro cifras: registrado, facturado, número de entradas y número de tickets que llevan algo de tiempo.

Esa última cifra es la más importante después del total. Cuarenta horas en tres de quinientos tickets no es una evaluación: son tres agentes que son los únicos que registran.

Debajo vienen los desgloses: por quien solicita, por equipo, por categoría y por día.

Además hay una tabla por cada campo personalizado. Ese es el camino a facturar por empresa o por centro de coste: creas un campo personalizado, lo rellenas en el ticket y el informe agrupa por él.

El periodo de la parte superior de la página se refiere al día en que se hizo el trabajo. El trabajo de julio en un ticket de junio consta, por tanto, en el informe de julio.

Una nota sobre las cifras merece tomarse en serio: proceden de entradas hechas por personas y de tus reglas de redondeo. Son una base de trabajo, no una factura auditada.

Bajo la tarjeta hay tres botones. Entregan las entradas individuales, no los totales de la página.

Son dos destinatarios, no tres formatos de archivo. «Export entries (CSV)» y «Export entries (Excel)» van a contabilidad: ambos son completos y no se recortan nunca.

«Export entries (PDF)» es el documento para una persona. Va al cliente como anexo de la factura.

El PDF está limitado a 20.000 entradas, y el propio documento lo indica. De todos modos, nadie lee una factura con más líneas que esas.

Los tres archivos se construyen a partir de la misma fuente: los filtros, el redondeo, las columnas y las cifras existen una sola vez, así que los tres no pueden separarse.

Una entrada que no es facturable tiene una celda vacía en la columna de facturable, no un cero. Un cero se sumaría en una tabla dinámica.

Un cliente no ve nunca las entradas de tiempo, ni siquiera en su propio ticket.

Esto no es un ajuste, sino un cerrojo en el servidor. No hay ningún interruptor que lo abra.

El motivo está en las propias entradas: las notas se escriben para el equipo. Dicen qué salió mal y cuánto duró la búsqueda de la causa.

Otros sistemas de este tipo hacen lo mismo. Donde el tiempo llega al cliente, llega como documento.

Para eso está la exportación en PDF: sale con la factura y no al ticket del portal de clientes.

El informe puede mostrar además quién ha registrado cuánto. De fábrica no lo hace.

El tiempo por persona son datos de rendimiento y, en muchas empresas, el comité de empresa tiene algo que decir al respecto.

El interruptor se llama «Per-agent evaluation» y está en los ajustes.

Mientras esté desactivado, el servidor ni siquiera entrega las cifras. La tabla no está oculta: no existe.

Esa diferencia importa. Un cerrojo que solo conoce la pantalla no es un cerrojo.