One unit. Four different truths.
Development, leasing, facilities, and community management each keep their own record of the same property. This is the architecture behind a single unit record that all four actually agree on — without merging the teams or the software they already run.
The situation
The new owner has the keys. The system doesn't know that yet
A unit in a master-planned community changes hands. The sale completes, the title transfers, the new owner moves in with a signed contract in hand. Three weeks later, they're still calling the community office for an access card, because the community management portal still lists the previous owner as the resident of record.
Nobody did anything wrong. The developer's sales system correctly closed the transaction. It simply never told the community management platform, which is a different piece of software, often run by a different company entirely. The leasing team, the facilities contractor, and the owners' association each keep a version of "who lives here" — and after a sale, those four versions stop agreeing.
In a single building this is an inconvenience. Across a master-planned community with several thousand units in various stages of construction, handover, leasing, and resale at any given time, it's a constant, low-grade operational drag that nobody owns end to end.
Maintenance sent to the wrong party
A repair request reaches the previous owner or a vacated tenant, because facilities never learned the unit had changed hands.
Fees billed to the wrong account
Community service charges continue against a seller for months after closing, generating disputes that consume staff time to unwind.
A unit that's "finished" in one system and not in another
Construction marks a unit as handed over while leasing still shows it as unavailable, so it sits empty generating no revenue.
The architecture
The unit is the record — not the department
The fix doesn't merge the developer's ERP, the leasing platform, the facilities ticketing system, and the community management portal into one piece of software — that project rarely finishes. Instead, each unit gets a single reference record that reads status and ownership signals from all four systems and keeps them in agreement.
No system here is replaced — the record reads the status each one already tracks.
Method
Five steps, in order
Each function keeps its existing software. The unit record is proven on one building or phase before it extends across the master plan.
Define the unit as the anchor
Not the department, not the system — the physical unit itself becomes the single reference point every function reads from.
Map the four systems of record
The developer's sales or ERP system, the leasing platform, the facilities ticketing tool, and the community management portal — including third-party operators.
Build the integration layer
Ownership, occupancy, and handover status flow between systems automatically instead of through manual notification.
Add handoff triggers
A completed sale notifies facilities and community management the same day. A vacancy triggers an inspection prompt automatically.
Prove it on one phase, then extend
Roll out on the building or phase with the most resale and handover activity first, then extend across the master plan.
What changes
Fragmented, today — versus a single unit record
| What's being measured | Fragmented, today | Single unit record |
|---|---|---|
| Ownership change reaching all four functions | Days to weeks, manual notification | Same day, automatic |
| Maintenance requests after a sale or move-out | Often misrouted to the previous party | Routed to the current record |
| Community fee billing after resale | Disputed, corrected after the fact | Always billed to the current owner |
| New owner or tenant onboarding | Days, across several departments | Same day, one record |
Direct answers
Questions asked directly about this specialization
No. The unit record reads status and ownership signals from each existing system. Replacing a core system is occasionally part of a later phase, but only when the assessment shows it is genuinely necessary.
Yes — this is one of the most common situations it is built for. The integration layer connects to the third-party operator's system the same way it connects to an in-house one, without requiring them to change their software.
Yes. The unit record tracks each unit through its own lifecycle stage, so a phase still under construction and a phase in resale can be managed through the same layer without conflict.
Only what is necessary to map the systems and workflows involved is accessed, and only after a mutual non-disclosure agreement is in place. Access is scoped and time-limited.
Still tracking four versions of who owns what?
This is solved through a systems architecture engagement — mapping your specific development, leasing, facilities, and community management systems and building the unit record over what you already run.
Start the conversation Confidential. No proposal before the assessment.