A controlled real estate ERP workflow keeps one governed chain of customer, unit, reservation, contract, financial, service, and handover records. Each stage has a named owner, entry condition, approval authority, downstream consequence, and reversal rule.
A real estate ERP workflow must preserve far more than a sales stage. From the first enquiry to final handover, the same customer, unit, commercial terms, contract, payment obligations, service history, and approvals move through several departments. If each department rebuilds that context, the organization creates competing versions of availability, contractual status, customer balance, and handover readiness.
Direct answer: A controlled lead-to-handover workflow keeps one governed chain of customer, unit, reservation, contract, financial, service, and handover records. Each stage has a named owner, entry condition, approval authority, downstream consequence, and reversal rule. CRM continues supporting the relationship, while ERP protects the operational and financial commitments that other departments must trust.
What must a lead-to-handover workflow preserve?
The workflow begins while intent is uncertain. A person may be an unqualified lead, a broker-referred prospect, or an existing customer considering another unit. CRM should preserve source, ownership, communication, interests, and next actions without prematurely creating a contractual or accounting commitment.
The operating risk begins when interest affects a scarce or governed record. Holding a unit changes availability. Approving a discount changes commercial authority. Accepting a reservation may create an expiry, evidence requirement, or payment condition. Approving a contract establishes parties, a unit, obligations, and a legal document history. Collections affect balances and customer statements. Handover may depend on contract status, payment clearance, unit readiness, inspection, documentation, and final approval.
These are different responsibilities, but they should not create different truths. Archer’s guide to the real estate CRM-to-ERP control boundary explains where engagement should hand over to operational authority. This article follows what happens after that boundary across the complete lifecycle.
The broader Real Estate ERP model for property developers includes the same connected principle: customer-facing work remains linked to projects, units, contracts, installments, accounting, Customer Experience, and handover rather than being separated into department-specific files.
Real estate ERP workflow: eight stages from lead capture to handover
The exact stages, names, approvals, and documents vary by developer, company, country, and contract route. The following framework is therefore a control model, not a universal legal procedure.
| Lifecycle stage | Records that must remain connected | Control question |
|---|---|---|
| 1. Lead and qualification | Source, broker, customer identity candidate, preferences, communication, sales owner, stage, and next action. | When is the enquiry qualified enough to become a governed customer or transaction? |
| 2. Unit and availability | Company, project, phase, building, unit, property attributes, availability, price basis, and status history. | Which record is authoritative when several channels or salespeople offer the same inventory? |
| 3. Reservation and approval | Customer, unit, approved price and terms, hold or reservation status, evidence, expiry, cancellation, and release. | Who may create the commitment, and what automatically happens if it expires or is rejected? |
| 4. Legal review and contract | Contracting parties, unit, commercial basis, customer documents, legal review, approval status, contract version, signatures, amendments, and active status. | Can the organization explain which contract version was approved, by whom, and what it authorizes? |
| 5. Payment plan and collections | Approved schedule, obligations, due dates, cheques or other instruments, receipts, allocations, rescheduling, discounts, penalties, and outstanding amounts. | Does every collection and approved change reconcile to the contract and current customer statement? |
| 6. Accounting and statement | Company, accounts, journal entries, partner, analytic references, reconciliation, balances, and statement position. | Can Finance trace the accounting consequence back to the approved unit, contract, obligation, and collection? |
| 7. After-sales and readiness | Requests, documents, responsible team, milestones, customer communication, readiness conditions, inspections, and unresolved issues. | Can Customer Experience continue the journey without rebuilding the customer, unit, contract, and payment context? |
| 8. Handover | Eligibility, unit readiness, financial clearance, inspection, required documents, approvals, delivery, keys, acknowledgements, and continuing service history. | What evidence proves that delivery was authorized and that all open conditions were handled? |
Odoo’s official documentation illustrates the normal commercial progression from qualified lead to opportunity and linked customer. A real estate implementation extends that connected principle into controlled inventory, reservations, contracts, payment obligations, service, and handover. Archer’s Odoo ERP platform overview describes the wider connected-app foundation.
How should control gates and record ownership work?
A process diagram is useful only when each arrow represents a real control. Every transition should identify the entry condition, authorized action, approving role where required, records created or changed, notifications, evidence retained, and reversal or exception route.
Keep one governed customer and unit identity
The lead record may begin with incomplete information, but the contractual and accounting party must become governed before commitments are created. Duplicate detection, company or individual status, contact details, contracting role, and document references should flow forward instead of being retyped by Legal, Finance, or Customer Experience. The same principle applies to the unit: one authoritative structure and status history must support availability, reservation, contract, service, and handover.
Make legal review part of the workflow, not an offline pause
Contract management is more than storing the final PDF. The system should make the proposed commercial basis, contracting parties, supporting documents, legal review, approval status, final version, and later amendment history explainable. Foreign customers can introduce a different document or approval route, but the ERP should not invent the legal requirements. It should enforce the route approved by the organization’s legal owners and preserve the evidence that allowed the contract to proceed.
Carry approved consequences forward
Approving a contract may activate the payment plan, broker entitlement conditions, customer statement, accounting treatment, and future service obligations. A payment reschedule may affect commercial value, collections, accounting, and handover clearance. A cancellation may release the unit while triggering refund, accounting, commission, and reporting consequences. These outcomes should follow explicit rules rather than messages and spreadsheet corrections.
How do changes and exceptions travel through the lifecycle?
A workflow should be designed around the normal route and the exceptions that test whether its records are truly connected.
- Reservation expiry or rejection: release the unit through an authorized action, preserve the history, and prevent an expired hold from remaining available in one channel and blocked in another.
- Customer or unit change: preserve the original decision and approval while updating the active customer-unit relationship and every affected commercial or operational record.
- Contract amendment, transfer, or cancellation: maintain version, authority, effective date, replaced obligations, unit status, financial consequences, and document history.
- Payment-plan change: distinguish the approved commercial plan from receivables, collections, accounting treatment, and the current customer statement.
- Cheque or collection exception: record replacement, return, split, grouping, allocation, or reversal without losing the obligation and accounting relationship.
- Handover delay or failed condition: preserve the readiness, inspection, payment, document, approval, and communication context instead of changing one isolated milestone.
The payment stage needs deeper rules than this lifecycle overview can provide. Archer’s guide to real estate ERP installment management explains approved schedules, NPV-driven changes, collections, cheques, allocations, accounting, and customer statements in detail.
Historical continuity matters as well. When an existing portfolio moves into a new platform, the organization cannot migrate customers, contracts, installments, payments, and service history as unrelated files. The related real estate ERP data migration guide explains how those relationships should survive extraction, transformation, validation, and acceptance.
What New Plan, Centrada, and MBG demonstrate
The following Archer Solutions projects provide different evidence for the connected lifecycle. They are project-specific examples, not universal legal, accounting, or performance claims.
New Plan Developments: the broadest documented transactional lifecycle
Archer implemented Odoo 17 for New Plan Developments, supporting 100 users across five real estate projects. The delivered environment connects CRM and brokers, unit availability, reservations, contracts, installment schedules, collections, accounting, approvals, after-sales, handover, and management reporting.
New Plan’s contract management also supports contracts with foreign customers, and the implemented contract cycle includes legal review and approval before the contract progresses. This is evidence of the project’s controlled route; it does not imply that every foreign-customer contract uses identical documents or legal requirements. The wider result is one data path from the first customer interaction through contract execution, payment follow-up, service requests, and handover.
Centrada Developments: connected NPV, finance, Customer Experience, and handover
For Centrada Developments, Archer implemented Odoo 18 on Odoo.sh for 130 users. The confirmed scope connects real estate and NPV operations, CRM and sales, brokers and commissions, accounting and finance, Helpdesk and Customer Experience, handover, and Human Resources. WhatsApp communication follows the customer workflow, while the real estate lifecycle remains intentionally distinct from construction operations, which were outside the confirmed scope.
MBG Developments: governed adoption across multiple projects
Archer’s implementation for MBG Developments established one Odoo 19 environment for 120 users across multiple projects. It connects lead, opportunity, sale, NPV payment plan, broker commission, finance, Customer Experience, and handover, supported by Human Resources and relevant integrations. MBG demonstrates that the lifecycle must remain governed not only in design, but also across departments, users, and project activity.
Operating principle: A lifecycle is connected only when an authorized change at one stage produces the correct, traceable consequences in every dependent stage—and when teams can still explain the original decision.
How should buyers test a real estate ERP workflow?
A presentation of modules is not enough. Ask the proposed implementation team to demonstrate one realistic transaction from initial lead through handover, then introduce an exception. The demonstration should show the following:
- Origin: How are lead source, broker, customer interest, ownership, and communication preserved?
- Identity: When does the lead become the governed contracting and accounting party, and how are duplicates prevented?
- Inventory: Which record owns availability, holds, reservations, release, and unit-status history?
- Authority: Who may approve price, terms, exceptions, legal review, contract activation, and later amendments?
- Documents: How are required documents, versions, approval evidence, and outstanding conditions tracked without exposing them to unauthorized users?
- Financial continuity: Can the team trace the contract through payment plan, collection, allocation, accounting, reconciliation, and customer statement?
- Customer continuity: Can Customer Experience see the correct unit, contract, payment, request, and communication context?
- Handover control: Which conditions establish eligibility, and who may approve inspection, delivery, keys, and unresolved exceptions?
- Change handling: What happens when the customer, unit, contract, payment plan, cheque, or handover date changes?
- Auditability: Can the organization identify who changed each material record, when, under which authority, and with what consequence?
This lifecycle test belongs inside the wider provider decision. Archer’s 10-point real estate ERP implementation partner evaluation matrix places end-to-end coverage alongside industry understanding, architecture, delivery governance, proof, support, scalability, and team alignment.
For Egypt and regional real estate operations, the detailed design may need to reflect installment-led sales, cheque handling, multiple legal companies, foreign-customer contract routes, country-specific accounting, commission policies, and different customer-service responsibilities. Geography changes the configured rules and evidence; it should not create competing customer, unit, contract, or payment truths.
The strongest workflow is not the one with the most screens. It is the one that preserves context, authority, and consequences as responsibility moves from Sales to Legal, Finance, Accounting, Customer Experience, and Handover. If your organization is defining or validating this lifecycle, discuss your real estate ERP project with Archer Solutions.