CRM genérico o software a medida: cómo decidirlo en una promotora

La decisión rara vez se plantea en frío. Llega cuando una promotora o comercializadora tiene tres promociones abiertas, un comercial externo por cada una, un ERP que no habla con nadie y una hoja de cálculo donde alguien apunta a mano qué reservas están firmadas. En ese punto se convocan demos de CRM, y en paralelo alguien sugiere que quizá habría que hacer algo propio. Las dos opciones son razonables. El error habitual es elegir por catálogo de funcionalidades en vez de por cómo funciona realmente el negocio.

Qué hace distinto a un CRM para promotora inmobiliaria

Un CRM generalista gestiona contactos, oportunidades y un embudo. Una promotora gestiona algo diferente: un inventario finito de unidades con estados que cambian (libre, reservada, contrato privado, escriturada), precios que se revisan por fases comerciales, un calendario de pagos ligado a certificaciones de obra, y personalizaciones de cliente que acaban en un cambio en la documentación de obra. El objeto central no es el lead, es la unidad. Cualquier herramienta que no entienda eso obliga a inventar campos personalizados hasta convertir el sistema en una maqueta frágil.

Por eso la pregunta "¿qué CRM para promotora inmobiliaria elegimos?" se contesta mal si solo se comparan precios por usuario. Lo que hay que comparar es qué parte del proceso real queda dentro del sistema y qué parte se sigue haciendo en Excel, WhatsApp y correos sueltos. La herramienta que deja menos fuera suele ganar, aunque tenga peor interfaz en la demo.

Cuándo el estándar es la respuesta correcta

Un producto de mercado tiene ventajas difíciles de replicar: está en producción en otras compañías, alguien lo mantiene cuando cambia una normativa o un canal de captación, y se puede tener funcionando en semanas y no en trimestres. Para una promotora que lanza una o dos promociones al año, con un equipo comercial reducido y procesos que no difieren mucho del resto del sector, el estándar es casi siempre la opción sensata.

Señales de que basta con un CRM vertical

El proceso comercial se parece al de cualquier otra promotora de tamaño similar. La postventa se gestiona con un volumen asumible de incidencias. No hay un ERP con lógica propia al que haya que atarse. Nadie del equipo tiene capacidad para especificar requisitos con detalle ni para hacer de interlocutor de un proyecto de desarrollo durante meses. Si se cumplen tres de estas cuatro, desarrollar es cargar con un coste que no se va a recuperar.

Cuándo tiene sentido construir

El desarrollo a medida se justifica cuando la diferencia operativa es real y sostenida en el tiempo. Algunos casos donde lo vemos con claridad: promotoras que trabajan con coinversores y necesitan reporting por vehículo de inversión con reglas propias; compañías que venden a través de una red mixta de comerciales internos, API y portales, con reparto de comisiones que ninguna herramienta estándar modela bien; operadores de build to rent que necesitan unir comercialización, contrato y explotación en un mismo dato; grupos que ya tienen un ERP muy asentado y prefieren construir la capa comercial encima antes que sustituirlo.

Hay un segundo motivo, menos técnico: el control del dato. Cuando el histórico comercial de diez años es un activo para decidir qué suelo se compra y a qué precio se lanza la siguiente fase, tenerlo en un modelo propio y exportable cambia la conversación. En un producto cerrado, el dato existe, pero con la estructura que decidió otro.

El punto intermedio que casi nadie evalúa

La disyuntiva pura entre comprar y construir es falsa la mayoría de las veces. Lo más frecuente en promotoras de tamaño medio es una combinación: un CRM estándar para la gestión comercial del día a día, y una capa propia para lo que el estándar no cubre — el configurador de personalizaciones, el panel de seguimiento de ventas por promoción para dirección, el portal de cliente donde el comprador ve su calendario de pagos y sube documentación.

Esa capa propia es software a medida, pero acotado: se construye sobre la API del CRM, resuelve un problema concreto y se puede retirar sin desmontar el resto. Cuesta una fracción de lo que cuesta una plataforma completa y suele resolver el ochenta por ciento del dolor real, que no está en registrar leads sino en todo lo que pasa después de la reserva.

Condición previa: que haya API

Este enfoque solo funciona si el CRM elegido tiene una API documentada, con webhooks y sin límites de llamadas absurdos. Es una pregunta que hay que hacer en la demo, antes de firmar, y pedir acceso a la documentación para que la lea alguien técnico. Un producto sin integración decente convierte cualquier necesidad futura en una petición al proveedor y una espera indefinida.

Lo que sale mal cuando se decide construir

El coste de un desarrollo no está en la primera versión. Está en los tres años siguientes. Una plataforma propia necesita mantenimiento, actualizaciones de dependencias, soporte cuando algo falla un viernes a las siete de la tarde y presupuesto anual para evolucionarla. Si la promotora no contempla esa partida recurrente, el sistema se degrada: nadie lo toca, deja de reflejar cómo se trabaja, y a los dos años el equipo vuelve a Excel en paralelo. Es el fracaso más común y casi nunca es culpa del código.

El segundo riesgo es de proceso. Un proyecto a medida requiere que alguien de la promotora dedique tiempo real — reuniones semanales, decisiones, validaciones — durante todo el desarrollo. Si ese interlocutor es un director comercial con tres promociones en marcha, las decisiones se toman tarde o no se toman, y el resultado refleja lo que el equipo de desarrollo supuso, no lo que la compañía necesita.

El tercero: construir para automatizar un proceso malo. Si el flujo de reserva a contrato tiene siete pasos manuales porque nadie lo ha revisado en una década, digitalizarlo tal cual produce un sistema caro que hace exactamente las mismas tonterías más rápido. Antes de escribir una línea de código conviene dibujar el proceso y quitarle todo lo que no sirva. Ese ejercicio a veces revela que el problema no requería software.

Cuándo no merece la pena ninguna de las dos

Si el equipo comercial no registra las visitas ni actualiza estados en la herramienta que ya tiene, cambiar de herramienta no arregla nada. El problema es de hábito y de incentivos: nadie usa un sistema que le da trabajo extra sin devolverle nada. Antes de una migración, merece la pena comprobar cuántos registros se actualizaron el mes pasado. Si la cifra es baja, el proyecto prioritario es otro.

Tampoco compensa mover nada en mitad del lanzamiento de una promoción. Una migración de CRM implica limpiar datos, formar al equipo y convivir un tiempo con dos sistemas. Hacerlo mientras se abre la caseta de ventas garantiza que los primeros meses de datos comerciales queden inservibles.

Cómo decidir en la práctica

Tres preguntas, por orden. Primera: ¿qué parte del proceso queda hoy fuera de cualquier sistema? Esa lista es el requisito real, no el catálogo del proveedor. Segunda: ¿esa parte es específica de la compañía o común al sector? Si es común, alguien ya la ha resuelto y se puede comprar. Tercera: ¿hay presupuesto recurrente y un interlocutor con tiempo? Sin las dos cosas, la respuesta es estándar, siempre.

Una cuarta pregunta útil para ordenar prioridades: si el sistema desapareciera mañana, ¿qué se perdería? Si la respuesta es "una agenda de contactos", casi cualquier herramienta sirve. Si la respuesta incluye el estado real del inventario, los calendarios de pago y el histórico de precios por fase, entonces la conversación sobre una plataforma a medida está justificada — y conviene empezarla por el modelo de datos, no por la interfaz.

El orden correcto

Modelo de datos primero, procesos después, interfaz al final. La mayoría de los proyectos que se tuercen lo hacen al revés: empiezan por las pantallas, se validan en una demo bonita, y tres meses más tarde aparece que una unidad puede estar reservada por dos personas a la vez o que no hay forma de representar una permuta. Definir bien qué es una unidad, qué es una reserva y cómo se relacionan con la obra y la contabilidad vale más que cualquier funcionalidad del comparativo.

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