Todo lo que se ve en la demo son piezas nativas de la plataforma: no hay software aparte, ni un servidor de terceros manteniendo el sistema vivo. Esto importa porque significa que la corredora es dueña de su propia operativa y la puede ver, auditar y modificar.
Existen los objetos personalizados: entidades propias, con sus campos, sus registros y su ficha, que se asocian al contacto. Un mismo contacto puede tener N pólizas colgando, cada una con su vigencia, su prima y su estado de cobranza, sin pisarse. No hace falta el atajo de meter todo en campos del contacto, que es lo que rompe cuando aparece la segunda póliza.
El disparador “Recordatorio de fecha personalizada” inscribe contactos a partir de una fecha guardada, y su selector de campo incluye los campos de fecha de un objeto personalizado, no sólo los del contacto. Se le indica cuántos días antes disparar, así que 60, 30 y 15 días antes del fin de vigencia salen los tres del mismo mecanismo. Es exactamente lo que hacía falta: sin esto, las renovaciones automáticas no salían.
El contacto sigue siendo la persona. La póliza es un registro aparte que cuelga de ella, y el siniestro cuelga de la póliza. Así una persona puede tener el auto, la casa y la garantía de alquiler al mismo tiempo, cada una con su propia vigencia.
Un solo mecanismo cubre los tres avisos de renovación. El disparador mira la fecha Vigencia hasta de cada póliza y arranca el flujo la cantidad de días antes que se le indique.
| Lo que pediste | Cómo se hace |
|---|---|
| Varias pólizas por cliente, sin pisarse | Objeto personalizado Póliza asociado al contacto. Cada póliza es un registro con sus propios campos y su propia vigencia. |
| Ver todas las pólizas de un cliente de un vistazo | Los registros asociados aparecen en la ficha del contacto. Es la pantalla de expediente de la demo. |
| Aviso solo a 60, 30 y 15 días | Tres workflows con el disparador recordatorio de fecha personalizada apuntando a Vigencia hasta, cada uno con su cantidad de días de anticipación. |
| A los 60, tarea interna. A los 30 y 15, WhatsApp | El de 60 usa la acción de crear tarea asignada a la corredora. Los de 30 y 15 usan la acción de enviar plantilla de WhatsApp, editable desde el panel. |
| Si marco renovada, que se corte | Un campo Renovada en la póliza. Cada workflow arranca con una condición que lo termina si ya está marcada. Marcarla también se puede automatizar con la acción de actualizar registro. |
| Lista de “qué me vence este mes”, filtrable por ramo | Vista guardada sobre el objeto Póliza, filtrando por rango de Vigencia hasta y por Ramo. Cada usuario puede guardar las suyas. |
| Estado de pago por póliza, no por cliente | El estado de cobranza es un campo de la póliza, no del contacto. Por eso una persona puede estar al día en el auto y deber la del hogar. |
| Aviso de cuota impaga, revisado antes de salir | El workflow arma el mensaje y, en vez de enviarlo, crea una tarea de aprobación con el texto listo. Recién al aprobarla sale el WhatsApp. Se puede apagar y que salga directo. |
| Lista de deudores al día | Vista sobre Póliza filtrada por estado de cobranza, ordenada por antigüedad de la deuda. |
| Tablero de siniestros por etapas | Un pipeline con las cinco etapas. Cada siniestro es una oportunidad vinculada a su póliza, y se arrastra de columna a columna. |
| Alerta si un siniestro queda 7 días sin movimiento | Workflow con disparador de oportunidad estancada a los 7 días en la etapa: crea la tarea y avisa. |
| Importar la cartera desde el Excel de MAPFRE | Importación por archivo sobre el objeto Póliza, con emparejado de columnas. Se hace una vez y después se repite el mismo mapeo. |
| Subir el PDF y que se completen los campos | El PDF se lee con IA y los campos extraídos se escriben en la póliza. Es la pieza que más ajuste pide: hay que calibrarla contra los formatos reales de MAPFRE antes de confiarle la carga. |
| Reportes exportables a Excel | Tablero con widgets sobre el objeto Póliza (vencimientos por mes, producción del período, reparto por ramo) y exportación de cualquier vista. |
Los objetos personalizados se habilitan en la cuenta. No vienen prendidos por defecto en toda subcuenta; es un paso de configuración previo, no un obstáculo.
El disparador inscribe al contacto, no al registro. El flujo corre en contexto de la persona y lee los datos de la póliza asociada. En la práctica no cambia nada de lo pedido, pero condiciona cómo se arman las condiciones.
La lectura del PDF hay que calibrarla. Es lo único de la lista que no es “configurar y listo”: conviene arrancar con el Excel, que es exacto, y sumar el PDF después con una tanda de pólizas reales para medir qué tan fino queda.
Capacidades verificadas contra la API y el constructor de la plataforma el 19 de agosto de 2026. Los datos de la demo son simulados: nombres, documentos, matrículas, números de póliza y de siniestro no corresponden a personas reales.