Our property-management system is an important system of record. We do not ask it to manage every lead source, communication, handoff, and exception across the business.
Most operators start with a property-management platform because leases, residents, accounting, maintenance, and reporting need a home. Then more tools arrive: a CRM, website forms, phone and text platforms, access control, listing services, and internal team workflows.
The common response is to force everything back into the property-management system. I understand the appeal. One system sounds simpler. In practice, it can make every workflow depend on a product that was built for a different job.
We give each system a defined role
For our current leasing stack, Rentvine handles property-management work. Twenty is the working CRM for prospects and follow-up. Our phone, text, website, and listing tools handle their respective channels. Slack is where many staff handoffs become visible.
An internal operating layer connects those systems. It receives events, normalizes records, reduces duplicates, creates tasks, and keeps an audit history of what happened.
That layer is not meant to replace the other products. It handles the gaps between them.
The source of truth depends on the question
"What is the source of truth?" is usually asked as if there can be only one answer. We use a more specific version of the question.
- For an executed lease and resident ledger, the property-management system should be authoritative.
- For an active prospect's history and next follow-up, the CRM should be authoritative.
- For whether a text was accepted or rejected by the carrier, the communications platform has the original event.
- For how those events connect and which task came next, the operating ledger keeps the durable history.
This avoids copying every field into every system and then pretending all copies are equally current.
The operating layer needs restraint
Custom software can become a problem if it tries to recreate leasing, accounting, or property management. We keep the internal layer focused on work the core systems do not handle well across product boundaries.
That usually includes:
- Matching one person across multiple lead sources
- Recording the original event and later status changes
- Creating owned tasks with deadlines and fallback rules
- Preventing the same batch or message from running twice
- Flagging failed integrations and incomplete records
If a vendor product already handles a function reliably, we use it. The internal layer should not become a vanity project.
Design around failures, not logos
A diagram of the stack can look clean while the operation is fragile. The better test is what happens when something fails.
If the CRM is temporarily unavailable, do we still retain the inquiry? If the text fails, does someone see it? If an integration rejects one resident record, can the team identify that record without reading a server log? If an employee declines a tour request, who owns it next?
Each connection should have an owner, an error path, and a way to correct the record. That is what turns a collection of subscriptions into an operating stack.
A practical way to map the stack
For each system, write down four things: the business job it owns, the records it controls, the events it sends or receives, and the person responsible when it fails. Then map only the handoffs the business actually needs.
I would rather have a small number of explicit connections than a complicated web of two-way syncs. The goal is not to make every application identical. It is to let the team find the current record, understand the next action, and recover when a tool does not behave as expected.