Es la distinción que más confunde al empezar, y en realidad es sencilla.

Una conversación es un hilo con un cliente. Empieza cuando escribe y termina cuando queda resuelto.

Un ticket es trabajo pendiente para tu equipo. Puede durar días, pasar por varias manos y no depende de que el cliente esté esperando en el chat.

La regla corta

Si puedes resolverlo mientras hablas, es una conversación.

Si tienes que decir "lo miramos y te contamos", eso es un ticket.

Ese momento, el "lo miramos y te contamos", es exactamente donde se pierden las cosas en soporte. Es una promesa que vive en la cabeza de alguien y no en ningún sitio.

¿Necesitas tickets?

No siempre, y no pasa nada por no usarlos.

Si tu soporte se resuelve casi todo en el momento (dudas de uso, precios, dónde está algo), las conversaciones te bastan. Añadir tickets sería un paso administrativo sin beneficio.

Los tickets empiezan a merecer la pena cuando:

A menudo tienes que investigar antes de poder responder. Hay cosas que dependen de otro equipo, como desarrollo o almacén. El trabajo dura más que la paciencia del cliente en el chat. Necesitas que quede constancia de que algo está pendiente, más allá de que alguien se acuerde.

Convertir una conversación en ticket

Desde la conversación, con el botón de convertir en ticket, o con Ctrl o Cmd + B.

Le pones un título y una descripción de lo que hay que resolver. La IA puede proponerte un borrador a partir de la conversación, que puedes aceptar o reescribir.

Lo importante: la conversación original queda enlazada al ticket. Desde el ticket puedes volver al hilo del cliente cuando necesites el contexto o las palabras exactas de lo que pidió.

Eso significa que no pierdes nada al convertir. No es "cerrar la conversación y abrir otra cosa": es añadir una capa de seguimiento encima.

Escribir un ticket que sirva

Como lo lee alguien que no estaba en la conversación, el título y la descripción importan más de lo que parece.

El título debe decir qué hay que hacer, no de quién es. "Revisar cobro duplicado del pedido 4471" es mejor que "Problema de Marta".

La descripción debe contener lo necesario para trabajar sin releer todo el hilo: qué pasó, qué se ha comprobado ya, qué se espera de quien lo coja.

Un ticket que dice "ver conversación" obliga a la siguiente persona a leerse veinte mensajes. Es el equivalente a no escribirlo.

Los estados

Los tickets pasan por estados que reflejan en qué punto está el trabajo. Puedes cambiarlos desde el propio ticket y configurarlos en Configuración, en Tickets.

Merece la pena tener pocos y claros. Un conjunto de estados que nadie entiende acaba con todo en el primero.

El panel del ticket

Cada ticket tiene su propia vista con:

Su actividad, que es todo lo que ha ido pasando. Sus notas y contexto interno. El enlace a la conversación original.

Es donde vive el trabajo mientras el cliente espera.

Tickets desde el correo

Los correos entrantes pueden convertirse en tickets automáticamente. Se configura en Configuración, en Tickets.

Encaja bien si tu soporte por correo es sobre todo de peticiones que requieren gestión. Encaja mal si recibes muchas dudas rápidas: acabarías con cientos de tickets que se cierran en dos minutos.

El error más común

Convertirlo todo en ticket "por si acaso".

Un ticket por cada conversación convierte la bandeja en una lista de tareas enorme donde ya no se distingue lo urgente. Los tickets funcionan porque son pocos y significan algo.

Conviértelos cuando de verdad haya trabajo pendiente.

Y el segundo error más común

Crear el ticket y no decírselo al cliente.

El ticket es para tu equipo. El cliente no lo ve. Si conviertes una conversación en ticket y no respondes nada, desde fuera parece silencio.

Responde siempre algo antes: qué vas a mirar y cuándo le dirás algo.