Integrar CRM y ERP en una inmobiliaria: por dónde empezar

La frontera entre el CRM y el ERP de una promotora suele ser una persona con un Excel. Alguien que, los viernes por la tarde, exporta reservas del CRM comercial, las cruza con el cuadro de unidades del ERP, corrige dos precios que no cuadran y manda el fichero a administración. Ese Excel es el verdadero sistema de información de la compañía, y es el primero que hay que romper.

El dato que rompe todo es la unidad, no el contacto

Casi todos los proyectos de integración empiezan mirando los contactos, porque es lo que más se parece a lo que hacen otros sectores. En inmobiliario el dato crítico es la unidad: el piso, el trastero, la plaza de garaje. La unidad tiene un estado (disponible, prerreservada, reservada, contratada, escriturada), un precio de tarifa, un precio real de venta, descuentos, mejoras y calidades contratadas, un calendario de cobros ligado al avance de obra y una fecha de entrega. Cada uno de esos campos vive hoy, parcialmente, en dos sistemas distintos.

Cuando el estado de la unidad se lleva en dos sitios, la consecuencia no es estadística, es operativa: se vende dos veces el mismo piso, se publica como disponible algo ya reservado, se emite un cobro con un precio que el comercial había renegociado. Antes de hablar de arquitectura, conviene aceptar que integrar CRM y ERP en una inmobiliaria es, sobre todo, decidir dónde vive la verdad de cada campo de la unidad.

Qué romper primero: la doble tecla

El primer objetivo no es un dashboard bonito, es eliminar la introducción manual del mismo dato en dos sistemas. En una promotora media, la doble tecla se concentra en tres momentos: alta de la promoción y su tabla de unidades, paso de reserva a contrato, y actualización de cobros. Son tres puntos, no treinta.

Romper la doble tecla en esos tres momentos resuelve la mayor parte del dolor diario y deja fuera, deliberadamente, cosas que parecen urgentes y no lo son: sincronizar todos los leads históricos, replicar la agenda de visitas, unificar la documentación. Esas se hacen después, si siguen haciendo falta.

El orden razonable de los flujos

Primero, del ERP al CRM: maestro de promociones y unidades con su tarifa. El CRM deja de tener su propia lista de pisos. Segundo, del CRM al ERP: la reserva y el contrato, con comprador, precio final, descuentos y mejoras. Tercero, del ERP al CRM: estado de cobros y de obra, para que el comercial responda a un cliente sin llamar a administración. Con esos tres flujos funcionando, el Excel de los viernes desaparece.

Quién manda en cada dato

Una integración sin reglas de propiedad del dato se convierte en una guerra de sobrescrituras. La regla que mejor aguanta en promoción residencial: el ERP manda en todo lo que tiene consecuencia contable o jurídica (unidad física, superficies, tarifa, contrato, cobros, factura) y el CRM manda en todo lo que es relación comercial (lead, origen, contacto, interacciones, oferta, documentación precontractual). El estado de la unidad es el campo disputado, y conviene que lo gobierne un solo sistema con el otro como espejo de solo lectura.

Esta decisión no es técnica, es política. La toman dirección comercial y dirección financiera, y hay que tomarla antes de escribir una línea de código. Si se delega en el integrador, se descubre tarde y en producción.

Cómo conectar sin montar un monstruo

Hay tres caminos habituales y los tres son defendibles según el caso. Conexión directa por API entre ambos sistemas: la más barata al principio y la más cara de mantener cuando aparece el tercer sistema. Capa intermedia de integración (middleware o iPaaS): más coste inicial, pero convierte cada nuevo sistema —portal, firma electrónica, app de postventa, BI— en un conector más. Intercambio por fichero programado: poco elegante, perfectamente válido cuando el ERP no expone API y los datos toleran un desfase de horas.

Decidir entre tiempo real y proceso nocturno es una pregunta de negocio: el estado de disponibilidad necesita segundos porque hay dos comerciales enseñando el mismo piso; el estado de cobros aguanta perfectamente una actualización diaria. Pedir tiempo real en todo multiplica el coste y la superficie de fallo.

Lo que ningún proveedor pone en la propuesta

Una integración necesita registro de todo lo que pasa, reintentos automáticos, control de duplicados y una cola de errores que alguien revise con nombre y apellidos. Sin ese último punto, los fallos se acumulan en silencio durante semanas y el sistema pierde la confianza del equipo, que vuelve al Excel. Recuperar esa confianza cuesta más que la integración.

Lo que sale mal

El bloqueo más frecuente es el ERP. Buena parte de los ERP verticales usados en promoción en España tienen API limitada, documentada a medias o facturada por módulo, y el acceso pasa por el partner que lo implantó. Antes de planificar nada, hay que pedir por escrito qué endpoints existen, qué cuestan y qué pasa en la próxima actualización de versión. Si la respuesta tarda tres semanas, eso ya es información sobre el proyecto.

El segundo problema son los datos sucios. Contactos duplicados, NIF mal escritos, promociones con nomenclatura distinta en cada sistema, unidades que en el ERP se llaman por código catastral y en el CRM por portal y planta. La integración no limpia nada: propaga el desorden más rápido. La limpieza y el criterio único de nomenclatura son trabajo previo, y suelen ocupar más tiempo del que nadie presupuesta.

El tercero es el alcance. Un proyecto que empieza por tres flujos termina, si nadie lo frena, en una migración de ERP, un rediseño del CRM y un cuadro de mando de dirección. También hay coste recurrente: una integración viva necesita mantenimiento cada vez que cambia una versión, un proceso o un campo. Presupuestarla como obra cerrada y no como servicio es el error que deja integraciones rotas a los dieciocho meses.

Y hay un riesgo organizativo: automatizar el paso de reserva a contrato elimina el control informal que ejercía la persona que repasaba el Excel. Si ese control no se sustituye por validaciones explícitas en el flujo, los errores pasan directos a contabilidad.

Cuándo no merece la pena

Con una sola promoción en comercialización y un equipo pequeño, el coste de integrar supera al del Excel durante bastante tiempo. Tampoco compensa si el ERP está en proceso de sustitución: se integra contra un sistema que va a desaparecer. Ni si no hay nadie dentro de la organización responsable del dato, porque la integración se convierte en una dependencia externa sin dueño interno.

En esos casos, la alternativa sensata es acordar nomenclatura única, un único fichero maestro de unidades y un proceso claro de quién lo actualiza. Es menos vistoso y resuelve el ochenta por ciento del dolor sin proyecto.

Cómo saber si ha servido

Las métricas útiles son operativas y se pueden medir antes de empezar: horas mensuales dedicadas a conciliar datos entre sistemas, días desde la firma de la reserva hasta su reflejo contable, número de incidencias por discrepancia de precio o estado, y tiempo que tarda un comercial en responder a un cliente que pregunta por su calendario de pagos. Si ninguna de esas cuatro mejora, la integración ha sido un gasto de infraestructura.

Un orden de trabajo que funciona

Mapear los tres momentos de doble tecla con las personas que los sufren. Decidir, por escrito y firmado por comercial y financiero, qué sistema manda en cada campo de la unidad. Verificar las capacidades reales de la API del ERP antes de comprometer fechas. Limpiar y unificar nomenclaturas. Construir el primer flujo —maestro de unidades— y dejarlo en producción un mes antes de tocar el siguiente. Y desde el día uno, un responsable interno de la cola de errores.

Una integración que nadie mantiene dura lo que dura la siguiente actualización del ERP.

En GU Studio trabajamos esto en integrar CRM y ERP inmobiliaria. Si quieres ver cómo encajaría en tu caso, cuéntanoslo.