We started building the pre-leasing operation for Boardwalk House while the 47-unit property was still under construction. The useful part was not the AI by itself. It was forcing every lead, decision, and handoff into an operating system the team could actually use.
People were already finding the property through the website, listing sites, phone calls, and text messages. We needed to respond without pretending the building was ready, losing the inquiry, or asking a leasing agent to reconstruct the conversation later.
That sounds like a CRM project. It turned into a broader operating project.
One person can look like three leads
A prospect might submit a website form, call from the same phone number an hour later, then reply by text using a different version of their name. If each channel creates an isolated record, the team sees three leads and the prospect gets three versions of the same follow-up.
We had to define the prospect record before adding more automation. At a minimum, that record needs the person's name, verified contact information, original source, desired unit or unit type, target move-in date, communication preferences, contact and consent history, current status, next action, assigned team member, and a complete interaction history.
The exact fields will vary by operator. The principle does not. A new inquiry should add context to one durable record whenever the evidence supports a match. It should not create another disconnected row just because it came through a different system.
A CRM record is not follow-up
Early on, it was tempting to treat successful record creation as the end of the workflow. It is only the start.
Every lead that needs action also needs an owner, a deadline, and a fallback. If a tour request goes to a leasing agent and nobody accepts it, the system should not quietly wait. It should create another task or route the request to someone else. If the prospect's information is incomplete, that should be visible as a problem to resolve, not buried in call notes.
We use simple staff responses where possible. Accept means the person owns the next step. Decline requires the workflow to keep moving. A timeout is treated as an operating event, not as silence.
The voice agent needs permission to stop
A voice agent can handle a clean inquiry: collect contact information, ask what the caller needs, record timing and unit preferences, and explain what is known. The harder design question is when it should stop.
We found several cases that should move to a person: poor audio, a caller name that conflicts with the phone record, a request for a short-term stay, uncertainty about pricing or opening dates, and a tour request that requires staff confirmation. The agent should preserve what it knows, flag what is uncertain, and create a callback task.
Guessing is worse than handing off. A confident but wrong answer about availability or timing creates more work than a short delay.
Keep the systems in their lanes
Our property-management system handles property-management work. Twenty is the working CRM. Calls, texts, the website, and listing sources each have their own jobs. We added an internal operating layer to maintain the durable prospect history, normalize events, reduce duplicates, and create tasks across those tools.
I do not think one application needs to do everything. I do think the team needs one clear answer to each of these questions:
- Where is the complete prospect history?
- Which system owns the next action?
- What happens when an integration or message fails?
- Who can correct a bad match or incomplete record?
If the answers change depending on who is working that day, the stack is not finished.
Test the awkward cases first
The normal demo is easy. A prospect submits perfect information, the record appears, and a team member follows up immediately. Real leasing traffic is messier.
We now pay more attention to duplicate forms, malformed email addresses, caller-ID mismatches, incomplete calls, missed showing deadlines, carrier delivery failures, and prospects who use several channels. Those cases expose whether the process has a real fallback or only a happy path.
The build order I would use again
- Define the prospect record and required history.
- Connect the lead sources already producing inquiries.
- Assign ownership, deadlines, and fallback rules.
- Add matching and duplicate protection.
- Add voice or messaging agents where the underlying process is stable.
- Connect the CRM and property-management system at the points where each becomes useful.
- Test incomplete calls, duplicate submissions, missed assignments, and delivery failures.
- Add reporting after the workflow is reliable enough to measure.
AI helps us answer quickly, collect information, and carry context between channels. The harder work is deciding what should happen when the conversation does not follow the plan. That is where most of the operating value sits.