Triaje de emails de soporte con LLM y revisión humana
Las colas de soporte suelen esconder problemas de producto y de operaciones. Peticiones de funcionalidades, informes de bugs, problemas de facturación, dudas de onboarding y problemas urgentes de cuenta llegan a la misma bandeja de entrada o helpdesk.
El triaje con LLM puede ayudar si se diseña como apoyo a la decisión y no como decisión final. La diferencia es operativa, no filosófica: el modelo lee, clasifica y redacta borradores; el humano aprueba y envía. Esa estructura es lo que permite a un equipo de soporte adoptar IA sin exponer la voz de la empresa al mal día de un modelo.
Un primer alcance acotado
El primer sprint debería clasificar mensajes, extraer los detalles clave y preparar un borrador de respuesta para revisión.
Clasificar tipo de mensaje, urgencia, área de producto y tier del cliente
Extraer IDs de cuenta, texto de errores, detalles del plan y acciones solicitadas
Detectar información que falta
Enrutar los tickets a la cola correcta
Redactar respuestas con el tono del producto
El equipo de soporte o de éxito de cliente sigue aprobando la respuesta. El sistema reduce el tiempo de lectura, enrutado y redacción.
Una arquitectura de referencia razonable para el primer sprint:
```
inbound: Gmail API / IMAP / Zendesk webhook / Intercom webhook
→ normalize to Ticket { id, channel, from, subject, body, attachments, customer_id? }
→ enrich: look up customer in CRM/billing, attach plan and recent activity
→ LLM classification (JSON schema):
{
type: "bug" | "billing" | "onboarding" | "feature_request" | "urgent",
urgency: "low" | "normal" | "high" | "critical",
product_area: "...",
customer_tier: "free" | "pro" | "enterprise",
missing_info: ["account_id" | "error_message" | ...],
suggested_queue: "tier1" | "billing" | "engineering" | "csm",
confidence: { type: 0.93, urgency: 0.71, ... }
}
→ RAG step: retrieve top knowledge-base articles, prior tickets, recent release notes
→ LLM draft (with citations to retrieved sources, tone profile, signature)
→ human review queue in a small Next.js admin or directly inside Zendesk macros
→ on approve: send via the original channel, write back to CRM/Zendesk,
log full run for analytics
```
Dos decisiones de diseño que importan:
Contexto del cliente antes de la clasificación. El mismo ticket de un usuario gratuito y de un usuario enterprise no es el mismo ticket. Enriquecer primero mejora tanto el enrutado como la calidad del borrador.
El borrador debe citar. Cada afirmación del borrador (política de reembolsos, disponibilidad de una funcionalidad, paso de troubleshooting) se apoya en un artículo de la base de conocimiento o en una nota de versión. El revisor ve la cita y puede verificarla en segundos.
Qué lo hace seguro
La comunicación con el cliente afecta a la confianza, así que el flujo de trabajo debe mostrar el texto fuente, la confianza y el motivo de cada acción sugerida. Los mensajes de baja confianza deben quedarse en la cola manual.
Salvaguardas concretas que conviene implementar desde el principio:
Ningún mensaje saliente sin una acción humana de aprobación. Basta con un solo clic: lo importante es la auditabilidad.
Perfil de tono por marca. Definido como una guía de estilo breve que se pasa en el prompt, con algunos ejemplos de respuestas aprobadas y rechazadas. Sin él, el modelo cae en una voz genérica de helpdesk.
Lista de temas prohibidos. Los reembolsos por encima de un umbral, el lenguaje legal, las divulgaciones de seguridad y las excepciones de precios se enrutan a una cola más estricta independientemente de la confianza.
Enmascaramiento de PII en el perímetro. Enmascarar patrones tipo tarjeta de crédito, documentos de identidad y tokens OAuth antes de enviar texto al modelo.
Límite de frecuencia por cliente en los borradores automáticos. Incluso con aprobación humana, el mismo cliente no debería recibir cinco respuestas redactadas por IA en una hora.
El equipo de producto también debería tener visibilidad de los bugs repetidos, la UX confusa y los huecos de documentación. Los datos de clasificación son un flujo gratuito de investigación de producto: los clústeres semanales de "missing_info: account_id" apuntan a un bug de onboarding; los picos de "feature_request" en la misma área informan el roadmap.
Qué medir
Haz seguimiento del tiempo de primera respuesta, el tamaño del backlog, la precisión de enrutado, la tasa de aceptación de borradores, la tasa de escalado y las categorías de problemas recurrentes.
Objetivos concretos que han aguantado en pilotos reales:
Tiempo de primera respuesta. Mediana reducida un 40-70% en el primer mes, sobre todo gracias a la preparación instantánea del borrador.
Precisión de enrutado. 90%+ en las cuatro categorías más grandes, medida contra la reclasificación del propio equipo.
Tasa de aceptación de borradores. Un 40-60% aceptados sin editar, otro 20-30% aceptados con ediciones ligeras y el resto reescritos. La tasa "sin editar" es la señal más limpia de confianza.
Tasa de escalado. No debería aumentar. Si lo hace, al modelo se le escapan matices y hay que ajustar el prompt o la política de enrutado.
Tiempo de revisión por ticket. Mediana de tiempo de lectura + decisión. La ganancia está aquí, no en el número absoluto de tickets gestionados.
Si el primer sprint funciona, el mismo patrón puede expandirse al chat in-app, las sugerencias de base de conocimiento, las actualizaciones del CRM y los resúmenes de feedback de producto. El mismo stack de triaje (clasificar, enriquecer, redactar, revisar, registrar) es el sustrato de todos ellos.