B2B Support Tickets · AI · Sistema Técnico
Diseñar para el experto
que no puede arrancar de cero
El técnico que gestiona 30 tickets simultáneos no necesita más información — necesita la información correcta, ya estructurada, en el momento en que abre el caso. Así diseñé un sistema de IA para esa restricción exacta.
Para quién está diseñado este agente
El técnico de soporte
Trabaja en el equipo de soporte del fabricante. Gestiona entre 15 y 40 tickets abiertos simultáneamente. Expertise técnico profundo en las máquinas que soporta. El problema no es el volumen — es que cada ticket llega incompleto. Dedica el 40% de su tiempo yendo y viniendo con el cliente solo para entender qué pasó realmente.
Su principal frustración: saber la solución pero no tener suficiente contexto para confirmarla.
Lo que necesita: abrir un ticket e inmediatamente saber qué pasó, qué se intentó, y cuál es el camino más probable.
Lo que rompe su flujo de trabajo: arrancar de cero en cada caso — hacer preguntas que el cliente ya respondió, en otro lado.
Decisiones de diseño — lado técnico
La decisión arquitectónica de construir dos sistemas separados — uno por usuario — se tomó precisamente por este usuario. Un asistente unificado que intentara servir tanto al operador como al técnico no habría optimizado para ninguno.
El técnico es un experto. No necesita empatía ni preguntas guiadas — necesita precisión, velocidad e información accionable. Darle la misma interfaz que al operador habría sido un fallo de diseño.
La decisión: un sistema dedicado de agentes que habla el lenguaje del técnico — códigos de error, modelos de máquina, historial de intervenciones, hipótesis de diagnóstico — desde el primer segundo que se abre el ticket.
Momentos — lado técnico
Momento 4
El ticket enriquecido
El técnico abre el ticket y en vez de dos líneas vagas encuentra un resumen estructurado: problema, urgencia, contexto de la máquina, intentos previos. Todo listo para actuar — sin hacerle una sola pregunta al cliente.
El técnico nunca arranca de cero.
Para cuando Ricardo abre el ticket, el asistente ya cruzó la descripción del cliente con el historial completo de la máquina. El grid de contexto — código de error, estado de producción, síntoma, intentos previos — es el output de ese trabajo, no un formulario que llena el técnico.
El badge ctx: 88% es una decisión de diseño.
Comunica de un vistazo qué tan completo es el contexto entrante — para que el técnico sepa inmediatamente si puede actuar o necesita indagar más. Confianza en los datos, antes que confianza en el diagnóstico.
La nota del agente conecta puntos que el técnico podría perder.
diag.analysis.v1 vinculando el E-11 actual con el E-04 de hace 12 días es exactamente el tipo de patrón que se pierde cuando los técnicos gestionan 30 tickets simultáneamente. El agente tiene el historial completo — y lo usa.
Momento 5
La sugerencia con nivel de confianza
El asistente técnico sugiere una solución probable con un porcentaje de confianza explícito, su fuente y un plan de acción paso a paso. El técnico decide si adoptarla, ajustarla o descartarla — el asistente nunca sobreescribe.
78% no es un número decorativo.
Es un guardrail en acción — el agente no dice 'el rodamiento está roto.' Dice 'esta es la causa más probable en base a lo que sé, pero hay algo que no puedo confirmar todavía.' Esa distinción cambia cómo Ricardo actúa sobre la sugerencia.
El panel de razonamiento hace de la explicabilidad un feature de UX.
Ricardo no tiene que confiar ciegamente en la sugerencia — puede ver exactamente por qué el agente llegó a esa hipótesis, qué tickets referenció y qué variable baja la confianza. Esa transparencia es lo que construye confianza con el tiempo.
Adoptar · Ajustar · Descartar preserva la autoridad del técnico.
El asistente sugiere — Ricardo decide. Esa decisión de diseño es intencional: en entornos industriales de alto riesgo, el juicio del experto siempre debe poder sobreescribir la recomendación del sistema.
Momento 6
El escalamiento con contexto completo
El técnico escala a un especialista. Con una acción, el sistema genera un paquete de escalamiento completo — conversación, hipótesis descartadas, scores de confianza, notas del técnico. El especialista no arranca de cero.
Este momento cierra el loop de la decisión de confianza al 78%.
Ricardo descartó la hipótesis del agente — exactamente lo que el nivel de confianza explícito estaba diseñado para habilitar. El sistema no falló. Le dio a Ricardo la información correcta para tomar la decisión correcta.
100% de contexto transferido significa que Pablo nunca hace una pregunta que ya fue respondida.
El paquete de escalamiento incluye la conversación completa, la hipótesis descartada y por qué, la sugerencia original y su score de confianza, y la nota propia de Ricardo. Pablo recibe un briefing — no un ticket.
La traza del sistema es una decisión de diseño, no solo un log técnico.
Cada agente que tocó el ticket aparece con su ID, acción y timestamp. Cuando algo sale mal en producción, esa traza es lo primero que el equipo revisa. Diseñarla para que sea legible es parte del trabajo.
Features del agente — sistema técnico
Features core
- ›Recibe ticket enriquecido del sistema del cliente como objeto estructurado — sin releer historial de conversación
- ›Cruza el ticket con el historial completo de la máquina — todos los tickets previos, resoluciones y registros de servicio
- ›Sugiere diagnóstico probable con nivel de confianza explícito y fuente
- ›Ayuda a redactar la respuesta al cliente — tono y precisión técnica calibrados
- ›Gestiona agenda y disponibilidad del técnico para visitas en sitio
- ›Detecta cuándo se necesita escalamiento a especialista y rutea automáticamente
Features extendidos
- ›Estimación de tiempo de resolución — basada en tickets similares resueltos, estima cuánto debería tomar este tipo de problema vs. el SLA del cliente
- ›Detección de patrones cross-cliente — si cinco clientes reportan el mismo síntoma en el mismo modelo de máquina en 30 días, marca un posible defecto de fabricación
- ›Preparación de kit pre-visita — antes de una visita en sitio, lista las partes, herramientas y documentación que el técnico probablemente necesite
- ›Verificación de stock en tiempo real — cuando se sugiere una parte, verifica disponibilidad en el depósito más cercano y dispara orden de compra si no hay stock
- ›Generación de reporte post-intervención — cuando el técnico cierra el ticket, redacta el reporte de intervención automáticamente
- ›Detección de garantía — antes de que el técnico actúe, verifica si la máquina está en garantía y si el tipo de falla está cubierto
- ›Asistente en sesión — una vez en sitio, el técnico describe hallazgos en tiempo real, el agente ajusta pasos sugeridos en consecuencia
- ›Predicción de próxima falla — basada en historial y patrones de uso de la máquina, sugiere chequeos proactivos durante la visita actual
- ›Asignación óptima de técnico — evalúa qué miembro del equipo tiene el historial de resolución más relevante para este tipo de falla específico
- ›Taxonomía de causa raíz — cada ticket cerrado contribuye datos estructurados de causa raíz a una taxonomía creciente
- ›Cotización preliminar automática — si la resolución requiere partes adicionales o una visita de seguimiento, genera una cotización preliminar para aprobación del cliente
Evals — sistema técnico
Antes del lanzamiento — lo que definí
Precisión de hipótesis
Dado un conjunto de tickets históricamente resueltos con diagnósticos conocidos, ¿el agente sugiere la hipótesis correcta? Medido como precisión top-1 y top-2. Umbral mínimo antes de producción: 75% top-1 en tickets de alta urgencia.
Calibración de confianza
¿El nivel de confianza que reporta el agente se correlaciona con su precisión real? La calibración se testea por separado de la precisión — un agente bien calibrado al 65% de confianza es más confiable que uno sobreconfiado al 90%.
Alucinaciones técnicas
¿El agente inventa referencias a tickets que no existen, o cita pasos del manual que no están en la documentación? Tolerancia cero. Cualquier alucinación en evals bloquea el lanzamiento de esa versión del agente.
Precisión de triggers de escalamiento
¿El agente escala cuando debe — y solo cuando debe? Testeado con casos límite: problemas cerca del umbral de confianza, combinaciones de falla inusuales, escenarios conocidos que requieren especialista.
En producción — lo que monitoreo
Tasa de adopción de sugerencias
Qué porcentaje de sugerencias de diag.suggest.v1 adopta el técnico sin modificación. Rango saludable: 40–70%. Demasiado alto arriesga confianza ciega. Demasiado bajo señala que las sugerencias no son útiles.
Tiempo hasta primera acción
La métrica de negocio principal. Si el ticket enriquecido está funcionando, el tiempo entre ticket recibido y primera acción del técnico debería disminuir.
Tasa de escalamiento por tipo de falla
Si ciertas categorías de falla escalan consistentemente, el agente carece de cobertura para esos casos — señala un gap en la base de conocimiento.
Violaciones de guardrails
Alertas en tiempo real cuando un agente produce contenido que viola las reglas definidas — logueado con agent ID, input y output para el próximo ciclo de evals.
Impacto — perspectiva del técnico y fabricante
−50%
Tiempo de resolución
Los tickets llegan con el 75–88% del contexto pre-completado. La primera respuesta del técnico es una acción, no una pregunta.
+35%
Capacidad del equipo
El mismo equipo maneja más casos — sin sumar personal. El tiempo ahorrado en ida y vuelta se redirige a resolución.
+28%
Resolución en primera visita
El kit pre-visita y la sugerencia de diagnóstico hacen que el técnico llegue con las partes correctas — no descubriendo en sitio qué necesita volver a buscar.
El valor real para el fabricante
Cada ticket resuelto alimenta el sistema de diagnóstico. Cuantos más casos procesa el agente, más precisas se vuelven sus hipótesis — para las máquinas específicas de ese fabricante, sus patrones de falla y su base de clientes. El sistema se vuelve más inteligente con el tiempo. Eso no es un feature — es el moat.
Métricas proyectadas basadas en benchmarks de la industria.