La mayoría de los clientes particulares de Fixlab llegaban por WhatsApp, con texto y notas de voz, y el equipo de atención los gestionaba junto al email, las llamadas y los mensajes dentro de la plataforma. A primera vista las preguntas parecían complejas. Qué documentación necesita una certificación depende de la reforma concreta y del vehículo específico, así que una sola conversación podía ramificarse en muchas condiciones: el año y modelo del coche, el tipo de reforma, qué fotos y certificados aplican, o si un cambio concreto es siquiera viable.
La mayoría de esas preguntas, pese a la ramificación, no necesitaban el criterio de un ingeniero. Con una base de conocimiento bien estructurada, puedes decirle a un cliente exactamente qué hace falta para cambiar los faros o añadir una bola de remolque: el año, el modelo, estos documentos, estas fotos. Se recopila, se registra como solicitud de reforma, y un ingeniero solo tiene que verificar y certificar.
Una minoría de casos sí necesita criterio real: convertir una furgoneta en camper con cama, estanterías y una placa de gas, o leer una foto para decidir si algo se puede certificar siquiera. Esos deben llegar a una persona. La mayoría, de alto volumen y que sigue un patrón, no debería tener que hacerlo.
Atención al cliente atendía todo lo que entraba por WhatsApp. Mucho podían responderlo al momento, a menudo un simple «sí, puedes seguir adelante, y vas a necesitar XYZ», y parte requería una consulta rápida con un ingeniero. Rara vez era la parte difícil del trabajo, pero el puro volumen apartaba al equipo del trabajo donde más valor aportan. Las respuestas aún podían tardar un día o más, más en temporada alta y fuera del horario laboral, así que los clientes insistían por varios canales, a menudo reenviando la misma información y teniendo que darla dos veces. El soporte dedicaba una gran parte de su tiempo a una pequeña parte del valor, y los clientes terminaban el proceso poco satisfechos aun cuando el trabajo en sí era sólido.
Una puerta de entrada en WhatsApp que responde al instante lo que se puede responder, recopila la documentación correcta, abre la solicitud de reforma en la plataforma e incorpora a una persona solo en los casos que de verdad la necesitan. Eso libera al equipo para dedicar su criterio donde de verdad hace falta: reformas complejas y clientes premium.
Durante las pruebas se usó Telegram. En producción, Fixi hace cuatro cosas, cada una algo que el taller hacía antes a mano.
Fixi responde sobre certificación de vehículos usando los criterios propios del taller en vez de conjeturas genéricas. La base de conocimiento completa vive en el contexto de trabajo del modelo, así que las respuestas se mantienen consistentes en vez de irse desviando.
Cuando un cliente está listo, Fixi lo verifica en la plataforma de Fixlab y abre una solicitud de certificación directamente a través de la API de la plataforma, recogiendo los datos que el taller necesita para actuar.
Los clientes suelen enviar fotos y notas de voz en vez de párrafos ordenados. Fixi lee imágenes y transcribe audio para que la conversación fluya, y agrupa los mensajes en ráfaga en un único turno coherente en vez de responder a fragmentos.
Cuando un caso necesita a una persona, Fixi lo escala al Slack del equipo con la conversación completa adjunta como una transcripción limpia. La persona toma el relevo, el cliente no nota la costura, y al resolverse Fixi retoma la conversación con el contexto intacto.
Un middleware de mensajería va delante y se encarga de todo lo que no es conversación. Detrás, un agente conversacional autónomo lleva el diálogo. Cada uno hace aquello en lo que es bueno.
No estamos atados a un solo modelo. Usamos Claude (Sonnet y Opus), Gemini y ChatGPT, aprovechando cada uno donde más valor aporta. Las conversaciones de certificación están cargadas de condiciones y excepciones, y una sola puede depender de varias a la vez, así que elegir el modelo adecuado para cada trabajo es lo que mantiene las respuestas correctas en vez de que solo suenen plausibles. La mezcla de modelos es parte de la fiabilidad, no un alarde técnico.
Si el agente no responde a tiempo, el cliente recibe una disculpa y el caso se escala a una persona automáticamente. Las llamadas de red se reintentan ante fallos transitorios.
El objetivo nunca fue una demo ingeniosa. Era algo que aguanta un lunes por la mañana, con clientes reales esperando.
No lanzamos y a ver qué pasa. Antes de entrar en producción, Odysi y Fixlab acordaron una prueba de aceptación por escrito: un conjunto de referencia de 50 escenarios reales que cubrían la identificación del cliente, preguntas de conocimiento, la creación completa de solicitudes, el escalado y la resolución. El umbral era explícito: cero fallos críticos y al menos un 80 % de aprobados.
El sistema pasó a producción solo después de superar ese umbral, y después de validar de principio a fin el ciclo completo de conversación (escalado a una persona y vuelta). Esa disciplina es lo importante. Un sistema conversacional es fácil de enseñar en una demo y difícil de dar por fiable. Acordar la prueba de antemano, por escrito, con el cliente, es como conviertes «parece que funciona» en «lo ha superado».
Fixi superó su prueba de aceptación y se puso en marcha. La arquitectura completa está validada en los cinco caminos de conversación, incluidos el traspaso a una persona y la reanudación.
Como el sistema acaba de lanzarse, todavía se están recopilando datos de uso real. Actualizaremos este caso con el rendimiento de campo a medida que llegue, con números reales en vez de estimaciones.
Mejor gestión de archivos en el traspaso a una persona.
Mayor enriquecimiento del contexto del cliente desde la plataforma.
Refinamiento continuo de la lógica central de conversación a medida que el uso real muestra dónde ayuda más.
Un pequeño estudio de producto. Prototipamos, automatizamos y lanzamos.
Ser pequeños es la ventaja: trabajas directamente con quienes construyen la cosa, y nos importa más algo que aguante en producción que algo que quede bien en una presentación.