B2B Support Tickets · AI · Sistema del Cliente
Diseñar para el momento
de mayor presión
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.
−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 obtenidas durante el lanzamiento beta con un grupo reducido de operadores y técnicos. Los resultados en escala pueden variar.
El operador de planta
Trabaja en el piso de producción. Cuando una máquina falla, llega al portal ya frustrado, desde un teléfono o terminal compartida, con una línea de producción parada. No es un usuario digital nativo y no tiene tiempo para explorar.
Decisiones de diseño — lado del cliente
Decisión 1
Dos sistemas, no uno
Un asistente unificado no optimiza para nadie. Dos sistemas con identidades distintas y un canal de contexto compartido.
Leer más →Decisión 2
Identidad del agente: comportamiento, tono e IDs
Cada agente tiene un ID funcional y versionado. Transparencia para el usuario, trazabilidad para el equipo.
Leer más →Decisión 3
Diseño de contexto: qué sabe el agente y cuándo
Qué sabe el agente antes de la primera pregunta, qué construye durante la conversación, y qué deliberadamente no sabe.
Leer más →Decisión 4
Diseñar para el usuario bajo presión
Máximo cuatro intercambios. El ticket siempre visible. El asistente guía, no filtra.
Leer más →Decisión 5
Handoff: cuándo el sistema del cliente se retira
Tres triggers de escalamiento. El sistema se retira cuando debe, no cuando falla.
Leer más →Decisión 6
Context y prompt design
El comportamiento del agente no se configura en el código. Se diseña en el contexto que recibe antes de la primera interacción y en las instrucciones que gobiernan cada decisión que toma.
Leer más →El flujo de interacción
Tres decisiones simultáneas en cada intercambio: qué contexto capturar, qué urgencia tiene el problema, y si puede resolverse en el chat o necesita un técnico.
El cliente nunca ve la complejidad — solo una conversación
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.