Cómo conectar tu CRM con un ERP inmobiliario sin duplicar datos
Integrar el CRM con el ERP no se trata de conectar dos APIs: se trata de decidir cuál de los dos manda sobre cada dato. Cómo se reparte, qué pasa cuando no coinciden y qué preguntar antes de empezar.
Toda inmobiliaria que crece llega al mismo punto: el área comercial trabaja en un sistema y el área de administración y finanzas en otro. Los dos guardan clientes. Los dos guardan unidades. Los dos guardan montos. Y nadie sabe cuál de los dos tiene razón cuando no coinciden.
La reacción natural es pedir una integración. Es la decisión correcta, y suele tomarse mal, porque se plantea como un problema técnico —conectar dos APIs— cuando en realidad es un problema de gobierno: quién manda sobre cada dato.
Si esa pregunta no se responde antes, la integración funciona y el problema empeora: ahora los datos inconsistentes se propagan solos y más rápido.
La única regla que importa
Cada dato tiene un dueño, y uno solo.
Un dato con dos dueños es un dato que va a tener dos valores distintos. No es una posibilidad remota: es lo que pasa siempre, porque dos personas en dos áreas, con dos criterios, van a editar el mismo campo en momentos distintos. Y cuando eso ocurre, ningún sistema puede resolverlo: la máquina no sabe cuál de los dos valores es el correcto. Lo tiene que decidir alguien, a mano, cada vez.
De esa regla se desprende todo lo demás. Un dato con dueño viaja en una sola dirección: del sistema que lo gobierna al que lo consume. El que lo consume lo muestra y no lo edita.
Que un campo sea «bidireccional» suena a más capacidad y es, casi siempre, una forma elegante de no haber decidido.
Cómo se reparte en la práctica
Este es un reparto razonable para una operación inmobiliaria. No es el único posible, pero sirve para discutirlo con nombres concretos:
| Dato | Dueño natural | Dirección | Por qué |
|---|---|---|---|
| Catálogo de unidades y su identificador | ERP o la fuente de obra | ERP → CRM | La unidad existe en el proyecto antes de existir en la venta |
| Disponibilidad comercial de cada unidad | CRM | CRM → ERP | La define la operación de venta: reservas, bloqueos, promesas |
| Lista de precios vigente | Depende de quién la fija | Un solo sentido, siempre el mismo | Es el campo donde más caro sale tener dos dueños |
| Prospectos y seguimiento | CRM | No viaja | Al ERP no le sirven y multiplican su base de contactos |
| Cliente ya convertido | CRM → ERP al promesar | CRM → ERP | El ERP lo necesita recién cuando hay que facturarle |
| Facturación, pagos y cobranza | ERP | ERP → CRM (solo lectura) | Es información contable; el comercial la mira, no la edita |
| Estado de avance de obra | ERP o planificación | → CRM | Afecta la fecha que la sala de venta promete |
Dos filas merecen atención especial.
La lista de precios es donde más conflictos aparecen, porque en muchas inmobiliarias la fija gerencia, la carga administración y la usa la sala de venta: tres actores sobre un mismo campo. Da lo mismo cuál sea el dueño, con tal de que sea uno solo y que el otro sistema la muestre sin permitir editarla.
El cliente no debería nacer en el ERP. Mientras es prospecto no le interesa a finanzas, y crearlo allí desde el principio llena la base contable de gente que nunca compró. Conviene que cruce recién cuando hay una promesa.
El identificador: la condición de entrada
Antes de hablar de APIs hay una pregunta más básica: ¿la unidad 802 de la torre B se llama igual en los dos sistemas?
Si en el CRM es B-802 y en el ERP es 0802B, o peor, si en uno está por número correlativo y en el otro por rol de avalúo, no hay integración posible. Hay una tabla de equivalencias que alguien mantiene a mano, y esa tabla se va a desactualizar en el primer cambio de proyecto.
Resolverlo es aburrido y es la mitad del trabajo: definir un identificador único por unidad, que no cambie nunca, y usarlo en los dos lados. Si hay que elegir cuál adoptar, conviene el del sistema que más difícil sea de cambiar, que normalmente es el ERP.
Lo mismo aplica a los proyectos y a las etapas. Un proyecto que en un sistema es «Torre Norte» y en el otro «Proyecto 14 – Etapa 2» obliga a traducir en cada mensaje.
Las tres fallas que aparecen después
El evento que llega dos veces
Las integraciones reintentan cuando algo falla, y está bien que lo hagan. El problema es qué pasa cuando el reintento llega después de que el primer mensaje sí funcionó: se crea la reserva dos veces, o se descuenta el pago dos veces.
Lo que hay que pedir es que cada mensaje lleve un identificador propio y que el receptor ignore los que ya procesó. Es un detalle técnico que se traduce en algo muy concreto: que una caída de red no te duplique una operación.
Los dos sistemas no coinciden y los dos están seguros
Va a pasar, aunque el reparto de dueños esté bien hecho: una carga manual antigua, una migración, un mes en que la integración estuvo caída.
La tentación es que el sistema resuelva solo, normalmente con la regla «gana el más reciente». Es la peor opción, porque pisa silenciosamente un dato que podía ser el correcto. Lo que conviene es que la discrepancia se detenga, se registre y se le muestre a una persona: un reporte de diferencias que alguien revisa, no una corrección automática que nadie ve.
El cambio de esquema
Alguien agrega un campo obligatorio en el ERP, o cambia el nombre de un estado, y la integración empieza a fallar. Si falla ruidosamente, se arregla el mismo día. Si falla en silencio, se descubre al cierre de mes.
Toda integración necesita que alguien reciba el aviso cuando se cae. Si ese alguien no está definido, no está definida la integración.
Qué va en tiempo real y qué no
No todo necesita viajar al instante, y querer que todo lo haga encarece el proyecto sin mejorarlo.
En tiempo real va lo que alguien está mirando en este momento para tomar una decisión: la disponibilidad de una unidad, su precio vigente, un bloqueo. Si eso viaja una vez al día, la sala de venta trabaja con información de ayer y vuelve el problema que la integración venía a resolver.
Una vez al día basta para lo contable: pagos recibidos, estados de cuenta, avance de obra. Nadie toma una decisión comercial en función de si un pago entró hace dos horas o anoche, y un proceso diario es mucho más simple de monitorear y de reprocesar cuando falla.
Cuándo la integración no vale la pena
Conviene decirlo porque casi nadie lo dice: si el volumen es bajo, una persona exportando una vez por semana puede ser la decisión correcta.
Una integración tiene costo de construcción y costo de mantención permanente: cada cambio en cualquiera de los dos sistemas puede romperla. Con un proyecto, pocas operaciones al mes y un ERP que se toca poco, ese costo no se recupera.
El punto de quiebre no es el número de unidades: es cuántas veces al día alguien necesita un dato que vive en el otro sistema. Cuando la respuesta es «varias veces, todos los días, y si está desactualizado se comete un error con un cliente», la integración se pagó sola.
Cinco preguntas antes de empezar
- ¿Cuál es el identificador único de una unidad y existe igual en los dos sistemas?
- ¿Quién es el dueño de la lista de precios? Uno solo.
- ¿Qué pasa si el mismo mensaje llega dos veces?
- ¿Qué pasa cuando los dos sistemas no coinciden? Si la respuesta es «gana el último», no hay respuesta.
- ¿Quién recibe el aviso cuando la integración falla? Con nombre.
Ninguna es técnica. Las cinco hay que responderlas antes de que alguien escriba una línea de código, y responderlas suele tomar más tiempo que construir la conexión.
Sobre qué registra y qué gobierna un CRM en este reparto está la página de CRM inmobiliario. Y si lo que se está integrando es, en realidad, una planilla que hace de sistema intermedio, conviene leer antes el costo oculto de gestionar proyectos en Excel: integrar una planilla es integrar un archivo que cualquiera puede editar.
Preguntas frecuentes
¿Cómo se evita duplicar datos entre un CRM y un ERP?
Definiendo un único dueño para cada dato y haciendo que viaje en una sola dirección, del sistema que lo gobierna al que lo consume. Un campo con dos dueños termina con dos valores distintos y ningún sistema puede decidir cuál es el correcto.
¿Qué datos debe gobernar el CRM y cuáles el ERP?
Como reparto razonable: el CRM gobierna los prospectos, el seguimiento comercial y la disponibilidad de cada unidad; el ERP gobierna el catálogo de unidades, la facturación, los pagos y el avance de obra. El cliente cruza del CRM al ERP recién cuando hay una promesa, para no llenar la base contable de gente que no compró.
¿Por qué es tan importante el identificador de la unidad?
Porque es lo que permite que los dos sistemas hablen de la misma unidad. Si en uno es B-802 y en el otro 0802B, no hay integración: hay una tabla de equivalencias que alguien mantiene a mano y que se desactualiza en el primer proyecto nuevo.
¿Qué pasa si el CRM y el ERP muestran datos distintos?
Conviene que la diferencia se detenga, se registre y se le muestre a una persona, en vez de resolverse sola con la regla de que gana el dato más reciente. Esa regla pisa en silencio un valor que podía ser el correcto, y nadie se entera hasta el cierre de mes.
¿Todo tiene que sincronizarse en tiempo real?
No, y querer que así sea encarece el proyecto sin mejorarlo. En tiempo real tiene que viajar lo que alguien está mirando para decidir ahora —disponibilidad, precio vigente, bloqueos—. Lo contable, como pagos y avance de obra, puede viajar una vez al día y es más simple de monitorear.
¿Siempre conviene integrar el CRM con el ERP?
No. Una integración tiene costo de construcción y de mantención permanente, y con poco volumen una exportación semanal hecha por una persona puede ser la decisión correcta. El punto de quiebre es cuántas veces al día alguien necesita un dato que vive en el otro sistema.
