Respuesta corta
La cobranza inmobiliaria se ordena cuando cada obligación conserva contexto de cliente, proyecto, unidad, cuota, vencimiento y pago. La automatización debe segmentar por estado real, detenerse frente a promesas o pagos y derivar disputas contractuales a una persona responsable.
Fuentes para verificar: SERNAC — Contratos preparatorios inmobiliarios · BCN — Ley 19.628 vigente
Construye una cartera que explique el caso
Agrega proyecto, unidad o lote, tipo de obligación, vencimiento, saldo, último pago, etapa y responsable. Una fila con nombre, teléfono y monto rara vez basta.
Separa datos objetivos de notas libres para que las reglas puedan priorizar sin interpretar comentarios ambiguos.
Segmenta por riesgo y momento
Los días de mora importan, pero una cuenta con promesa vigente no debe recibir la misma secuencia que otra sin contacto.
Combina antigüedad, monto, respuesta, compromiso, historial y cercanía de hitos contractuales. Separa disputas y casos sensibles.
Trata las promesas como datos
Toda promesa necesita fecha, monto, canal, origen y estado. Antes de insistir, el sistema debe consultar si el pago fue conciliado.
Distingue intención, solicitud y convenio aprobado para que la automatización no se atribuya facultades que la empresa no entregó.
Piloto sugerido
Comienza con un proyecto activo y un tramo de mora manejable. Excluye litigios y define mensajes, horarios, ofertas y responsables.
Tras ciclos suficientes, revisa calidad de datos, derivaciones, experiencia y pagos. Escala solo cuando el flujo soporte información actualizada.
Diagnóstico antes de configurar
Dibuja primero la relación entre comprador, proyecto, unidad, obligación y pago. Si el equipo no puede explicar a qué cuota corresponde un saldo, ninguna cadencia será confiable. Registra además la fecha de actualización, el sistema de origen y el responsable que puede corregir cada campo.
Separa mora operativa de excepciones contractuales. Una cuota vencida con datos completos puede entrar a seguimiento; una diferencia sobre el contrato, un desistimiento, una identidad incierta o un caso judicial necesitan un propietario humano. La automatización debe reconocer esa frontera y entregar antecedentes, no resolverla por inferencia.
Construye la línea base por proyecto y tramo de mora. Cuenta obligaciones elegibles, contactos útiles, promesas con fecha, pagos conciliados, errores y horas del equipo. Sin ese punto de partida, un aumento de pagos puede reflejar estacionalidad, composición de cartera o campañas paralelas.
Mapa operativo
Del problema a una prueba verificable
- 01
Modelar
Relaciona cliente, proyecto, unidad, obligación, vencimiento, saldo, pago y estado mediante identificadores estables.
- 02
Excluir
Retira disputas, datos insuficientes, procesos jurídicos y cualquier caso que no tenga una política aprobada.
- 03
Coordinar
Configura pausas comunes para WhatsApp, llamadas y email ante respuesta, promesa o pago por conciliar.
- 04
Revisar
Concilia resultados por obligación y audita una muestra de conversaciones antes de escalar a otro proyecto.
Señales para detener y corregir
- Cobrar un saldo agregado sin identificar la cuota.
- Confundir solicitud de convenio con acuerdo aprobado.
- Contactar después de un pago en tránsito.
- Usar notas libres como único registro de promesas.
Preguntas para la revisión interna
- ¿Cuál es la unidad exacta de cobro?
- ¿Qué sistema confirma el pago?
- ¿Qué eventos pausan todos los canales?
- ¿Quién resuelve una excepción contractual?
- ¿Cómo se compara un proyecto con su línea base?
Recurso práctico
Convierte esta guía en una prueba.
Usa la plantilla de cartera ficticia para verificar el modelo antes de integrar datos reales. Agrega campos propios solo cuando exista una definición, un origen y una acción clara asociada a ese dato.
Abrir kit de prueba controlada →Matriz para tomar la decisión
| Señal | Qué revisar | Decisión |
|---|---|---|
| Próximo a vencer | Cuota identificada y datos confirmados | Recordatorio preventivo sin lenguaje de mora |
| Mora reciente | Saldo actualizado y ausencia de pago en tránsito | Cadencia breve con salida ante respuesta |
| Promesa vigente | Monto, fecha, responsable y estado | Pausar hasta conciliar o vencer el compromiso |
| Disputa o excepción | Antecedentes contractuales y propietario del caso | Suspender automatización y derivar |
Escenario, no caso de cliente
Ejemplo ilustrativo por proyecto
Un comprador mantiene dos cuotas: una aparece vencida y la otra tiene un pago por conciliar. Si la cartera solo conserva el saldo total, ambos movimientos pueden generar el mismo mensaje. Con obligaciones separadas, el sistema pausa la cuota en conciliación y gestiona únicamente la que cumple las reglas aprobadas.
El escenario es ficticio y no describe un cliente. Su objetivo es mostrar cómo el modelo de datos reduce contactos incorrectos antes de medir recuperación.
Cómo medir sin confundir señales con resultados
- Cuentas gestionables: obligaciones con identidad, saldo y vencimiento suficientes.
- Promesas vigentes: compromisos con monto y fecha que todavía no deben recontactarse.
- Pagos posteriores a contacto: abonos conciliados dentro de la ventana definida.
- Errores evitables: contacto posterior al pago, identidad equivocada o duplicidad entre canales.
La metodología completa está disponible en cómo KOBRA define y valida métricas de cobranza.
Checklist para llevarlo a la práctica
- Identificador único por cliente, proyecto y obligación.
- Separación entre cuota, gasto, abono y saldo.
- Promesas con fecha, monto, estado y responsable.
- Exclusión de disputas y casos jurídicos.
- Conciliación antes de cada nueva gestión.
Preguntas frecuentes
¿Cómo priorizar una cartera inmobiliaria?
Combina días de mora con monto, hito contractual, respuesta reciente, promesa, historial y calidad del dato. La prioridad debe poder explicarse y no depender solamente de ordenar una planilla por saldo.
¿Qué casos no deberían automatizarse?
Disputas contractuales, identidad incierta, solicitudes fuera de política, casos sensibles y decisiones sobre término del contrato necesitan revisión humana. La automatización puede reunir antecedentes y derivar, no inventar una solución.
¿Qué debe medirse en el piloto?
Mide contacto útil, compromisos válidos, pagos conciliados, tiempo de resolución, derivaciones, errores de datos y contactos posteriores al pago. Revisa también una muestra cualitativa de conversaciones.