Los bots de las aseguradoras atienden pólizas, pero no venden. Construí el que ocupa la etapa que nadie asesora en el chat
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, que mide cuántos aciertos gana el modelo por cada error que suma, para el router de dudas, un eval con macro-F1 para el clasificador de emociones). Está desplegado en una demo pública que podés probar en un clic.
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 | Asesores y productores, por teléfono o en persona | El que arranca por la web compara solo |
| Cotizar | Cotizador web (24 hs) o asesor por WhatsApp | Formulario frío, o dictarle el formulario a una persona y esperar |
| Contratar | Web / asesor / productor | |
| Usar y gestionar (posventa) | Letizia (WhatsApp) + app | Bien resuelto |
Una precisión importante, porque el matiz es la tesis: el asesoramiento existe. Está el asesor del call center y, sobre todo, están los productores asesores, que son el corazón comercial del rubro. Y cotizar por WhatsApp también se puede: lo probé como cliente. Pedí cotizar mi auto aclarando desde el primer mensaje que era usado, sin GNC (el equipo de gas) y de uso particular, y el canal me derivó con una asesora humana. La atención fue correcta, pero el diseño del camino mostró sus costuras: la primera respuesta llegó a los 22 minutos; me pidió todos los datos juntos, como un formulario dictado (DNI, fecha de nacimiento y patente incluidos, antes de ver un precio); me re-preguntó el uso y el GNC que yo ya había aclarado; y la cotización quedó para después. Al día siguiente, un mensaje automático me invitó a contratar 100% online... en los cotizadores web. Una interacción no es una muestra, pero estas fricciones son de diseño del canal, no de la persona: horario y cola, cero memoria del contexto, y el precio siempre diferido.
Lo que no tiene dueño, entonces, no es "cotizar por WhatsApp": es la venta asesorada inmediata, las 24 horas, que respeta lo que ya dijiste y muestra un precio en el momento, reservando al humano para donde agrega valor. Y el dato más interesante del benchmark es que el canal ya está validado: La Caja demostró que WhatsApp le funciona (invirtió en Letizia, ofrece telemedicina por ahí). Falta apuntarlo a esta etapa del embudo.
Antes de apostar, la pregunta obligada: ¿esto le pasa solo a La Caja? Relevé a la competencia (información pública, julio de 2026) y el patrón se confirmó con un detalle revelador: todas invirtieron en canales conversacionales, y ninguna los apunta a venderle al cliente nuevo.
| Aseguradora | Canal conversacional | Para qué lo usan | ¿Venta asesorada en el chat? |
|---|---|---|---|
| La Caja | Letizia (WhatsApp) + asesores en el mismo chat | Posventa: pólizas, bajas, documentación; cotizar deriva a un asesor humano | A medias: lo probé, y es el formulario dictado a una persona (todos los datos juntos, en horario laboral, precio diferido) |
| Zurich | Chatbot de WhatsApp con IA | Atención y siniestros (derivó el 15% de las denuncias telefónicas al chat) | No: venta por teléfono y cotizadores web |
| Allianz | Ally (portal Mi Allianz) + WhatsApp 24/7 | Autogestión de clientes y soporte a productores | No: cotización por formulario web y productores |
| Mapfre | MAIPI (WhatsApp) | Autogestión: pólizas, cuotas, siniestros; incluye cotizar | A medias: solo para clientes ya registrados (exige el celular de la póliza), transaccional y sin comparación asesorada |
| Sancor | Cotizador IA por WhatsApp + PREVI (salud) | El cotizador es para productores; PREVI es autogestión de socios | No para el cliente final: lo conversacional de venta apunta al intermediario |
La lectura fina importa: los movimientos más cercanos (Mapfre cotizando a clientes existentes, Sancor cotizando por WhatsApp para sus productores) confirman que el rubro va hacia ahí, pero dejan vacante el lugar específico: la venta asesorada al cliente que todavía no es cliente, dentro del chat. Ese es el hueco, y es estructural.
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 digital. La apuesta: asesorar, comparar y cotizar dentro del chat, y entregar un lead calificado y tibio al asesor o productor que hoy ya existe. El bot no compite con esa figura: la alimenta con un lead que llega con su cotización armada, en vez de un dato frío de formulario. Y no emite pólizas ni reemplaza al tarifador oficial: su techo, elegido a propósito, es dejar la venta lista para que una persona la cierre.
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 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 modelo de lenguaje, o LLM, anclado a una base de conocimiento). El problema que resuelve es de confianza: un asistente de seguros que inventa una cobertura es un riesgo, no un bug más de una demo. 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á 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: bot.ivandujaut.com. 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.
Si llegaste hasta acá, algo del problema te interesó. Me gusta discutir estas decisiones con gente que las vive de cerca: escribime lo que harías distinto, o agendemos una call.
Ver todos los proyectos