Un flujo de onboarding de compradores en preventa conecta la reserva, la identidad del comprador, la unidad, los requisitos de documentos aprobados, el contexto de pago, las comunicaciones y la propiedad de excepciones antes de que el expediente avance al siguiente estado autorizado. El flujo coordina la evidencia y los traspasos; no decide si un contrato o documento es legalmente suficiente.
Define el evento de entrada del onboarding
El flujo necesita un evento observable que establezca cuándo comienza el onboarding. Para muchos desarrolladores, ese evento puede ser una reserva aprobada u otro estado de venta autorizado internamente. El evento exacto debe provenir de la política operativa del desarrollador y de sus sistemas aprobados.
En la entrada, el flujo debe capturar o referenciar:
- el identificador de la reserva y su estado actual;
- el registro del comprador en el CRM o sistema de compradores aprobado;
- el registro de la unidad y el proyecto en el sistema de inventario o de proyecto aprobado;
- los equipos responsables de ventas y de administración de contratos;
- el conjunto de requisitos aprobado que aplica al proyecto y al tipo de transacción;
- el contexto del calendario de pagos aprobado, cuando corresponda; y
- la fecha, la fuente y el actor detrás del evento de entrada.
Comenzar desde un evento definido evita que un registro en borrador, abandonado, duplicado o de otro modo no aprobado inicie silenciosamente el trabajo posterior. Si el contexto de entrada está incompleto o en conflicto, el flujo debe crear una excepción en lugar de asumir cuál registro es el correcto.
Establece el contexto del comprador y la unidad
La relación entre el comprador y la unidad es la columna vertebral del onboarding. Cada requisito, comunicación, referencia de pago, tarea y traspaso debe permanecer conectado a ese mismo contexto.
Una secuencia de configuración práctica es:
- Leer el estado de la reserva aprobado desde su fuente autoritativa.
- Cotejar la reserva con el registro del comprador usando identificadores aprobados.
- Cotejar la reserva con el registro del proyecto y la unidad.
- Confirmar el responsable interno de la etapa actual.
- Identificar conflictos, duplicados, campos faltantes o cambios no autorizados.
- Enrutar el contexto sin resolver al responsable humano con nombre.
- Registrar la relación validada para uso del resto del flujo.
El flujo puede coordinar el cotejo, pero no debe fusionar identidades de compradores, cambiar la asignación de una unidad ni resolver un conflicto material sin los permisos y la revisión humana definidos por el desarrollador.
Aplica el conjunto de requisitos aprobado
Los requisitos de documentos deben provenir de una fuente aprobada, mantenida por el desarrollador y sus asesores autorizados. El flujo puede aplicar ese conjunto de requisitos al contexto del comprador y la unidad, pero no debe inferir requisitos legales ni crear nuevos.
Para cada elemento requerido, da seguimiento a hechos operativos separados:
- qué requisito aprobado satisface;
- quién se espera que lo entregue;
- si se recibió un archivo o registro;
- cuándo y por qué canal se recibió;
- si pasó verificaciones técnicas básicas, como un formato legible;
- si está a la espera de revisión autorizada;
- si un revisor autorizado lo aprobó, rechazó o solicitó una corrección; y
- qué responsable de excepciones se hace cargo si la ruta rutinaria se detiene.
La recepción no es aprobación. Un archivo que llega a un repositorio prueba que algo se recibió; no establece que el documento esté completo, vigente, sea auténtico, exigible o suficiente. Esas determinaciones corresponden al revisor autorizado y al proceso aprobado.
El flujo de preparación de documentos ofrece una estructura reutilizable para mantener distintas la evidencia, el estado de revisión y la propiedad de excepciones.
Mantén el contexto de pago separado del estado de la transacción
El onboarding puede necesitar contexto de pago, como un calendario aprobado, una referencia de depósito de reserva o una condición requerida antes del siguiente traspaso. Ese contexto debe permanecer separado del registro financiero autoritativo.
Un calendario aprobado describe lo que se espera. Un registro de transacción describe lo que el sistema financiero ha registrado. Un estado liquidado refleja el estatus reconocido por el proceso financiero aprobado. Estos estados no deben colapsarse en un solo campo de "pagado".
Durante el onboarding, el flujo puede:
- referenciar el calendario aprobado y el hito relevante;
- solicitar o conservar evidencia permitida;
- leer el estado registrado desde el ERP o sistema financiero aprobado;
- crear tareas rutinarias o comunicaciones aprobadas a partir de ese estado; y
- enrutar discrepancias, disputas, reversos, evidencia poco clara o registros faltantes a finanzas.
El flujo no debe inferir que se recibieron o liquidaron fondos a partir de un mensaje del comprador, una imagen cargada, una notificación externa o una fecha esperada. Finanzas sigue siendo responsable del estado autoritativo de la transacción y de cualquier decisión de excepción.
Usa estados de onboarding explícitos
Los estados explícitos ayudan a los equipos a entender lo que se sabe sin exagerar la preparación.
| Estado | Significado operativo | Siguiente paso permitido |
|---|---|---|
| No iniciado | El evento de entrada aprobado no ha ocurrido o el contexto no está disponible | Esperar el evento de entrada o resolver el contexto faltante |
| En progreso | El trabajo rutinario de onboarding está en marcha y quedan elementos requeridos abiertos | Continuar solicitudes, recolección y coordinación aprobadas |
| Listo para revisión | La evidencia definida está disponible para un revisor autorizado | Enrutar el expediente para revisión sin declarar aprobación |
| Bloqueado | Una dependencia conocida impide que la ruta rutinaria continúe | Asignar la dependencia a su responsable |
| Excepción | Los hechos entran en conflicto con la política o requieren una decisión autorizada | Pausar la automatización rutinaria y escalar con evidencia |
Estos son estados operativos, no conclusiones legales. "Listo para revisión" no significa listo para contrato, aprobado, en cumplimiento o completo, a menos que un revisor autorizado registre esa decisión separada en el sistema aprobado.
Los cambios de estado deben conservar:
- el estado anterior y el nuevo;
- la evidencia de origen;
- el actor o la automatización aprobada responsable;
- la versión de política aplicable;
- la marca de tiempo; y
- cualquier excepción sin resolver.
Límites de revisión humana y excepciones
Un flujo de onboarding controlado necesita puntos visibles donde la automatización se detiene. La revisión humana es apropiada cuando:
- la identidad del comprador, la reserva, el proyecto o el contexto de la unidad están en conflicto;
- el conjunto de requisitos falta, es ambiguo o parece desactualizado;
- debe evaluarse el contenido, la suficiencia, la firma, la validez o el efecto legal de un documento;
- el comprador solicita un cambio en términos contractuales, financieros, de título, de financiamiento o específicos de la jurisdicción;
- la evidencia de pago no coincide con el ERP o el registro financiero aprobado;
- un estado esperado está disputado, revertido o poco claro;
- una comunicación está fuera del lenguaje o los permisos aprobados;
- un plazo, exención, aprobación, liberación o decisión de contrato requiere autoridad; o
- el siguiente paso cambiaría una política o requisito aprobado.
Cada excepción debe identificar el equipo responsable, la evidencia de origen, el momento en que se planteó, la ruta de resolución permitida y la decisión autorizada. Evita usar una cola general sin responsable, porque eso solo traslada el trabajo desconectado a un nuevo lugar.
Prepara un traspaso de contrato autorizado
El propósito del flujo no es producir una conclusión legal automática. Es preparar un traspaso claro, respaldado por evidencia, hacia la persona o el equipo autorizado para revisar el expediente y determinar el siguiente estado.
Un paquete de traspaso útil puede incluir:
- el contexto validado del comprador, el proyecto, la unidad y la reserva;
- el conjunto de requisitos aprobado aplicable y su versión;
- los elementos recibidos con su procedencia y estado de revisión;
- el contexto de pago aprobado y el estado financiero registrado, mantenidos por separado;
- un historial de actividad y comunicación;
- las excepciones abiertas, resueltas y escaladas;
- responsables con nombre para cada elemento sin resolver; y
- la decisión autorizada específica que se está solicitando.
El revisor debe poder rastrear cada hecho material hasta su fuente. Tras la revisión, el resultado autorizado debe registrarse en el sistema aprobado antes de que el flujo avance.
Lista de verificación de onboarding de compradores
Usa esta lista para evaluar un recorrido real de onboarding:
- El evento de entrada está aprobado, es observable y está documentado.
- Los registros de comprador, reserva, proyecto y unidad tienen fuentes autoritativas.
- La relación comprador-unidad se valida antes de que comience el trabajo posterior.
- Los requisitos provienen de una fuente aprobada por el proyecto y revisada por asesores.
- La recepción, las verificaciones técnicas, la revisión y la aprobación son estados separados.
- El contexto del calendario de pagos está separado del estado registrado y liquidado.
- Cada acción rutinaria está permitida por una política aprobada.
- Cada excepción tiene un responsable con nombre y una ruta de resolución.
- Las comunicaciones y decisiones sensibles requieren la revisión apropiada.
- El traspaso de contrato incluye procedencia y elementos sin resolver.
- Una persona autorizada registra el resultado final.
Lleva el flujo a la práctica
Mapea un recorrido de reserva a contrato usando los sistemas, equipos y políticas ya vigentes. Comienza con el evento de entrada aprobado, asigna una fuente autoritativa a cada tema operativo, y luego define la evidencia y la decisión humana requeridas en cada cambio de estado.
Usa atención al comprador para coordinar la comunicación rutinaria en torno a ese recorrido, manteniendo la revisión de documentos y las decisiones de contrato con sus responsables autorizados. Antes de elegir la automatización, haz que los equipos internos responsables y los asesores profesionales aprueben el conjunto real de requisitos, los límites de revisión y los criterios de traspaso del proyecto.
