B2B Support Tickets · AI · Sistema del Cliente
Diseñar para el usuario
que no quiere estar ahí
Los operadores llegan al portal con una máquina rota y una línea de producción parada. No están buscando explorar — quieren que alguien resuelva su problema, rápido. Así diseñé un sistema de IA para ese momento exacto.
Para quién está diseñado este agente
El operador de planta
Trabaja en el piso de producción de una planta industrial. Cuando una máquina falla, es el primero en enterarse — y el primero en sentir la presión de arreglarla. No es un usuario digital nativo. Accede al portal desde un teléfono o una terminal compartida. Llega ya frustrado.
Su mayor miedo: abrir un ticket y no recibir respuesta.
Lo que necesita: sentir que alguien lo está escuchando — de inmediato.
Lo que rompe su confianza: un chatbot que se siente como un filtro, no como un ayudante.
Decisiones de diseño — lado del cliente
La primera decisión de diseño fue arquitectónica: ¿un asistente unificado para ambos usuarios, o dos sistemas especializados con identidades distintas?
Un sistema único no optimizaba para nadie. El operador bajo presión y el técnico de soporte gestionando 30 tickets simultáneos tienen contextos, urgencias y lenguajes completamente diferentes. Diseñar un sistema para ambos significaba diseñar una experiencia mediocre para cada uno.
La decisión: dos sistemas con identidades separadas, roles claros y un canal de contexto compartido entre ellos. El operador nunca ve el sistema del técnico. El técnico nunca interactúa con el asistente del operador. Pero ambos trabajan sobre el mismo ticket, alimentándose mutuamente.
El trade-off aceptado: mayor complejidad de diseño e implementación. Dos identidades que mantener, dos flujos que testear, dos conjuntos de guardrails que definir. Justificado porque la experiencia de cada usuario mejoró drásticamente.
Momentos — lado del cliente
Momento 1
La bienvenida contextualizada
El operador entra al portal. En vez de un formulario vacío o un genérico '¿Cómo puedo ayudarte?', el asistente ya sabe quién es y qué máquinas tiene. Ese primer mensaje personalizado es la primera demostración de que el sistema es inteligente — y de que no lo va a hacer arrancar de cero.
El asistente no pregunta — propone.
El primer mensaje se construye a partir del contexto ya disponible: nombre de la empresa, lista de máquinas, último ticket y su resolución. El operador no escribe una sola palabra antes de sentirse reconocido.
Las opciones guiadas reducen la carga cognitiva.
En vez de un input vacío, el asistente ofrece tres caminos basados en los escenarios más probables. Un operador bajo presión no quiere escribir — quiere elegir y avanzar.
El ID del agente es visible por diseño.
aparece en la interfaz como una decisión de transparencia — el operador puede ver qué agente está interactuando con él. client.triage.v1 En producción, también alimenta directamente el sistema de trazabilidad.
Momento 2
El ticket construyéndose en tiempo real
A medida que el operador describe el problema, el ticket aparece visible en la misma pantalla, llenándose automáticamente. El usuario ve que lo que dice se está registrando. Ese solo momento elimina el miedo principal: que su descripción se pierda.
El ticket siempre está visible — nunca es una promesa.
Cada respuesta del operador llena inmediatamente un campo en el panel derecho. El usuario no confía en el sistema porque se lo dice — confía porque lo ve funcionando.
Los campos vacíos importan tanto como los llenos.
'Esperando respuesta...' comunica que el sistema sabe lo que todavía necesita — no que se olvidó de preguntar. Esa distinción es lo que separa a un asistente bien diseñado de un chatbot.
El indicador de progreso responde la pregunta implícita.
Un operador bajo presión — con una línea de producción parada — necesita saber que la conversación avanza. La barra de progreso al 65% comunica: estamos por llegar, no dando vueltas.
Momento 3
La transición — cerrar con control
El asistente cierra la conversación y confirma el ticket creado. No es una pantalla de error, no es una disculpa — es una pantalla de cierre que transmite control y claridad. El operador sabe quién tiene su caso, qué prioridad tiene y qué pasa después.
El cierre es una entrega, no una derrota.
La tarjeta de confirmación no dice 'No pude ayudarte.' Dice 'Tengo todo lo que el equipo necesita para actuar.' El lenguaje es deliberado — el sistema trabajó para Jorge, no en su contra.
El divisor temporal elimina la ambigüedad.
Marcar exactamente cuándo se creó el ticket responde la pregunta implícita que todo operador bajo presión hace: ¿realmente se envió?
El input deshabilitado cierra el contrato conversacional.
Jorge sabe que esta conversación terminó — limpiamente, no de golpe. El botón 'Caso nuevo' le da control sin reabrir un loop cerrado.
Features del agente — sistema del cliente
Features core
- ›Guía la descripción del problema a través de preguntas contextuales — no formularios abiertos
- ›Reconoce códigos de error directamente del input — no necesita preguntar qué significa E-11
- ›Detecta lenguaje de urgencia extrema y escala inmediatamente
- ›Construye el ticket en tiempo real — visible para el operador en todo momento
- ›Pre-carga datos de la máquina, fecha de instalación e historial de tickets automáticamente
- ›Responde consultas generales sin abrir un ticket — stock, cronogramas de reparación, estado de tickets previos, procedimientos de mantenimiento
Features extendidos
- ›Diagnóstico por imagen y video — el operador fotografía o filma el problema, el agente identifica el componente afectado
- ›Análisis de audio ambiental — detecta anomalías en el sonido de la máquina antes de que el usuario las describa
- ›Detección proactiva vía integración con sensores IoT — el agente abre el ticket antes de que el operador reporte el problema
- ›Modo voz — para operadores con las manos ocupadas en el piso de producción
- ›Detección de recurrencia — si el mismo síntoma aparece tres veces en 60 días, alerta al equipo de soporte sobre una causa raíz no resuelta
- ›Simulador de impacto — estima el costo de producción del tiempo de inactividad antes de crear el ticket, contextualiza la urgencia
- ›Checklist de seguridad — si el problema involucra riesgo para el operador, ejecuta un protocolo de seguridad antes de cualquier otra acción
- ›Resumen automático para supervisor — genera un resumen ejecutivo para el supervisor del cliente cuando se abre un ticket de alta urgencia
- ›Modo offline — funciona con conectividad limitada, sincroniza el ticket cuando se restablece la conexión
- ›Multilenguaje automático — detecta el idioma del usuario y opera en él sin configuración
Evals — sistema del cliente
Antes del lanzamiento — lo que definí
Clasificación de urgencia
Dado un conjunto de descripciones de problemas, ¿el agente clasifica correctamente urgencias alta, media y baja? Umbral mínimo para ir a producción: 90% de precisión en urgencias altas — un falso negativo en una línea de producción detenida tiene costo real.
Cumplimiento de guardrails
¿El agente inventa procedimientos técnicos cuando tiene información insuficiente? ¿Promete tiempos de respuesta? ¿Minimiza urgencias descritas como críticas? Cualquier violación de guardrails en evals bloqueó el lanzamiento.
Calidad del contexto generado
¿El ticket producido por la conversación tiene suficiente información para que el técnico actúe sin preguntar nada? Medido con una rúbrica de 8 campos — umbral: 75% de campos completos en promedio.
Calibración
¿El nivel de confianza del agente se correlaciona con su precisión real? Un agente que dice 90% y acierta el 60% de las veces es más peligroso que uno que dice 60% y acierta el 60% de las veces.
En producción — lo que monitoreo
Tasa de escalamiento por agente
Si client.triage.v1 escala demasiado, el umbral de urgencia está mal calibrado. Si escala muy poco, las conversaciones están terminando en frustración.
Tasa de abandono del portal
Si los usuarios se van a mitad de conversación, el flujo tiene demasiada fricción.
Completitud promedio de contexto
Porcentaje de campos llenos por ticket en promedio. Si baja del 70%, el agente está haciendo las preguntas equivocadas.
Violaciones de guardrails en producción
Alertas en tiempo real cuando un agente produce contenido que viola las reglas definidas.
Impacto — perspectiva del operador
−60%
Abandono del portal
Los operadores bajo presión se quedan en el sistema porque el asistente los guía, no los filtra.
4
Intercambios hasta el ticket
El operador nunca llena un formulario. En cuatro turnos conversacionales, el ticket se crea, se confirma y el operador sabe qué pasa después.
−40%
Rondas de ida y vuelta
Los tickets llegan con el 75–88% del contexto pre-completado. Los técnicos actúan en vez de preguntar.
+25
Puntos NPS
Satisfacción post-ticket en situaciones de alta urgencia. El operador que llega con una línea de producción parada y en tres minutos tiene un ticket confirmado — ese operador confía en el sistema.
Métricas proyectadas basadas en benchmarks de la industria.