Los bots de las aseguradoras atienden pólizas, pero no venden. Construí el que ocupa la etapa que nadie asesora
No arranqué con una idea de producto, arranqué con una pregunta: ¿cómo te vende un seguro hoy una aseguradora grande? Para responderla en serio hacían falta dos cosas: profundidad en un caso concreto y amplitud en el resto del rubro. Como caso para mirar a fondo elegí una aseguradora líder del mercado argentino, La Caja, y le relevé el sitio público completo: el catálogo, la estructura de planes de cada línea, los canales de atención y sus roles, los cotizadores (auto, hogar, moto), el centro de ayuda. Todo con información pública, separando lo observado de lo que supongo.
El mapa del recorrido del cliente quedó así:
| Etapa del funnel | Quién la atiende hoy | Cómo se siente |
|---|---|---|
| Entender qué me conviene | Nadie con claridad | El cliente compara solo |
| Cotizar | Cotizador web | Formulario, hay que salir a la web |
| Contratar | Web / asesor | |
| Usar y gestionar (posventa) | Letizia (WhatsApp) + app | Bien resuelto |
Los dos extremos están cubiertos. El medio, no. Y el dato más interesante del benchmark: La Caja ya demostró que WhatsApp le funciona (invirtió en Letizia, ofrece telemedicina por ese canal). El canal está validado internamente; lo usan para la etapa equivocada del embudo.
La amplitud vino del resto del paisaje: el caso fue el ancla del análisis, no su límite. Cada decisión de flujo se contrastó contra el rubro completo: los cotizadores de otras aseguradoras y agregadores (Mercantil Andina, comparaencasa, asegurarmiauto) para el diseño de las preguntas; las prácticas de recuperación de carrito abandonado del comercio conversacional para el re-enganche; las políticas reales de WhatsApp Business (la ventana de 24 horas, plantillas, opt-in) para todo lo proactivo; y los patrones de timeout de chatbots de la industria para el manejo de silencios. Cuando más abajo digo "ningún cotizador pregunta esto", es porque los miré, no porque lo supongo.
La regla es no competir donde el incumbente ya es fuerte. Hacer otro bot de posventa sería esfuerzo sin diferencial; la pre-venta conversacional ataca el momento de mayor intención de compra y menor acompañamiento. La apuesta: asesorar, comparar y cotizar dentro del chat, y entregar un lead calificado y tibio. El bot no emite pólizas ni reemplaza al tarifador oficial: su techo, elegido a propósito, es dejar la venta lista para cerrar.
Antes de las features, los principios que filtraron cada decisión:
La cotización es un proceso estructurado y repetible (los cotizadores web ya lo modelan en cuatro pasos); las dudas son abiertas ("¿qué es la franquicia?", "¿cubre granizo?"). Usar solo menús sería rígido; usar solo IA sería impredecible y caro justo donde el error cuesta más, que es en lo que el bot afirma sobre coberturas. Entonces: menús determinísticos para el flujo de cotización, y el modelo de lenguaje para las consultas abiertas, anclado a una base de conocimiento con contenido real relevado del sitio, para no inventar. El trade-off es mantener dos caminos y afinar la frontera entre ambos, y buena parte de las decisiones que siguen son, justamente, refinamientos de esa frontera.
La versión inicial del flujo de auto pedía el año y, en un paso aparte, "¿es 0km o usado?". Un usuario real me lo hizo notar de la peor manera: para un auto 2009 esa pregunta tiene respuesta obvia, y hacerla igual hace que el bot parezca no razonar. Antes de tocar el flujo hice un benchmark de cómo lo resuelven los cotizadores reales (La Caja, agregadores, comparadores): ninguno pregunta la condición por separado. El año la lleva implícita, o el "0km" es una opción dentro del selector de año.
v1: condición como paso propio
"¿Año del vehículo?" y después "¿es 0km o usado?". Para un 2009 la segunda pregunta tiene respuesta obvia: el bot suma un paso y parece no razonar, justo al arranque, donde más se abandona.
v2: el año lleva la condición
Año pasado implica usado y se avanza sin repreguntar. Solo el año en curso es ambiguo, y ahí la repregunta usa el criterio objetivo del negocio: "¿ya está patentado?" (0km significa exactamente sin patentar). Un hecho de sí o no, en vez de un juicio.
El flujo pasó de 8 a 7 pasos para el caso común, y la repregunta del caso ambiguo cambió de un juicio subjetivo a un hecho verificable. Lo que no hice también fue una decisión: no pido el año de patentamiento como dato aparte, porque no mueve el precio (la suma asegurada sale del año de modelo contra la tabla de valores) y sumaría un paso contra todo lo que venía simplificando.
El menú original tenía "Hablar con un asesor" como opción visible. El problema: es la salida fácil, y buena parte de los usuarios la elegiría de entrada, con lo que el bot se canibaliza solo (nunca llega a cotizar ni a calificar el lead, que es su función). La solución no fue esconder al humano, fue cambiar el disparador: el asesor se ofrece cuando el motor de emociones detecta malestar, con un nivel. El clasificador devuelve una etiqueta, no una intensidad, así que el nivel sale de la severidad y la persistencia: el enojo pesa doble y dispara la oferta de una; la frustración necesita sostenerse más de un mensaje, porque una puede ser desahogo y dos son una señal. Una satisfacción resetea el acumulado.
Las salidas se conservan con criterio: escribir "asesor" deriva siempre (el que quiere una persona la tiene, solo que sin promoción), y el cierre post-cotización mantiene "que me llame un asesor" como opción principal, porque ahí el asesor es la conversión, no una fuga. El trade-off honesto: el usuario decidido a hablar con una persona tarda un mensaje más en descubrir cómo.
El menú arrancó con siete opciones y terminó con cuatro acciones simétricas de cotizar. Las tres podas ("Tengo una duda", "Hablar con un asesor", "Comparar los planes") destilaron un principio: el menú lista acciones, no información ni escapes. Una duda se responde escribiéndola; la comparación de planes aparece donde de verdad sirve (en la elección final, con el precio adelante); el asesor se ofrece por contexto. Alrededor del menú se acumularon los demás refinamientos de fricción: un indicador de progreso ("Dato 3 de 7") porque preguntar a ciegas es una causa conocida de abandono, la posibilidad de escribir "volver" para corregir el último dato sin perder el progreso, y un parser que entiende "creo que la segunda me sirve" como la opción 2, con una regla conservadora: si el mensaje huele a pregunta, el bot prefiere repreguntar antes que elegir por vos.
El momento de mayor intención de compra es justo después de ver el precio, y la primera versión lo desperdiciaba: cotizaba y remataba con "escribí menú para otra consulta". El cierre actual empuja hacia adelante: que me llame un asesor (con captura de contacto y el resumen de la cotización, para que el asesor llame tibio y con contexto), contratar online, o comparar otro plan. El contacto pide además un opt-in explícito y separado para re-contactar por WhatsApp, porque la política de la plataforma exige consentimiento afirmativo para mensajes de marketing, y el diseño del re-enganche (retomar una cotización a medias, un "¿seguís ahí?" proactivo, una plantilla fuera de la ventana de 24 horas) está construido sobre las reglas reales de WhatsApp Business, no sobre cómo me gustaría que funcionara.
La parte que más me interesa mostrar: las piezas de IA no se asumen, se miden.
En el motor hay dos piezas semánticas distintas, y cada una resuelve un problema de negocio diferente:
RAG (el LLM anclado a una base de conocimiento). El problema que resuelve es de confianza: un asistente de seguros que inventa una cobertura no es una demo con un bug, es un riesgo. Por eso el modelo no habla de memoria: responde sobre una base de contenido real relevado (los planes, la franquicia con ejemplo, los requisitos por línea). El beneficio acá no es de costo, es que baja las respuestas inventadas en el rubro donde una respuesta inventada cuesta más caro.
El router de embeddings (retrieval sin generación). El problema que resuelve es de costo, latencia y determinismo, y acá sí hay números. La observación de partida: la mayoría de las consultas abiertas son las mismas pocas dudas (qué cubre tal plan, qué es la franquicia, cómo se paga). Pagar una generación del LLM por cada repetición es tirar plata, porque cada consulta abierta arrastra toda la base de conocimiento en el prompt:
| Ruta | Qué procesa | Costo por consulta |
|---|---|---|
| LLM (generación) | ~5.500 tokens de entrada (base de conocimiento + historial) + ~180 de salida | ~US$0,02 |
| Router (embedding + coseno) | ~30 tokens de embedding, sin generación | ~US$0,0000006 |
Con el router resolviendo el 64% de las dudas conocidas sin tocar el LLM, la proyección de ahorro escala con el volumen (supuestos: costo por consulta de arriba, a precios de lista de la API):
| Consultas abiertas / mes | Resueltas por el router | Ahorro mensual estimado |
|---|---|---|
| 10.000 | ~6.400 | ~US$130 |
| 100.000 | ~64.000 | ~US$1.300 |
| 1.000.000 | ~640.000 | ~US$13.000 |
A escala de demo son centavos, y lo digo sin vueltas. Pero el costo es solo un tercio del argumento. Los otros dos pesan igual o más para una aseguradora: latencia (la respuesta canónica sale en milisegundos; una generación tarda segundos, y en un chat la espera se siente) y determinismo: la duda repetida se responde siempre con el mismo texto canónico, revisable y aprobable por compliance, con cero riesgo de alucinación justo en las preguntas que más veces se responden. En seguros, eso último vale más que el ahorro.
El router compara cada consulta contra un corpus de 37 dudas conocidas (181 formulaciones) y responde la canónica solo si la similitud supera un umbral. Elegir ese umbral es un problema de clasificación binaria (¿esta consulta tiene respuesta conocida?), así que se midió como tal, con método leave-one-out y 31 distractores como negativos:
El punto elegido privilegia cobertura con el LLM como red de seguridad: resuelve el 64% de las dudas conocidas con un 97% de acierto de contenido en lo que responde. Y con un criterio del rubro: para un bot de seguros, una respuesta enlatada equivocada es peor que gastar una llamada.
El clasificador de emociones siguió la misma disciplina: se evaluó contra un benchmark propio etiquetado. La versión con el modelo grande daba macro-F1 0.91 pero era un lastre de latencia; el modelo chico da 0.87 sin perder la señal accionable (detecta los 20 mensajes negativos del set, con cero falsos positivos), y encima cuesta un tercio por token. La decisión fue el chico, con el eval en la mano.
Y aprendí una lección de mantenimiento que no vi venir: cuando cambié el flujo de auto, la respuesta canónica de "qué datos pedís" quedó vieja y el router la seguía sirviendo con total confianza. El retrieval no se entera de que el producto cambió debajo: ahora cada cambio de flujo dispara una pasada por el corpus y una re-corrida del eval, porque el umbral se revalida, no se asume.
El embudo también está instrumentado de punta a punta: eventos de inicio y avance de cotización, lead
capturado, cotización aceptada (con canal: asesor u online), derivaciones, dónde se traba la gente
(flow_stuck, con el paso exacto) y hasta dónde se corrige un dato. El dashboard vive en /funnel, en
la misma demo.
Es un bot de pre-venta. No emite pólizas: el precio en firme y la emisión salen del tarifador oficial y la suscripción, con requisitos regulatorios que no corresponde simular. Los precios que muestra son rangos orientativos de un modelo de factores propio, anclados a los precios reales relevados, y se presentan como lo que son. El techo elegido es entregar un lead calificado y tibio, con el resumen de su cotización, listo para que un asesor lo cierre. Definir ese techo temprano ordenó todo lo demás: qué construir, qué medir y qué no prometer.
El conocimiento técnico acá es un medio, y se nota en qué habilitó. La arquitectura es hexagonal (el núcleo no conoce la infraestructura), y eso pagó en términos de producto varias veces: el bot cotiza cuatro líneas con cuatro modelos de pricing distintos (auto por factores, hogar bifurcado según propietario o inquilino, accidentes personales como catálogo de precio publicado, bici como tasa sobre el valor declarado) sin tocar el motor de conversación; el mismo núcleo atiende dos canales (el webhook de WhatsApp y una demo web con estética de WhatsApp, para que cualquiera pruebe sin lista blanca); y la identidad es white-label: la marca es una variable de configuración y el catálogo es una carpeta de markdown, así que cambiar de aseguradora es cambiar contenido y configuración, no código. La demo corre con identidad neutra a propósito: no corresponde presentarse con el logo de una empresa ajena, y una insurtech que la mira tiene que poder proyectarse usándola.
TypeScript de punta a punta con arquitectura hexagonal verificada en CI, Hono como servidor, Claude (AI SDK) para generación y clasificación de emociones, embeddings de OpenAI para el router semántico de dudas, Postgres para leads y eventos, Redis para sesiones, Docker y deploy continuo con demo pública.
La demo está viva: insurance-advisor-bot.onrender.com (plan gratuito: la primera carga puede tardar unos segundos en despertar). Escribí "hola" y arranca el menú. El análisis completo, con las 24 decisiones documentadas y los benchmarks, está en el repositorio.
Publico esto para que me lo discutan:
Si algo de esto te hizo pensar distinto, escribime.
En resumen
¿Cómo te vende un seguro una aseguradora hoy? Salí a responder esa pregunta con datos públicos y encontré un patrón que se repite en el rubro: la posventa está bien resuelta (bots de WhatsApp, apps, autogestión) y la cotización vive en formularios web fríos. El medio, la venta asesorada (el momento en que alguien no sabe si le conviene Terceros Completo o Todo Riesgo), no tiene dueño conversacional. Construí el bot que ocupa esa etapa: compara planes, asesora, cotiza cuatro líneas y captura el lead dentro del chat. Para anclar el análisis en datos reales elegí un caso de estudio concreto, La Caja (su bot Letizia es de los buenos, y aun así atiende, no vende), pero el motor es white-label: la marca es configuración y el catálogo es contenido, así que sirve para cualquier aseguradora. Cada decisión está documentada con su criterio, su dato y su trade-off, y las piezas de IA no se asumen: se miden (una curva ROC para el router de dudas, un eval con macro-F1 para el clasificador de emociones). Está desplegado en una demo pública.