Cómo priorizar tickets de soporte (sin depender del que grita más fuerte)

Hay una regla no escrita que gobierna la mayoría de las colas de soporte del mundo: se atiende primero al que insiste. El cliente que manda tres mensajes seguidos y termina con “¿alguien ahí?” pasa adelante. El que escribió una vez, con calma, y se quedó esperando, se hunde. Nadie decidió que fuera así. Es lo que pasa cuando no hay un criterio explícito y cada agente elige de la lista lo que le salta a la vista.

El problema de esa regla es que no tiene ninguna relación con lo que le conviene al negocio. Insistir mide la personalidad del cliente, no la gravedad del caso. Y mientras tanto, el ticket del cliente que tiene la facturación caída desde ayer sigue esperando, porque escribió educadamente una sola vez.

Priorizar es poner ese criterio por escrito antes de que la cola te obligue a improvisar.

Los dos ejes que definen una prioridad

Casi todos los modelos de priorización que funcionan se reducen a cruzar dos cosas: impacto (a cuántos afecta y qué tan grave es) y urgencia (qué tan rápido se degrada si no haces nada).

Son ejes distintos y conviene no confundirlos. Un error de tipografía en la página de precios tiene impacto alto (lo ve todo el mundo) y urgencia baja (mañana sigue igual de mal, ni peor). Una integración caída para un solo cliente tiene impacto bajo en el conjunto y urgencia altísima para ese cliente, porque cada hora que pasa se acumulan datos sin sincronizar.

Cruzando los dos ejes salen cuatro cajones. En la práctica, la mayoría de los equipos los llama así:

La tabla es la parte fácil. Lo difícil es acordar, con nombres y ejemplos concretos de tu producto, qué cae en cada cajón. Ese acuerdo es el 90% del trabajo, y es el que casi nadie hace.

Cómo se ve eso en tu producto (y no en un manual)

Una matriz genérica no sirve para decidir a las 10 de la mañana con doce tickets abiertos. Lo que sirve es una lista de casos reales de tu producto mapeados a cada nivel. Algo así:

• P1: el servicio no responde para todos, se cobró dos veces a un cliente, se filtró información de una cuenta.
• P2: una función central falla para un cliente grande, un cliente en periodo de prueba está bloqueado y vence en tres días, un error impide facturar aunque haya un workaround manual.
• P3: algo funciona mal pero hay forma de rodearlo, una consulta de configuración, un reporte que muestra un dato raro.
• P4: una sugerencia de mejora, una pregunta de “cómo se hace”, un detalle visual.

Escribe tu propia versión de esa lista con tu equipo, en media hora, con ejemplos de tickets que ya recibiste. Ese documento vale más que cualquier framework porque elimina las discusiones de todos los días. Cuando alguien duda de si algo es P2 o P3, mira la lista en lugar de preguntar en el canal.

Un detalle que suele quedar fuera: el nivel de prioridad tiene que traer pegado un compromiso de tiempo. “P1” no significa nada si no dice cuánto. Si tu P1 se responde en 15 minutos y tu P3 dentro de las 48 horas hábiles, escríbelo. Cómo definir esos compromisos y medirlos lo desarrollamos en cómo medir el SLA de soporte.

El cliente no decide su propia prioridad

Casi todos los formularios de soporte tienen un desplegable de prioridad que el cliente completa. Y casi todos terminan con el 70% de los tickets marcados como “urgente”, porque para el cliente su problema siempre lo es. Es humano y es esperable.

Lo que el cliente sí puede darte, y es valiosísimo, es el impacto desde su lado: a cuántas personas de su equipo afecta, si tiene alguna forma de seguir trabajando mientras tanto, si hay una fecha límite real de por medio. Pregúntale eso en lugar de pedirle que se autoasigne un P1. Con esa información, la prioridad la fija tu equipo, que es el único que puede comparar ese caso contra los otros once de la cola.

Cuando todo es P1, nada es P1

La señal de que tu esquema se rompió es fácil de ver: la mitad de la cola está marcada como crítica. Cuando eso pasa, la etiqueta dejó de ordenar nada y el equipo volvió a elegir por instinto, solo que ahora con más burocracia encima.

Dos cosas suelen causarlo. La primera es que la definición de P1 quedó demasiado ancha, y todo lo que “molesta bastante” entra. La segunda es que subir la prioridad no le cuesta nada a nadie, así que ante la duda todos suben. Se arregla igual: acotando la definición de P1 a un puñado de escenarios que puedas contar con los dedos de una mano, y pidiendo que quien marca un P1 escriba una línea justificando por qué. Ese pequeño costo hace maravillas.

Y si de verdad tienes cinco P1 simultáneos, ordena por cuántos clientes afecta cada uno. Cuando incluso eso empata, el más viejo va primero.

Dónde vive la prioridad

Todo esto asume algo que en muchos equipos no está resuelto: que los tickets estén en un lugar donde se les pueda poner prioridad. Un canal de Slack no tiene campo de prioridad. Una casilla de correo compartida tampoco. Ahí la única prioridad posible es el orden cronológico invertido, que es exactamente el problema del que hablábamos al principio.

Con MelonHelp, cuando alguien reacciona a un mensaje de Slack con el emoji 🎫, el ticket se crea con el contenido y el autor ya cargados, y desde ese momento tiene dueño, estado y prioridad. La conversación sigue donde tu equipo ya trabaja, pero deja de ser un mensaje suelto para pasar a ser algo que la cola puede ordenar.

Si atiendes ocho consultas por semana y todas te caben en la cabeza, este artículo entero te sobra: ordenar por fecha te alcanza y cualquier sistema de prioridades te va a dar más trabajo del que te ahorra. La prioridad recién empieza a pagar cuando la cola es más larga que tu memoria y hay más de una persona eligiendo qué agarrar.

Preguntas frecuentes