En una empresa de previsión exequial, la cartera en mora se mira casi siempre hacia atrás: cuánto se debe, desde cuándo, quién no paga. La pregunta que más dinero y más reputación protege mira hacia adelante: ¿qué contratos van a perder cobertura en los próximos días si nadie hace nada? Porque cuando la regla los inactiva, la siguiente conversación con esa familia puede ser la del fallecimiento.
La respuesta corta: cada semana, cartera debería ver la lista de contratos que cruzarán el próximo tramo de cobertura o el umbral de inactivación en los próximos 14 días, con el último pago, el canal por el que se les cobra y si hubo un intento de cobro fallido. Esa lista no la tiene que construir nadie a mano: los datos ya están en el ERP. Este artículo explica cómo armarla con IA y MCP, quién la usa, qué nunca se automatiza y cómo medir si funcionó.
1. El problema de negocio: la regla corre de noche y nadie se entera
Los sistemas de previsión aplican reglas de mora: tantos días de atraso, el contrato pasa a atrasado; tantos más, a inactivo; tantos más, a retirado. Son reglas necesarias, porque sin ellas la compañía presta servicios a contratos que no pagan. El problema es que la regla actúa sola, todos los días, y la mayoría de los contratos que cruzan el umbral no son de titulares que decidieron dejar de pagar: son un débito que falló, un cobrador que cambió de ruta, una familia que se mudó, una cuota que subió y nadie explicó.
El costo aparece en cuatro frentes. Ingreso: cada contrato inactivado es una cuota recurrente que se deja de cobrar, y recuperarlo después cuesta más que retenerlo antes. Servicio: si ocurre un fallecimiento con el contrato inactivo o con el porcentaje de prestación reducido, la familia recibe una negativa o un servicio parcial en el peor momento. Reputación: esa negativa es la que termina en redes, en la autoridad de protección al consumidor o en un reclamo formal. Y gestión: la dirección ve que la base de afiliados activos baja y no sabe cuánto fue decisión del titular y cuánto fue falta de gestión a tiempo.
2. Los tres umbrales que vigila la lista
Cada contrato de la lista está a pocos días de uno de estos tres cambios. Ordenarlos así le dice a cartera qué es urgente y qué puede esperar a la ruta normal.
| Umbral | Qué cambia para la familia | Quién lo configura | Qué hace cartera |
|---|---|---|---|
| Próximo tramo de cobertura | El porcentaje de prestación del servicio baja | Cada compañía, en su tabla de plazos | Contactar antes del cambio; si hay un servicio en curso o reciente en el grupo familiar, escalar |
| Inactivación | El contrato pasa a inactivo: deja de estar vigente para la prestación | La configuración general (días de inactividad, con un mínimo de 90 en el código) | Gestión prioritaria: llamada, visita del cobrador o enlace de pago, según el canal |
| Retiro | El contrato sale de la base con motivo de falta de pago | La configuración general (días de retiro, con un mínimo de 180, contados desde la fecha de cobertura) | Última gestión documentada; decidir si se ofrece un acuerdo o un plazo adicional |
La regla editorial del caso: la lista no juzga al titular, describe un contrato. Un contrato por cruzar el umbral es una tarea de cartera, no un moroso. La mayoría se resuelven con una llamada o con un cobro que se reintenta por otro medio.
3. Qué datos del ERP intervienen
El caso usa registros del módulo de previsión exequial de SFUN y de tesorería. Todos se pueden leer por MCP con los permisos del usuario que consulta:
| Registro | Qué aporta a la lista | Límite que hay que conocer |
|---|---|---|
| Contrato de previsión | Estado, fecha de cobertura (hasta dónde está pagado), días de atraso, porcentaje de prestación, tipo de contrato, sede, plan y grupo familiar | Los días de atraso se recalculan a diario; la lista se arma sobre el dato del día |
| Configuración general de previsión | Si la inactivación y el retiro automáticos están activos y con cuántos días | Es una sola configuración para toda la instancia, no por compañía |
| Tablas de plazos por compañía | Los tramos de días y el porcentaje de prestación de cada uno | Si una compañía no las configuró, rige la tabla estándar |
| Plazo adicional | Contratos con un plazo extra concedido, que mueve su tramo | Un plazo adicional vigente saca al contrato de la urgencia |
| Medio de pago y canal | Medio de pago, tipo de cobro (descuento, recurrente o manual), si tiene débito automático, grupo de cobro (ruta) y asesor de cartera | Define quién hace la gestión: el cobrador de la ruta, el asesor o el equipo de cobros digitales |
| Facturas y pagos | Último pago y por qué medio, intentos de cobro recientes | No hay un campo «último pago» en el contrato: sale de las facturas y los pagos asociados |
| Anotaciones del contrato | Gestiones y novedades registradas (incluido el retiro por falta de pago) | La inactivación automática no deja anotación: hoy solo cambia el estado |
Aplica a los contratos particulares (incluidos los de mascotas y mixtos). Los contratos empresariales no se inactivan por esta regla: siguen los días permitidos de su convenio, y su gestión es con la empresa pagadora, no con cada afiliado.
4. Cómo se arma con MCP, paso a paso
El caso lo usa la jefatura de cartera, una vez por semana (el lunes funciona bien, antes de asignar rutas). El asistente de IA (Claude, ChatGPT o Gemini conectados a SFUN por SFUN MCP en solo lectura) arma la lista; la jefatura de cartera y los coordinadores de ruta deciden la gestión.
Paso 1 — Leer las reglas vigentes
«Dame la configuración de inactivación y retiro de previsión y la tabla de plazos de prestación de cada compañía.» El asistente lee si la inactivación está activa, con cuántos días, y los tramos de porcentaje. Sin este paso, la lista se arma con supuestos; con él, cada fecha de la lista sale de la regla real.
Paso 2 — Los contratos que cruzan un umbral en los próximos 14 días
«Lista los contratos particulares activos o atrasados cuyos días de atraso, sumando 14, alcanzan el próximo tramo, los días de inactivación o los de retiro; excluye los que tengan un plazo adicional vigente.» El asistente usa la fecha de cobertura de cada contrato y calcula, por cada uno, en cuántos días cruza y qué umbral.
Paso 3 — Último pago y canal de cada contrato
Para cada contrato de la lista, el asistente trae el último pago (fecha, valor y medio), el tipo de cobro, si tiene débito automático, la ruta y el asesor. Si el contrato es de débito automático y el último pago es de hace varios ciclos, la causa probable es un cobro que falla: eso es mora involuntaria y se gestiona distinto.
Paso 4 — Señales que suben la prioridad
Sube a la cabeza de la lista el contrato que cruza el umbral en menos de siete días, el de un grupo familiar con muchos beneficiarios, el que tiene muchos años de antigüedad y pagos al día hasta hace poco (alguien que siempre pagó y dejó de hacerlo suele tener un problema de cobro, no de voluntad), y el que tuvo un cambio de cuota reciente sin aviso (ver cambio de cuota sin aviso).
Paso 5 — Una lista corta por responsable
El entregable no es una tabla de mil filas: es una lista por responsable. Ruta norte: 14 contratos, tres cruzan la inactivación esta semana. Cobros digitales: 9 contratos de débito automático sin pago en dos ciclos. Asesor de la sede centro: 4 contratos con cambio de cuota reciente. Cada responsable gestiona y registra el resultado en el contrato.
5. El bucle de mejora continua
- Cada semana: se compara la lista del lunes anterior con lo que pasó. ¿Cuántos contratos de la lista pagaron antes de cruzar el umbral? ¿Cuántos cruzaron sin gestión registrada? Los segundos son el foco de la semana.
- Cada mes: se agrupan los contratos que se inactivaron por causa (cobro fallido, ruta sin cobertura, cambio de cuota, titular sin contacto, decisión del titular). Una ruta con muchas inactivaciones sin gestión tiene un problema de cobertura de cobro, no de clientes.
- Cada trimestre: la dirección revisa si los días de inactivación y los tramos de prestación siguen teniendo sentido frente a los datos, y si conviene ampliar la ventana de la lista de 14 a 21 días en las rutas más lentas.
6. Gobierno y límites: lo que nunca se automatiza
- Un usuario de solo lectura para el asistente. El MCP de SFUN hereda los permisos del usuario con el que se conecta. Para este caso, ese usuario lee contratos, configuración, facturas, pagos y anotaciones; no cambia estados, no concede plazos adicionales ni registra pagos.
- El asistente no inactiva ni reactiva. La regla de inactivación es de la compañía y corre en el ERP. El asistente solo anticipa a quién le va a llegar.
- Ningún mensaje automático a la familia. La lista es para el equipo de cartera. El contacto con el titular lo decide y lo hace una persona, con el guion y el canal que la compañía aprobó.
- Mínimo dato al modelo. La lista necesita el número de contrato, fechas, valores y canal; no necesita documentos de identidad, causas de muerte ni datos de salud de los beneficiarios.
- Prudencia con los servicios en curso. Si un contrato de la lista tiene un servicio reciente o en curso en su grupo familiar, se escala a la jefatura; ninguna regla de cobro se aplica a una familia en duelo sin que una persona lo revise.
- Registro de cada gestión. Quién corrió la lista, sobre qué fecha, y qué gestión se hizo en cada contrato. Las reglas generales están en gobierno de agentes de IA en el ERP funerario.
7. KPIs: línea base y meta
| Indicador | Cómo se mide | Línea base habitual | Meta a dos trimestres |
|---|---|---|---|
| Contratos inactivados por atraso al mes | Contratos particulares que pasaron a inactivo / contratos activos al inicio del mes | Se mide con los tres meses anteriores | Bajar mes a mes |
| Contratos de la lista que se pusieron al día antes del umbral | Contratos que pagaron antes de cruzar / contratos de la lista | Cero: hoy no hay lista | Más de la mitad |
| Inactivaciones sin gestión registrada | Contratos inactivados sin anotación de gestión en los 14 días previos / inactivados | Casi todos, porque la regla no avisa | Menos del 10 % |
| Contratos reactivados en los 30 días siguientes | Reactivados tras pagar / inactivados | La que salga del primer mes | Subir; y que la lista los haga innecesarios |
| Servicios con prestación parcial por atraso | Servicios prestados con porcentaje menor al 100 % / servicios a contratos de previsión | Se mide el primer trimestre | Bajar trimestre a trimestre |
8. Hoja de ruta de adopción y errores comunes
- Semana 1: crear el usuario de solo lectura, leer la configuración vigente de inactivación, retiro y tramos, y contar cuántos contratos se inactivaron en los tres meses anteriores. Ese número es la línea base.
- Mes 1: correr la lista cada lunes, repartirla por responsable y pedir que cada gestión quede anotada en el contrato. Empezar por la sede o la ruta con más inactivaciones.
- Trimestre 1: separar la mora involuntaria (débitos y cobros fallidos) de la voluntaria, alinear el guion de contacto con el área de servicio al cliente y llevar el indicador de inactivaciones sin gestión al comité de cartera.
Errores comunes: mirar solo la inactivación y olvidar los tramos de prestación (el contrato sigue «activo» pero ya no cubre todo); armar la lista con días supuestos en lugar de leer la configuración; tratar igual al titular que nunca falló que al que paga tarde siempre; mandar la lista completa a todos en lugar de una lista por responsable; y darle al asistente un usuario que puede cambiar estados o conceder plazos.
Qué existe hoy en SFUN y qué no
| Pieza | Estado |
|---|---|
| Contrato de previsión con estados (activo, atrasado, inactivo, retirado, reactivado), fecha de cobertura y días de atraso recalculados a diario | Existe |
| Inactivación y retiro automáticos por días de atraso, configurables y con mínimos (90 y 180 días) | Existe |
| Porcentaje de prestación del servicio por tramos de atraso, configurable por compañía, y plazo adicional que lo amplía | Existe |
| Vuelta automática a activo cuando el titular se pone al día dentro del umbral | Existe |
| Medio de pago, tipo de cobro, débito automático, grupo de cobro y asesor de cartera en el contrato | Existe |
| Anotación del retiro por falta de pago en cada contrato | Existe |
| Lectura por SFUN MCP de contratos, configuración, plazos adicionales, anotaciones, facturas y pagos, con los permisos del usuario | Existe |
| Aviso previo al titular o al equipo antes de inactivar | No existe: es lo que cubre la lista de este caso |
| Reporte de «contratos próximos a inactivar o a cambiar de tramo» | No existe: hoy se arma en la conversación con el asistente |
| Anotación en el contrato cuando la regla lo inactiva | No existe: la inactivación cambia el estado sin dejar novedad |
| Días de inactivación distintos por compañía | No existe: la configuración es una sola para la instancia (los tramos de prestación sí son por compañía) |
Lo que no existe es la hoja de ruta natural del caso. Mientras tanto, la lista funciona leyendo los datos que ya están en el ERP, con la decisión de una persona en cada contrato.
Lo que hacen otros sectores
En el crédito de consumo, el patrón ya tiene nombre. Un análisis de FinBox sobre MCP en préstamos describe un agente de cobranza que, ante un deudor con dos cuotas vencidas, reúne el saldo, el historial de pagos, los cambios recientes de ingreso y la política de cobranza, y recomienda una acción (reestructurar, llamar o enviar un enlace de pago) mostrando su razonamiento; antes, el gestor reunía esa información desde varias pantallas. Proveedores de plataformas de crédito como LoanPro describen además una capa de cumplimiento que revisa cada acción de cobranza antes de ejecutarla y deja rastro de lo que hizo el agente.
La homologación al sector funerario es directa: lo que en un banco es la cuota vencida que está por pasar a cartera castigada, en una empresa de previsión es el contrato que está por perder la cobertura. La diferencia es que en previsión el costo de llegar tarde no es solo financiero: es la familia que llama el día del fallecimiento. Por eso aquí el agente no ejecuta la cobranza; prepara la lista y una persona decide.
Preguntas frecuentes
¿Cuándo pierde la cobertura un contrato de previsión exequial por atraso?
Depende de las reglas de cada compañía. En SFUN, el porcentaje de prestación del servicio baja por tramos de días de atraso que configura cada compañía, y el contrato pasa a inactivo cuando los días de atraso alcanzan el umbral configurado (que el sistema no permite fijar por debajo de 90 días). Antes de la inactivación, el contrato puede seguir activo con una cobertura parcial.
¿SFUN avisa antes de inactivar un contrato?
No. Hoy la tarea diaria cambia el estado sin enviar un aviso previo ni dejar una anotación en el contrato. Por eso este caso arma la lista semanal con un asistente de IA por MCP en solo lectura: para que cartera sepa a quién le va a llegar la regla antes de que corra.
¿La IA puede inactivar, reactivar o conceder un plazo en SFUN?
En este caso, no. El asistente se conecta con un usuario de solo lectura: lee contratos, configuración y pagos, y arma la lista. Cambiar estados, conceder plazos adicionales o registrar pagos sigue siendo decisión y acción de una persona del equipo de cartera.
¿Qué pasa si el titular paga después de que el contrato se inactivó?
En SFUN, cuando el pago lleva los días de atraso de nuevo dentro del umbral, el contrato vuelve a activo al actualizarse. Aun así, el periodo en que estuvo inactivo es un riesgo: si en esos días ocurre un fallecimiento, la prestación se rige por el estado y el porcentaje vigentes. La lista existe para que ese periodo no ocurra.
¿Aplica igual en todos los países de Latinoamérica?
El método sí. Lo que cambia por país son las reglas de protección al consumidor sobre la terminación de contratos por falta de pago y el aviso previo que se exige, y la cultura de previsión de cada mercado. Revisa con tu asesor legal qué aviso debe recibir el titular antes de perder la cobertura en tu país.
En resumen
En previsión, la mora se gestiona tarde porque se mira hacia atrás. Una lista semanal de los contratos que cruzarán el próximo tramo de cobertura o el umbral de inactivación, con su último pago y su canal de cobro, convierte la regla nocturna en una agenda de cartera. SFUN ya tiene los datos y las reglas; con un asistente de IA por MCP en solo lectura, esa lista sale en minutos, y la decisión sigue siendo de una persona. Para ver qué datos expone el conector y con qué permisos, revisa la página de SFUN MCP.
Fuentes de este artículo
- FinBox Research: «MCP: the protocol that rewires lending», sobre un agente de cobranza ante un deudor con dos cuotas vencidas. Consulta del 12 de noviembre de 2026.
- LoanPro: «What is Model Context Protocol and what does it mean for lending?», sobre la revisión de cumplimiento previa a cada acción de cobranza. Material de proveedor; consulta del 12 de noviembre de 2026.
- Código de SFUN (rama principal, consulta del 12 de noviembre de 2026) para todo lo que se afirma del producto. La configuración de cada compañía puede variar.
- Advertencia de alcance: no hay cifras publicadas sobre contratos de previsión inactivados por atraso en Latinoamérica. Los valores de la imagen y de los ejemplos son ilustrativos.