Por qué lanzar un producto de seguro suele llevar entre 6 y 18 meses, y cómo definirlo como un único manifiesto reduce ese ciclo a días. Incluye checklist de lo que necesitas tener listo.
En muchas aseguradoras, MGAs y brokers, lanzar un producto nuevo es un proyecto que se mide en trimestres. Entre que el área comercial detecta una oportunidad y el primer cliente puede cotizar y emitir, es habitual que pasen entre 6 y 18 meses. Para cuando el producto sale, el mercado ya se movió, el canal que lo pidió perdió interés o la competencia llegó primero.
El problema rara vez es el producto en sí. Una cobertura de hogar, un seguro de bicicletas o un accidentes personales no son técnicamente complejos. Lo que demora es el camino que recorre la definición del producto hasta convertirse en software.
Dónde se van los meses
Si miras un lanzamiento típico de punta a punta, el tiempo se reparte en etapas que se repiten casi siempre en el mismo orden:
- Relevamiento de requisitos: producto, suscripción, legales y comercial escriben un documento que intenta describir todo: qué datos se piden, qué coberturas hay, qué reglas aplican.
- Traspaso actuarial: la tarifa vive en una planilla. Alguien tiene que interpretarla y traducirla a código, celda por celda, con todas las ambigüedades que eso implica.
- Sprint de desarrollo: el equipo de IT construye pantallas, validaciones, el motor de cálculo y la emisión. Compite por prioridad con todo lo demás que tiene en el backlog.
- QA: se descubre que el cálculo no coincide con la planilla, que un campo obligatorio no se valida o que un impuesto se aplica sobre la base equivocada. Vuelta al paso 2.
- Integración por canal: cada broker, partner o fintech necesita su propia integración, su propio formulario y sus propias pruebas.
- Rollout: capacitación, documentación, ajustes de último momento y una lista de pendientes que pasa a la fase dos.
Cada etapa tiene un traspaso entre equipos, y cada traspaso es una oportunidad de malentendido. El documento de requisitos dice una cosa, la planilla otra y el código una tercera. Nadie tiene una única fuente de verdad sobre qué es el producto.
El producto como un único manifiesto
La alternativa es dejar de describir el producto en documentos que después alguien tiene que interpretar, y definirlo directamente en un formato que la plataforma ejecuta. En quore, eso es el manifiesto: un único archivo estructurado que contiene todo lo que hace falta para cotizar y emitir.
- Variables: los datos que se piden al cliente, con su tipo, rango y opciones. Por ejemplo, edad entre 18 y 75, o provincia dentro de una lista cerrada.
- Coberturas con fórmulas: cada cobertura tiene una fórmula legible que calcula su prima a partir de las variables.
- Tablas de tarifas: valores por zona, edad, plan o cualquier dimensión, consultables desde las fórmulas.
- Vigencia y cuotas: si el producto es anual, mensual o en cuotas, y cómo se distribuye el pago.
- Impuestos: cada impuesto o recargo con su tipo y su valor, aplicado en el orden correcto.
- Pasos de cotización: cómo se agrupan las preguntas y en qué orden se muestran.
- Reglas de emisión: si la póliza se activa automáticamente o queda pendiente hasta que se cumplan condiciones, como una inspección o una validación externa.
Cuando el producto está definido así, las etapas del ciclo tradicional se comprimen. No hay traducción de planilla a código porque la fórmula es la tarifa. No hay sprint de pantallas porque el formulario se genera a partir de las variables y los pasos. No hay una integración nueva por canal porque el mismo producto se publica en la API, en un widget embebible y en un portal con la marca del canal.
Qué cambia para cada equipo
Producto y suscripción pasan a ser dueños del manifiesto. Pueden ajustar una regla o un valor sin abrir un ticket. El área actuarial revisa fórmulas que se leen casi como la planilla original, y puede probarlas con casos reales en un simulador antes de publicar. IT deja de construir cada producto desde cero y se concentra en lo que sí requiere ingeniería: integraciones con sistemas core, pagos y seguridad.
El control no se pierde. Los cambios se hacen sobre un borrador y solo llegan a producción cuando alguien publica una versión. Las pólizas emitidas quedan asociadas a la versión con la que se cotizaron.
Checklist: qué tener listo antes de empezar
La velocidad depende en buena parte de la preparación. Si tienes estos elementos definidos, armar el producto es cuestión de días:
- Lista de datos a pedir al cliente, indicando cuáles afectan el precio y cuáles solo se necesitan para emitir.
- Coberturas y sumas aseguradas, con el criterio de cálculo de cada una.
- Tablas de tarifas actualizadas, con dimensiones claras (por ejemplo, zona y rango de edad).
- Impuestos y recargos que aplican, con su base de cálculo.
- Modalidad de vigencia y opciones de pago: anual, mensual, cantidad de cuotas.
- Reglas de emisión: qué se activa en el momento y qué requiere una validación previa.
- Canales de lanzamiento: venta directa, brokers, partners embebidos.
- Un set de casos de prueba con el resultado esperado, para validar en el simulador.
El cuello de botella casi nunca es la complejidad del producto, sino la cantidad de veces que su definición cambia de manos.
Lanzar en días no significa saltarse controles. Significa eliminar los traspasos que no agregan valor y tener una única fuente de verdad que todos los equipos pueden leer, probar y aprobar.
¿Tienes un producto esperando en el backlog?
Agenda una demo y te mostramos cómo quedaría definido como manifiesto en quore.