Cómo automatizar el cruce entre clientes y propiedades en una inmobiliaria

El problema no es encontrar muchas coincidencias. Es saber cuáles merece la pena enseñar

Una inmobiliaria puede tener cientos o miles de inmuebles y decenas o cientos de demandas activas. Cruzarlos automáticamente parece un problema sencillo: comparar campos y mostrar coincidencias. De hecho, los CRM inmobiliarios ya incorporan desde hace tiempo funciones para relacionar demandas con inmuebles y distinguir entre propiedades propuestas o descartadas.

El problema aparece cuando la lógica se queda en “cuantos más criterios coincidan, mejor”. No todos los criterios tienen el mismo peso y, sobre todo, no todos cumplen la misma función.

Para una persona, “tener terraza” puede ser un deseo. Para otra puede ser imprescindible. Un tercer cliente puede preferir terraza, pero aceptar un balcón amplio. Lo mismo ocurre con el barrio, la planta, el ascensor, la distancia al trabajo, el número de habitaciones o el presupuesto.

Si todo se convierte en puntos, el sistema puede terminar ofreciendo un inmueble que acumula muchas características atractivas pero falla justo en aquello que hacía inviable la operación.

Por eso, antes de hablar de IA, puntuaciones o automatizaciones, hay que conseguir que la demanda esté bien representada. Si el CRM solo guarda una caja de texto con “busca piso luminoso por la zona”, cualquier automatización posterior tendrá que adivinar demasiado.

La entrada sobre automatización para inmobiliarias explicaba el proceso comercial completo: leads, demandas, visitas, captación y seguimiento. Aquí vamos a profundizar únicamente en una parte: cómo relacionar una demanda activa con inmuebles potencialmente adecuados sin convertir el CRM en una fábrica de recomendaciones irrelevantes. Cuando el equipo selecciona qué inmuebles merece la pena enseñar, el siguiente tramo es la gestión de visitas inmobiliarias.

Requisitos obligatorios y preferencias flexibles: la diferencia que evita la mayoría de las falsas coincidencias

La distinción más útil es también una de las más sencillas.

La clave está en que no existe una lista universal de criterios obligatorios. La misma variable cambia de categoría según la persona y el momento.

“Con ascensor” puede ser una preferencia para un comprador y una condición imprescindible para otro. “Máximo 320.000 €” puede ser realmente un techo o una cifra orientativa que admite cierto margen. “Tres dormitorios” puede significar “necesito tres” o “preferiría tres, pero dos grandes podrían servirme”.

El CRM debería representar esa diferencia. Si no lo hace, la automatización no puede saber si debe descartar o simplemente bajar de posición una propiedad.

Qué significa que una preferencia no pueda compensar un requisito

Conviene explicarlo sin fórmulas. Imaginemos que un sistema asigna puntos: terraza suma, buena orientación suma, cocina abierta suma y estar cerca del metro también suma. Si el precio máximo es una condición obligatoria, un inmueble que supera ese precio no debería entrar en el ranking solo porque reúne muchas otras cosas atractivas.

El sistema puede guardar ese inmueble para que un agente lo vea en una situación excepcional, si la política comercial lo permite. Lo que no debería hacer es presentarlo como “uno de los mejores encajes” fingiendo que cuatro preferencias positivas compensan una condición que el propio cliente había marcado como límite.

En términos de diseño, esto obliga a separar dos preguntas:

1. ¿Puede este inmueble ser candidato?
2. Entre los candidatos válidos, cuáles merece la pena revisar primero?

Mezclar ambas preguntas en una única puntuación es una de las formas más rápidas de generar recomendaciones absurdas.

El “mapa de requisitos y preferencias”: una forma sencilla de diseñar la demanda antes de automatizarla

En Yarvia utilizamos aquí el concepto mapa de requisitos y preferencias como recurso de diseño editorial: una tabla que obliga a definir qué significa cada criterio antes de utilizarlo para buscar o puntuar inmuebles. No es un estándar oficial del sector ni una función concreta de un CRM.

Para cada criterio conviene poder responder a estas preguntas:

Este mapa resuelve además otro problema: la calidad del cruce depende de la calidad y actualidad de los dos lados. No basta con tener una demanda bien cualificada. El inmueble también necesita datos fiables.

Una vivienda puede haber cambiado de precio, estar reservada, retirarse de comercialización o tener una ficha incompleta. Por eso, antes de calcular cuánto “encaja”, el proceso debería comprobar si la demanda sigue activa y si el inmueble puede realmente proponerse.

idealista/tools, por ejemplo, distingue demandas activas e inactivas, permite trabajar con inmuebles cruzados, propuestos y descartados y excluye inmuebles reservados de determinados cruces automáticos. Es un ejemplo de producto concreto, no una regla universal, pero ayuda a visualizar algo importante: el estado comercial forma parte del cruce.

Un sistema de cruce por capas: primero comprobar, después ordenar

En lugar de hablar de “matching híbrido”, resulta más útil pensar en un sistema de cruce por capas. Cada capa responde a una pregunta distinta y evita que la siguiente trabaje con candidatos que ya no deberían estar ahí.

El esquema puede resumirse todavía más: comprobar → descartar → ordenar → interpretar → explicar → registrar. La parte inteligente no está únicamente en la IA; está en colocar cada tipo de decisión en el momento adecuado.

Este enfoque es más robusto que pedir a un único modelo que “encuentre las mejores viviendas para este cliente”. No porque la IA sea incapaz de encontrar relaciones útiles, sino porque hay decisiones que no necesitan interpretación. Si un inmueble está reservado, no hace falta un modelo para debatir si su descripción es muy compatible con el deseo del comprador.

Dónde aporta IA: entender expresiones humanas sin sustituir los datos objetivos

Las demandas reales no llegan en forma de una tabla perfectamente rellenada. Un cliente puede decir:

“Quiero algo luminoso, con sensación de amplitud, en una zona tranquila y, si puede ser, con cocina abierta.”

La ficha de un inmueble podría utilizar otras palabras:

“Vivienda exterior orientada al sur, salón comedor integrado y calle residencial con poco tráfico.”

Una búsqueda literal por palabras puede perder parte de esa relación. Aquí sí puede aportar la IA: ayudar a encontrar textos que hablan de ideas parecidas aunque utilicen palabras diferentes.

Qué es un embedding, explicado sin jerga

Un embedding, o representación vectorial, es una forma matemática de convertir un texto en números de manera que textos con significados relacionados puedan quedar “cerca” entre sí. No hace falta que el propietario de una inmobiliaria entienda el cálculo. Lo importante es entender para qué sirve.

Permite que el sistema relacione expresiones como “zona silenciosa” y “calle con poco tráfico”, o “espacio diáfano” y “salón con cocina integrada”, aunque no compartan exactamente las mismas palabras.

Servicios de búsqueda modernos permiten combinar este tipo de búsqueda por significado con búsquedas normales por texto y con filtros. Esa combinación es técnicamente útil, pero no convierte la similitud de significado en una prueba de que el inmueble cumple la demanda.

“Se parece a lo que busca” no significa “cumple lo que necesita”

Ésta es la frontera que conviene mantener durante todo el artículo.

Dos descripciones pueden parecerse mucho en significado y, sin embargo, la vivienda no servir. También puede ocurrir lo contrario: una ficha inmobiliaria muy escueta puede describir mal un inmueble que sí cumple perfectamente los requisitos objetivos.

Por eso la IA debe complementar el dato estructurado, no sustituirlo.

Cómo ordenar candidatos sin convertir una puntuación en una falsa probabilidad de compra

Una vez eliminados los inmuebles que no cumplen lo imprescindible, puede tener sentido asignar una puntuación para ordenar los restantes. A esto se le suele llamar scoring.

En este contexto, scoring significa simplemente ordenar candidatos según criterios definidos. No significa que el sistema sepa qué vivienda comprará el cliente.

Una puntuación puede tener en cuenta, por ejemplo:

• Cuántas preferencias se cumplen.
• Qué importancia tiene cada una para ese cliente.
• Qué distancia existe respecto a un valor deseado.
• La calidad o completitud de la información disponible.
• La proximidad de significado entre una preferencia expresada en texto y la descripción del inmueble.
• El feedback previo cuando se haya registrado de forma útil.

Qué puede significar esa puntuación por dentro

Internamente, un motor puede utilizar diferentes formas matemáticas de ordenar resultados. En búsquedas basadas en representaciones vectoriales, una opción habitual es la similitud coseno: una medida que compara la cercanía entre dos representaciones matemáticas del significado. También pueden utilizarse otras métricas o una segunda fase que vuelve a ordenar los candidatos después de obtener una primera lista.

Estas puntuaciones relativas son útiles para ordenar resultados dentro de una misma búsqueda o configuración. No deberían interpretarse como una probabilidad de compra. Un valor como 0,86 puede significar que un resultado está más cerca que otro según una métrica concreta, pero no que exista un 86 % de posibilidades de que el cliente compre esa vivienda.

Además, distintas técnicas de búsqueda y reordenación pueden producir escalas diferentes. Por eso, cuando el sistema combina filtros, búsqueda por significado y una segunda ordenación, lo importante para el negocio no es enseñar al agente todas las puntuaciones internas. Lo importante es transformar ese cálculo en una explicación comprensible: qué condiciones cumple, qué preferencias favorecen su posición y qué información falta o genera dudas.

Pero la puntuación debe leerse como orden de revisión, no como “probabilidad de interés”. Decir “87 % de compatibilidad” puede sonar preciso sin que exista una metodología que justifique qué significa ese 87 %.

Tampoco conviene fijar un umbral universal como “todo lo que supere 0,8 se envía”. Las puntuaciones dependen del método utilizado y pueden cambiar cuando combinamos diferentes sistemas de búsqueda y ordenación. Lo correcto es calibrar el sistema con ejemplos reales y observar qué resultados considera útiles el equipo comercial.

Una propuesta automática debería poder explicar por qué aparece

Cuando el agente abre una lista de diez inmuebles, una puntuación sin contexto ayuda poco. Saber que uno tiene “8,4” y otro “7,9” no explica qué diferencia existe entre ambos.

Una salida más útil puede ser:

Esta explicación permite al agente detectar rápidamente una mala interpretación. Si descubre que “terraza” era imprescindible, puede corregir la demanda. Si el cliente acepta balcón, puede reflejarlo. Si falta un dato crítico, puede comprobarlo antes de enviar.

La automatización deja así de ser una caja que escupe coincidencias y se convierte en una herramienta para reducir la búsqueda manual sin quitar visibilidad al equipo.

Qué hacer con los inmuebles descartados: guardar contexto, no prometer que “la IA aprende sola”

Una de las mayores pérdidas de información aparece después de la propuesta.

Un agente enseña cinco viviendas. El cliente descarta cuatro. Una semana después, otro agente vuelve a proponer dos de ellas porque el CRM solo sabe que “seguía buscando”.

Para evitarlo, la relación entre demanda e inmueble puede guardar estados como candidato, propuesto, interesado, descartado o pendiente de feedback. Cuando aporte valor, también puede conservar el motivo del descarte.

• Precio.
• Zona.
• Distribución.
• Planta.
• Estado de conservación.
• Característica ausente.
• Ya visitado.
• Ya no disponible.
• No encaja por un motivo libre registrado por el agente.

Guardar ese feedback no significa que el modelo de IA quede entrenado automáticamente. Puede servir para varias cosas más sencillas y, muchas veces, más útiles: evitar reproponer el mismo inmueble, actualizar una preferencia, generar una pregunta para el cliente o revisar la regla que estaba produciendo ruido.

Cuándo tendría sentido volver a proponer algo descartado

No conviene convertir “descartado” en una prohibición eterna. Puede cambiar una condición importante.

Un inmueble rechazado por precio podría entrar de nuevo si baja de forma relevante. Uno descartado por estar reservado podría volver si recupera disponibilidad. Una vivienda rechazada porque el cliente buscaba exclusivamente un barrio puede tener sentido meses después si el propio cliente amplía la zona.

La regla no es “nunca volver a mostrarlo”. Es no repetir automáticamente una propuesta que ya sabemos que no funcionó cuando nada importante ha cambiado.

Cuando un inmueble encaja con muchas demandas: no todo el mundo tiene que recibir el aviso a la vez

El problema contrario también existe. En una agencia con bastante volumen, un inmueble nuevo puede cumplir las condiciones básicas de muchas demandas al mismo tiempo. Si la automatización interpreta cada coincidencia como una orden de envío, el resultado puede ser una avalancha de avisos y un equipo comercial sin capacidad para gestionar las respuestas.

Por eso conviene separar de nuevo dos decisiones: el inmueble encaja con esta demanda y esta demanda debe revisarse o contactarse ahora. La primera pertenece al sistema de cruce. La segunda es una decisión de priorización comercial.

La agencia puede definir criterios operativos transparentes, por ejemplo:

• Que la demanda siga activa y haya sido confirmada recientemente.
• Que los criterios estén suficientemente completos para no enviar una propuesta a ciegas.
• Que el inmueble no se haya propuesto ya a esa persona.
• Que exista disponibilidad real del agente o una cola de revisión asumible.
• Que el cliente haya indicado una intención o plazo que haga razonable contactar ahora.
• Que se respete la política comercial de la agencia cuando existe inventario escaso.

La antigüedad de una demanda, por sí sola, tampoco debería convertirse en una regla automática universal. Una demanda antigua puede seguir perfectamente vigente y una reciente puede estar incompleta. La prioridad necesita una política explícita y datos actuales.

Además, esa priorización no debería basarse en categorías personales sensibles ni en características que no sean necesarias para gestionar la operación. El objetivo es ordenar trabajo comercial, no puntuar personas.

Qué hacer cuando no hay ningún inmueble adecuado

Una automatización mal diseñada siente la tentación de devolver algo siempre. Si no hay candidatos, empieza a relajar condiciones hasta fabricar una lista.

Eso puede dar una apariencia de eficacia, pero perjudica la experiencia comercial.

Si el cliente ha marcado 320.000 € como máximo real, el sistema no debería ampliar por su cuenta a 350.000 € solo para obtener resultados. Tampoco debería cambiar la zona, reducir habitaciones o ignorar una necesidad de accesibilidad sin que alguien haya autorizado el cambio.

Cuando no hay candidatos, el sistema puede hacer cosas mucho más útiles:

• Informar al agente de que la búsqueda no devuelve inmuebles que cumplan todas las condiciones obligatorias.
• Mostrar qué condición está eliminando más opciones.
• Preguntar qué criterio estaría dispuesto a flexibilizar el cliente.
• Mantener la demanda activa para comprobar nuevos inmuebles.
• Crear una tarea de seguimiento.
• Avisar cuando aparezca una nueva propiedad que sí cumpla.

Eso preserva algo esencial: la persona decide qué puede cambiar de su búsqueda; el sistema no reescribe sus condiciones para mejorar sus propios resultados.

Datos declarados, preferencias que el sistema deduce y privacidad

Hay otra distinción importante para una inmobiliaria que utiliza IA.

Si una persona dice “mi máximo son 320.000 €”, tenemos un dato declarado. Si descarta dos viviendas interiores y el sistema observa que quizá valora especialmente que sean exteriores, tenemos una preferencia que el sistema está deduciendo a partir de su comportamiento.

No deberían tener la misma autoridad.

La segunda puede ser útil para ordenar mejor o para que el agente pregunte: “Veo que las viviendas interiores no te han encajado; ¿quieres que prioricemos exterior?”. Lo que no debería ocurrir es que, sin confirmación, el sistema convierta esa observación en una condición rígida y elimine todas las viviendas interiores.

Además, no todo lo que puede deducirse debería guardarse.

Si una persona necesita una vivienda sin escalones, el proceso puede registrar una necesidad funcional de accesibilidad. No hace falta deducir ni almacenar por qué existe esa necesidad. Cuantos más datos personales incorporemos “por si ayudan al algoritmo”, mayor es la complejidad, la exposición y la responsabilidad del tratamiento.

La Agencia Española de Protección de Datos insiste en diseñar los tratamientos con los datos necesarios para la finalidad y en considerar la exactitud de los datos de entrada, salida e intermedios cuando intervienen sistemas de IA. Traducido al proceso inmobiliario: definir bien qué significa cada dato, mantenerlo actualizado y no acumular información personal que no sea necesaria para gestionar la demanda.

Ejemplo práctico: tres inmuebles para una misma demanda

Utilicemos una demanda ficticia sencilla:

• Operación: Compra.
• Precio máximo: 320.000 €, definido como límite.
• Dormitorios: Mínimo 2.
• Zona: Barrios A o B.
• Preferencias: Exterior, luminoso y cocina abierta.
• Terraza: Deseable, pero no imprescindible.

El inmueble B es el ejemplo más importante. Podría tener una descripción espectacularmente parecida a lo que el cliente ha contado. Incluso podría obtener una gran puntuación en un sistema puramente semántico. Pero no debería desplazar al A ni aparecer como una recomendación prioritaria, porque no supera el primer filtro.

El C plantea un problema distinto. No sabemos si es luminoso. El sistema no debería convertir la ausencia de información en “sí” ni necesariamente en “no”. Puede marcar ese aspecto como no evaluable y dejar que el agente decida si merece la pena comprobarlo.

Esta diferencia entre incumple y no sabemos evita otra fuente habitual de errores. Una base de datos incompleta no debería dar una falsa sensación de certeza.

Qué debe sincronizarse con el CRM y qué pertenece a la lógica del cruce

La entrada anterior sobre integración entre CRM y ERP desarrollaba en profundidad quién manda sobre cada dato, cómo sincronizar y cómo evitar duplicados. Aquí la frontera es distinta.

Para este proceso necesitamos saber, como mínimo, dónde viven:

• La demanda y sus criterios vigentes.
• Los datos del inmueble y su estado comercial.
• La relación demanda–inmueble: candidato, propuesto, descartado, interesado.
• El historial de feedback.
• La siguiente acción comercial.

No hace falta que todo esté físicamente en la misma base de datos. Sí hace falta que la automatización sepa qué sistema debe consultar antes de actuar y dónde debe registrar el resultado.

Si el precio del inmueble se gestiona en una plataforma y el CRM conserva una copia desactualizada, el problema no se arregla con un algoritmo de recomendación mejor. Primero hay que resolver la autoridad y actualización del dato.

Errores que conviene diseñar antes de automatizar

Un sistema de cruce real necesita contemplar más cosas que el camino feliz. Entre las excepciones más habituales que merece la pena diseñar están:

• Demanda inactiva o desactualizada.
• Inmueble reservado, retirado o con precio modificado.
• Dato obligatorio del inmueble ausente.
• Preferencia expresada de forma ambigua.
• El mismo inmueble ya fue propuesto.
• El inmueble fue descartado y no ha cambiado ninguna condición relevante.
• Una nueva información del cliente contradice la demanda existente.
• Dos fuentes muestran estados distintos del inmueble.
• La IA encuentra una gran similitud de texto, pero el inmueble falla un criterio obligatorio.
• No existe ningún candidato que cumpla todos los requisitos.

Cada una necesita una salida. A veces será descartar. Otras, pedir confirmación. Otras, crear una tarea. Y en algunos casos habrá que dejar el inmueble en una cola de revisión porque el sistema no dispone de información suficiente.

Automatizar no significa eliminar esas situaciones. Significa conseguir que no queden escondidas dentro de una lista de resultados aparentemente correcta.

Cómo probar el sistema antes de automatizar el envío de propiedades

El error más caro sería construir el motor de cruce y conectarlo directamente con el cliente desde el primer día.

La fase inicial debería funcionar como recomendación interna para los agentes. El sistema genera candidatos y el equipo decide cuáles habría enviado realmente.

Un piloto razonable puede seguir esta secuencia:

1. Seleccionar un conjunto de demandas activas con información suficientemente buena.
2. Definir para cada una qué criterios son obligatorios y cuáles son preferencias.
3. Comprobar la calidad de los campos de los inmuebles que se utilizarán.
4. Crear el primer filtro con condiciones claras.
5. Añadir una ordenación sencilla entre los candidatos que quedan.
6. Incorporar IA solo en criterios de texto donde realmente ayude.
7. Mostrar la explicación de cada candidato al agente.
8. Comparar propuestas del sistema con las que habría seleccionado el equipo.
9. Registrar falsos positivos, datos faltantes y motivos de descarte.
10. Ajustar criterios antes de automatizar cualquier envío externo.

Qué medir

El número de coincidencias generadas es una métrica pobre. Un sistema puede duplicarlas y empeorar la operación.

• Porcentaje de candidatos que el agente considera irrelevantes.
• Propuestas descartadas por incumplir criterios que deberían haberse detectado antes.
• Demandas sin candidatos válidos.
• Campos críticos de inmueble que faltan con frecuencia.
• Propuestas repetidas que se han evitado.
• Porcentaje de descartes con motivo conocido.
• Tiempo desde que aparece un inmueble adecuado hasta que el agente lo revisa.
• Correcciones manuales del orden de candidatos.
• Casos en los que la IA aporta una relación útil que los filtros normales no detectaban.
• Casos en los que la IA genera ruido y debe ignorarse.

Solo cuando el sistema demuestra que reduce búsqueda manual sin aumentar falsas coincidencias tiene sentido plantearse el siguiente nivel: automatizar determinados envíos, alertas o seguimientos.

El último metro: WhatsApp o email deberían comunicar la selección, no decidirla

Una vez que el sistema ha encontrado candidatos válidos y la agencia decide que pueden enviarse, aparece la última parte del proceso: hacer llegar la propuesta al cliente por el canal adecuado.

Ese envío puede integrarse con email, WhatsApp Business Platform u otras herramientas de mensajería que utilice la agencia, siempre de acuerdo con las reglas del canal, preferencias de contacto y configuración de la empresa. Pero conviene mantener la arquitectura separada.

La diferencia es importante. Si WhatsApp o el sistema de emailing vuelven a decidir por su cuenta qué propiedades enviar, terminamos duplicando lógica y perdiendo control. El canal debe recibir una selección ya gobernada por el proceso.

En un piloto, además, no automatizaría el envío desde el primer día. Empezaría mostrando las propuestas al agente. Cuando la calidad esté medida y las reglas de comunicación estén claras, se puede automatizar el último tramo para determinados casos y mantener revisión humana en otros.

La mejor automatización no es la que más propiedades propone

El objetivo de una inmobiliaria no debería ser que cada demanda reciba automáticamente una lista más larga. Debería ser que el equipo dedique menos tiempo a revisar opciones claramente inadecuadas y más tiempo a las que sí merecen una conversación.

Eso exige algo menos espectacular que pedirle a una IA que “encuentre la casa perfecta”, pero mucho más útil en producción: criterios bien definidos, datos vigentes, una separación clara entre lo obligatorio y lo preferido, un sistema de ordenación comprensible y un historial que recuerde qué se propuso y qué ocurrió después.

La IA tiene un papel real. Puede entender lenguaje menos estructurado, relacionar expresiones distintas y ayudar a ordenar mejor. Pero su valor aparece después de poner orden en el proceso, no antes.