El correo que quedó ahí, sin respuesta, toda una semana
Una clienta escribe un martes. Su pedido llegó roto. No está enojada todavía, solo confundida, y espera que alguien la ayude.
El correo llega a una bandeja compartida. Tres personas pueden verlo. Cada una asume que otra va a responder. El jueves, ya está enterrado bajo cuarenta mensajes nuevos. El martes siguiente, ya no está confundida. Está enojada. Y le está contando a una amiga que no compre en tu negocio.
Nadie hizo nada mal a propósito. Por eso esta historia es tan común. Llevo años construyendo los sistemas detrás de operaciones de atención al cliente — la parte que el cliente nunca ve, la que decide si su pedido se resuelve en diez minutos o se pierde una semana. Casi todos los negocios con los que hablo vivieron alguna versión de esta historia, justo cuando el correo deja de alcanzar.
Te cuento qué pasa realmente cuando una solicitud de un cliente entra a un sistema de tickets bien armado, y por qué eso cambia tanto el resultado.
Cada solicitud se convierte en un ticket, no solo en un mensaje
En una bandeja compartida, un correo de un cliente es solo... un correo. No tiene estado. Nadie es dueño de él. Lo pueden leer cinco personas y no responderlo ninguna.
Un sistema de tickets convierte ese mismo correo en un ticket apenas llega. Un ticket tiene algo que un correo no tiene:
- Un responsable — una persona con nombre y apellido a cargo
- Un estado — nuevo, en proceso, esperando al cliente, resuelto
- Una marca de tiempo — el momento exacto en que llegó
Suena chico. No lo es. En el momento en que un mensaje se convierte en un ticket con dueño y estado, deja de ser invisible. Cualquiera del equipo puede mirar la cola y ver, de un vistazo, qué se atendió y qué no.
Asignación: que la solicitud llegue a la persona correcta
No todas las solicitudes necesitan a la misma persona. Una pregunta de facturación, una demora de envío y un producto roto son tres problemas distintos, y casi siempre tres especialidades distintas.
Un buen sistema de tickets deriva cada solicitud según reglas simples definidas de antemano. Un mensaje con la palabra "reembolso" va a facturación. Uno etiquetado "envío" va a logística. Si nadie tomó un ticket dentro de un tiempo determinado, se marca para que un supervisor lo note.
Una vez ayudé a un equipo a reemplazar el criterio de "lo toma el que esté libre" por asignación basada en reglas. El cambio fue casi aburrido — un puñado de reglas de derivación. El efecto, en cambio, fue inmediato: menos tickets rebotando entre tres personas antes de llegar a la correcta, y clientes que ya no explicaban su problema dos veces.
Priorización: decidir qué se atiende primero
No todos los tickets merecen la misma atención en este momento. Una clienta que no puede completar un pago durante una promoción es un nivel de urgencia distinto al de alguien que pregunta por la política de devoluciones del mes que viene.
Priorizar significa que el sistema — y el equipo — trata los tickets según la urgencia, no solo según el orden de llegada. Palabras como "no puedo pagar", "no funciona" o "urgente" pueden hacer que un ticket suba automáticamente en la cola. También influye quién pregunta: una clienta de mucho tiempo con un pedido activo puede pasar delante de una consulta general sin pedido asociado.
Esa es justamente la idea: una cola ordenada solo por tiempo hace que un arreglo urgente de cinco minutos quede detrás de veinte preguntas fáciles que llegaron antes.
Por qué "usemos el correo, nomás" deja de funcionar al crecer
El correo funciona bien cuando una sola persona responde todo. Empieza a fallar en un punto muy específico: cuando entra más de una persona a responder.
Los estudios sobre bandejas compartidas lo confirman — los equipos con más de un puñado de agentes, o más de unas cincuenta conversaciones por día, empiezan a tener problemas reales. Hay mensajes que dos personas responden por separado, sin ver la respuesta de la otra. Y hay otros que no responde nadie, porque cada uno asumió que ya lo tenía otro.
Nada de esto tiene que ver con el esfuerzo. Tu equipo puede trabajar muy bien y aun así perder el hilo, porque el correo nunca fue pensado para mostrar quién es dueño de qué. Un sistema de tickets existe justamente para responder la pregunta que el correo no puede: ¿de quién es esto, ahora mismo?
Qué muestran realmente los reportes de tiempo de respuesta y resolución
Cuando las solicitudes se convierten en tickets, se vuelve posible algo nuevo: medirlas. Dos números importan más que el resto.
El tiempo de respuesta es cuánto espera un cliente hasta escuchar a un humano por primera vez — aunque sea solo un "lo recibimos, ya lo estamos viendo". El tiempo de resolución es cuánto pasa hasta que el problema se cierra de verdad.
No son números decorativos. Un tiempo de respuesta que empieza a subir suele ser la primera señal de que falta una persona en el equipo, antes de que alguien se queje en voz alta. Y si una sola categoría — digamos, facturación — tarda mucho más que el resto en resolverse, eso te dice exactamente dónde está trabado el proceso, en vez de dejarte adivinando.
Vi cómo un panel de rendimiento convirtió una sensación vaga ("la atención se siente más lenta") en una decisión concreta ("los martes y miércoles necesitamos un agente más") en cinco minutos. Ese es el valor real: convertir una intuición en un número sobre el que se puede actuar.
Señales de que ya superaste el correo y las planillas
Algunas señales que escucho una y otra vez:
- Clientes que escriben para preguntar "¿recibieron mi último mensaje?"
- Dos personas del equipo que le respondieron al mismo cliente cosas distintas
- Nadie puede decir, sin revisar tres bandejas, cuántos casos abiertos hay en este momento
- Te enterás de una respuesta lenta recién cuando el cliente se queja en público
Cualquiera de estas señales ya es un llamado de atención. Dos o tres juntas significan que el sistema que estás usando no fue pensado para el tamaño del equipo que lo usa.
Esto se conecta con algo de lo que escribo seguido: depender de una sola persona para saber cómo está cada cosa es un riesgo en sí mismo. Un sistema de tickets también resuelve eso — todo el equipo ve la cola, no solo quien la tiene en la cabeza.
También vale conocer la diferencia con un CRM. Un CRM sigue tu relación con un cliente en el tiempo. Un sistema de tickets sigue una solicitud puntual, desde que llega hasta que se cierra. Muchos negocios terminan necesitando los dos, pero resuelven problemas distintos.
Por dónde empezar
No hace falta cambiar todo el primer día. Preguntate: si ahora mismo llega un correo de un cliente, ¿todo tu equipo sabría quién es el dueño de ese caso y qué tan urgente es? Si la respuesta honesta es no, ahí está tu punto de partida — no un proyecto enorme de software, sino una forma más clara de ver qué entra y quién lo atiende.