Triaje y borradores de respuesta: menos horas de espera en soporte

Son las 9:15 de un lunes. En la bandeja de soporte hay 140 tickets sin abrir del fin de semana. Un agente entra, lee el primero, decide de qué va, busca en qué documento estaba la respuesta, la adapta, la escribe y la envía. Doce minutos. El segundo es una consulta de facturación que no le toca a él, así que la reasigna. El tercero es una queja urgente enterrada entre dudas triviales, pero nadie la ha visto todavía porque llegó a las 23:00 del sábado.

Ese es el problema real: no es que el equipo escriba mal, es que dedica la mitad del turno a clasificar, priorizar y buscar antes de poder responder nada. Y mientras tanto, el reloj del SLA (el tiempo máximo de respuesta que has prometido al cliente) corre. El resultado son primeras respuestas lentas, casos urgentes que se cuelan tarde y agentes agotados de tareas mecánicas.

Dónde se pierde el tiempo hoy

Si desglosas el ciclo de un ticket, el tiempo no está donde crees. Está antes de escribir:

• Lectura y comprensión: cada agente abre el ticket, entiende el idioma, el tono y el asunto real, que muchas veces no coincide con lo que dice el campo asunto.
• Clasificación manual: decidir categoría (facturación, incidencia técnica, envío, cancelación) y urgencia. Cuando lo hacen varias personas, los criterios varían.
• Reasignación: un porcentaje alto de tickets acaba en la cola equivocada y se mueve una o dos veces antes de llegar a quien corresponde.
• Búsqueda de la respuesta: rebuscar en la base de conocimiento, en correos antiguos o en Slack cuál era la política vigente.
• Redacción desde cero: reescribir por enésima vez la misma explicación de cómo solicitar una devolución.

La parte que aporta juicio (decidir si una excepción aplica, calmar a un cliente enfadado) es minoritaria. El grueso es trabajo repetitivo que retrasa todo lo demás.

Cómo cambia el proceso con Claude

La idea no es que un modelo responda solo a los clientes. Es que haga el trabajo previo y deje al agente listo para decidir. El reparto es explícito: Claude clasifica y propone un borrador, la persona revisa, corrige y envía. Nada sale sin ojo humano.

El flujo nuevo, ticket a ticket:

1. Triaje automático: al entrar el ticket, Claude lee el texto, detecta idioma, asigna categoría y nivel de urgencia, y extrae los datos clave (número de pedido, producto, fecha). Devuelve todo en un formato fijo.
2. Enrutado: con esa clasificación, el ticket cae directo en la cola correcta. Menos reasignaciones.
3. Borrador de primer nivel: para las categorías frecuentes, Claude redacta una respuesta apoyándose en los artículos de tu base de conocimiento que tú le has dado. El borrador cita de qué política sale cada afirmación.
4. Revisión humana: el agente ve el ticket ya clasificado y con un borrador. Lee, ajusta el tono, corrige lo que no cuadre y pulsa enviar. O lo descarta si el caso es delicado.

El agente pasa de producir a validar. Ese cambio es el que recorta minutos por ticket sin sacrificar control.

Cómo implantarlo

No montes esto para todo el departamento de golpe. Un piloto acotado la semana que viene:

1. Elige un segmento estrecho: una sola categoría con volumen alto y riesgo bajo. Por ejemplo, dudas sobre estado de pedidos o cómo hacer una devolución. Nada de reclamaciones legales ni bajas.
2. Reúne tu material: 10 o 15 artículos de tu base de conocimiento y 20 ejemplos de respuestas buenas ya enviadas. Ese es el contexto que Claude usará.
3. Escribe la instrucción de triaje y pruébala con tickets reales anonimizados.

Eres asistente de triaje de soporte. Para cada ticket devuelve:
- categoria: [facturacion | envios | devoluciones | tecnico | otros]
- urgencia: [alta | media | baja]
- idioma detectado
- datos_clave: pedido, producto, fecha si aparecen
- resumen en una frase
No inventes datos que no estén en el texto.

Redacta un borrador de respuesta usando SOLO la
información de los artículos adjuntos. Tono cercano y
profesional, en el idioma del cliente. Si la respuesta no
está en los artículos, escribe: "Requiere revisión: sin
fuente". Indica al final de qué artículo sale cada punto.

Para que el equipo aproveche esto sin depender de nadie técnico, viene bien un curso para empezar con Claude desde cero donde aprendan a escribir instrucciones y a montar este tipo de flujos por sí mismos.

Qué medir

Compara siempre contra tu línea base de las semanas anteriores al piloto:

Con dos semanas de datos ya ves si el piloto se sostiene. Si el FRT baja pero suben las quejas por respuestas impersonales, el problema es de tono, no de velocidad.

Riesgos y límites

Esto tiene fronteras claras que conviene decir sin adornos:

• El envío automático no es el objetivo. Un borrador enviado sin leer es una carta que no escribiste tú firmada con tu nombre. Mantén la validación humana, sobre todo al principio.
• Datos personales y RGPD. Los tickets contienen nombres, correos, direcciones y a veces datos de pago. Anonimiza en las pruebas, revisa qué tratamiento de datos permite tu contrato con el proveedor y no metas números de tarjeta ni datos de salud en ningún prompt. En España y LATAM aplica el RGPD y las leyes locales de protección de datos: consúltalo con tu responsable antes de conectar buzones reales.
• Alucinaciones. Si Claude no tiene la política en el contexto, puede inventarse una respuesta plausible y falsa. Por eso la instrucción le obliga a marcar "sin fuente" en lugar de rellenar huecos. Cásos así van directos a un humano.
• Casos que no se delegan. Reclamaciones legales, bajas, incidencias con clientes enfadados o cualquier tema con implicación económica o reputacional: triaje sí, borrador quizá, decisión y redacción final siempre humanas.
• Sesgo de urgencia. Revisa periódicamente que la clasificación de urgencia no esté minusvalorando quejas por el tono contenido de algunos clientes.

Bien acotado, este flujo no reemplaza a tu equipo: le quita el trabajo mecánico para que dedique el tiempo a lo que de verdad necesita criterio humano. Ese es el resultado que buscas, no un robot respondiendo por ti.