Propuesta funcional — Sistema de gestión inmobiliaria
v2 · incorpora el flujograma del clienteRevisamos el flujograma (Excel) que nos pasó el cliente y lo cruzamos con la v1. La estructura general se mantiene — nube, app web + Android, dashboard gerencial — pero el cliente separa el negocio en tres líneas con reglas propias: Alquiler, Administración de propiedades y Venta, cada una con su propia ficha, acuerdo y estados. Esta versión lo incorpora.
Sigue siendo válida: agentes (web/Android) y gerencia (dashboard) leen y escriben sobre la misma base en la nube. Lo que cambia puertas adentro del núcleo se detalla en el diagrama 2.
Esto es lo que trae el flujograma del cliente y la v1 no tenía: alquiler, administración de propiedades (cobro por cuenta de terceros) y venta comparten el maestro de propiedades y el CRM de clientes, pero de ahí en más cada línea tiene su propia ficha, su propio acuerdo y su propio cierre.
El diagrama de arriba dibuja alquiler, administración y venta como tres carriles paralelos, pero eso describe el flujo de cada operación, no dice que una propiedad deba elegir uno solo. En la realidad, "vendo o alquilo" es un caso frecuente: una misma propiedad puede tener una operación de Alquiler y una de Venta abiertas al mismo tiempo (o, si el propietario cambia de idea durante la administración, pasar a tener también una operación de Venta activa). El modelo de datos correcto es Propiedad 1 → N Operaciones, cada Operación con su propia línea, su propio Acuerdo y su propia máquina de estados — nunca "esta propiedad es de alquiler" como atributo fijo de la ficha.
El cliente define el ciclo de vida como una máquina de estados explícita, no solo "publicado / no publicado". Alquiler y venta comparten los mismos 6 estados; administración usa una variante de 5 pensada para un vínculo continuo, no para un cierre puntual.
Se mantiene igual que en la v1 — sigue siendo el mejor ejemplo end-to-end. El paso 4 ("Gestión del alquiler") es ahora, en detalle, el "Acuerdo Alquiler" + los 6 estados del diagrama 3.
La versión de bolsillo de la sección 4, abierta en los nueve pasos reales: cuándo se toca el maestro de Personas, cuándo cambia el rol de alguien, cuándo se dispara la alerta de vencimiento, y qué decisión hay que tomar al final.
Checklist actualizado con lo que trae el flujograma del cliente: se suman ficha de propiedad, CRM de clientes, administración y autogestión de propietarios. Los campos de la ficha de propiedad se completaron además tomando como referencia arquibrokers.com — tipo de propiedad, ambientes, superficie cubierta/total, amenities y apto crédito no estaban en el flujograma original y el cliente los validó como una buena adición.
El Excel original del cliente, en la hoja "Ficha para ingresos", lista menos campos para Venta que para Alquiler — a Venta le faltan orientación, aptos por piso, cantidad de pisos, parrillero, mascota, antigüedad, garantía y nombre de administración. Al revisarlo, el cliente aclaró expresamente que para él los atributos de la propiedad son los mismos sin importar la línea de negocio — la ficha no cambia según sea alquiler, administración o venta, solo cambia el campo de aspiración (alquiler / venta) y los datos del acuerdo comercial. Queda así, como definición explícita del cliente, no como supuesto nuestro: una única Ficha de propiedad, tal como está en la sección 6, sin variantes por línea.
El propio flujograma del cliente deja puntos marcados con signos de interrogación. Las sumamos a las nuestras para resolver antes de definir modelo de datos y pantallas.
Publicación en portales, ¿manual o vía API? El flujograma marca "Publicar web y portales" con cinco signos de pregunta, y en el maestro de propiedades vuelve a aparecer como "Publicar web y portales — API". Define si la integración (MercadoLibre incluido) es automática o carga asistida. Fuente: Flujograma.xlsx — hoja "Flujograma"
Costos — ¿de qué? Aparece como nota suelta junto al cierre de venta ("Costos?"), sin precisar si se refiere a costos operativos de la inmobiliaria, costos a cargo del propietario, o gastos a descontar en la liquidación de administración. Fuente: Flujograma.xlsx — hoja "Flujograma"
Facturación electrónica y forma de pago: el flujo la marca como paso separado, con "propietario e inquilino si aplica" y "opcional" junto a la forma de pago. Conviene confirmar si la facturación electrónica es obligatoria desde el día uno o si arranca opcional.
Alcance de la app Android: ¿la usan también los propietarios para la autogestión, o queda reservada a agentes y la autogestión es solo web?
Split de comisión entre agentes: el flujograma habilita "búsqueda entre colegas" — si dos agentes intervienen en una operación, ¿cómo se reparte la comisión o la tarifa de cobro?
Tres puntos que marcamos como importantes para definir junto con el proveedor antes de que arranque el desarrollo — no son detalles de diseño, son decisiones que cambian el alcance o el costo.
Seguridad de acceso: MFA y expiración de sesión. Definir si el segundo factor (tipo Google Authenticator) es obligatorio para todos los usuarios o solo para gerencia/administración, y cómo expira la sesión — ¿24 horas fijas, o por inactividad? Nuestra recomendación: MFA obligatorio para gerencia y administración (acceso a comisiones y liquidaciones), opcional para agentes de campo. Para la sesión, combinar las dos cosas en vez de elegir una: una sesión "de trabajo" que dura hasta 24 h desde el login, más un cierre automático por inactividad — corto (15–30 min) en las pantallas financieras y de administración, más largo en el resto. Un solo timeout fijo de 24 h sin control de inactividad deja una sesión abierta toda la jornada en un dispositivo que alguien más puede tomar.
Publicación en MercadoLibre. Ya lo marcamos como pregunta abierta en la sección 7, pero lo repetimos acá porque define alcance y costo: ¿integración automática vía API (sincroniza precio, estado y fotos) o carga manual asistida? Confirmar también si el plan de MercadoLibre que va a usar la inmobiliaria admite integración por API — no todos los planes la incluyen.
Guardado de contratos en la nube. Definir el detalle de cómo se almacenan (Acuerdo Alquiler, Acuerdo Administración, Acuerdo Venta y su documentación adjunta): acceso por URL firmada con expiración — nunca en un bucket público —, quién puede ver el documento de qué operación (agente asignado, gerencia, y el propietario en autogestión, cada uno con su alcance), y por cuánto tiempo se retiene un contrato después de "Liquidado" o "Finalizado".
Auditoría de negocio y log de sistema — son dos cosas distintas. Requisito del cliente, no solo recomendación nuestra: todo cambio de estado de una operación (Ingresado → Autorizado → … → Liquidado, y lo mismo para Administración) tiene que quedar auditado — quién lo cambió, cuándo, y desde/hacia qué estado. Lo mismo para cambios sobre el Acuerdo (comisión, tarifa, montos) y para el traspaso de una tarea entre áreas (ver el mapa del sistema completo) — eso es auditoría de negocio. Aparte, conviene un log de sistema más amplio y técnico: inicios de sesión, documentos subidos, ediciones de ficha, cambios de permisos. Los dos registros deberían ser de solo lectura incluso para quien hizo el cambio — si se pueden editar o borrar, dejan de servir como auditoría.
Calendario por usuario, con vencimientos y anotaciones diarias. Cada agente necesita su propio calendario — no solo turnos de visita, también anotaciones libres día a día (llamadas a hacer, seguimientos, recordatorios propios) además de los vencimientos automáticos de contratos y pagos. El usuario principal / administrador tiene que poder ver los calendarios de todos los agentes, individualmente o combinados, sin que cada agente tenga que compartírselo a mano. Definir si las anotaciones personales de un agente son privadas para gerencia o también visibles — probablemente el contenido libre debería ser propio, y solo los eventos ligados a una operación (visitas, firmas, vencimientos) visibles para gerencia.
Menú y permisos por línea de negocio. El sidebar del prototipo ("Pessi Studio") hoy muestra todo a cualquier usuario. En la versión real, lo que cada usuario ve tiene que depender de a qué línea está asignado: un usuario de Administración vería solo ese menú y esas propiedades; uno General (gerencia) vería todo; uno de Alquiler solo alquiler; uno de Venta solo venta. Y no son categorías cerradas — un mismo agente puede estar asignado a más de una línea a la vez (Venta y Alquiler, o Venta y Administración), y eso tiene que reflejarse mostrándole la unión de esos menús, no una sola línea fija. Queda pendiente de resolver en conjunto: el modelo de permisos (roles fijos vs. una lista de líneas asignadas por usuario) y cómo se combina con los roles de seguridad de la nota anterior (gerencia/administración con MFA obligatorio).