A caller dials a residential brokerage at 7:42pm on a Tuesday. The voice agent picks up. The very next thirty seconds decide whether this call is worth $14,000 in gross commission or $2,200, whether it routes to the listing partner or the buyer rep on duty, and whether the CRM record gets fifteen fields populated or nine. The brokerage has one number. The caller could be either side of the transaction. The intake either branches cleanly or it produces a record that nobody knows what to do with the next morning.
Every brokerage we have looked at has the same problem. The phone tree did not branch, so the receptionist or after-hours service captured a generic "interested in real estate" lead with a name, a phone number, and a free-text note that says "wants to talk about a house." That note is useless. It does not tell the listing partner whether to grab a CMA tool or the buyer agent whether to pull MLS searches. AI voice intake is not a transcription upgrade. It is a schema decision made before the caller finishes their second sentence.
The branching question is the entire architecture
There is exactly one question that determines which schema gets loaded: "Are you looking to buy a property or sell one?" Some brokerages prefer "Are you calling about a property you own, or are you searching for one?" because it sounds less transactional. The phrasing matters less than the placement. This question goes second, after the agent identifies the brokerage and acknowledges the caller. It does not go fifth after a series of pleasantries. It does not go after asking for a name.
The reason it goes second is that every subsequent field depends on the answer. If you ask price range before knowing whether the caller is buying or selling, you have to ask it twice or interpret it ambiguously. A seller's "price" means asking price expectation. A buyer's "price" means budget ceiling. Same word, different field, different downstream behavior in Follow Up Boss or kvCORE or Lofty.
The voice agent should capture the branch as a single enum field, then immediately load the corresponding schema. If the model does this in two turns instead of one, you are paying for an extra round trip and the caller hears a pause. Vendors that branch in-prompt rather than in-flow handle this in a single inference.
Listing-side schema: ten fields, higher conversion, lower volume
Sellers call less often than buyers. They convert at higher rates because they have already made the decision to transact. The listing-side schema captures roughly ten fields, and the order matters because motivation reveals itself when you ask in the right sequence:
- Property address (full street address, city, ZIP).
- Property type (single-family, condo, townhouse, multi-unit).
- Reason for selling (relocation, downsizing, upsizing, divorce, financial, estate, life event, investment exit).
- Timeline (listing within 30 days, 3-6 months, 6-12 months, exploring).
- Price expectation or comp range.
- Mortgage status (free and clear, mortgaged with equity, underwater, unsure).
- HOA or condo association (yes/no, monthly fee if known).
- Current listing agreement (none, expired, currently listed elsewhere, exclusive).
- Occupancy (owner-occupied, tenanted, vacant).
- Best contact method and window.
The "reason for selling" field is the highest-value capture on the entire call. A divorce seller is a different lead than a relocation seller, who is different from a financial-distress seller, who is different from a downsizer. Same address, same price, completely different conversation when the listing partner calls back. Industry data suggests listing-side calls convert to signed listing agreements at roughly 25 to 35 percent when handled within 24 hours, and the conversion within that band is heavily influenced by whether the agent walks in with the right context.
A schema that captures motivation as free text instead of an enum is doing half the job. The listing partner cannot search "all divorce sellers in the pipeline" if the field is a paragraph. CRM-side, this needs to be a structured tag.
Buyer-side schema: ten fields, lower conversion, higher volume
Buyers call more, convert less, and need triage harder. The buyer-side schema captures different fields and asks them in a different order because financing posture is the gating qualification:
- Area of interest (ZIP, neighborhood, MLS area, school district).
- Property type and bed/bath minimum.
- Price range (ceiling and ideally floor).
- Financing posture (pre-approved with lender, pre-qualified, will need lender, cash, exploring).
- Timeframe (within 30 days, 1-3 months, 3-6 months, 6+ months).
- Currently own (yes contingent on sale, yes not contingent, no).
- Working with another agent (yes exclusive, yes informal, no).
- First-time buyer flag.
- VA/FHA/conventional loan type if known.
- Best contact method and showing availability.
Buyer-side conversion to an active buyer-rep relationship sits roughly in the 8 to 15 percent range industry-wide. The biggest single predictor is the financing field. A pre-approved buyer with a 3-month timeframe is a 30%+ conversion call. An "exploring" buyer with no lender is closer to 5%. The voice agent should capture financing in three turns of the conversation, not bury it as the eighth question.
A common failure pattern: the schema asks "are you pre-approved?" and gets a yes, but does not capture the lender name or the approval amount. That field collapses two pieces of data that the buyer agent needs separately when they call back.
The "I'm not sure yet" caller needs a third branch
Maybe 12 to 18 percent of callers will not answer the buy-or-sell question cleanly. They are calling because a neighbor sold for a number that surprised them and they want to know what their place is worth, but they might also buy something smaller. They are inheriting a property and have not decided whether to keep it. They saw a sign and called.
This is not an edge case to script around. It is a third branch with its own short schema:
- Reason for the call (curiosity about home value, inherited property, considering a move, market question, other).
- Property address if relevant.
- Whether they would consider listing if the number was right.
- Whether they would consider buying if a specific area opened up.
- Best contact method.
The exploratory branch is a five-field schema, not a ten-field one. It does not force the caller into the listing or buyer pipeline. It captures intent loosely, routes to a generalist or the broker on duty, and lets the human follow up with the right framing. Forcing a binary here is how brokerages produce CRM records that never get worked.
Cross-routing: listing leads and buyer leads go to different humans
In most brokerages we have looked at, listing-side leads route to a senior agent, the broker, or a designated listing specialist. Buyer-side leads route to a duty rotation, a buyer-rep team, or whichever agent is up. The CRM team-assignment field is schema-specific, not lead-specific.
This matters because the routing rule sits inside the intake schema, not bolted on after. A Follow Up Boss action plan for sellers should fire on listing-schema completion. A kvCORE smart drip for buyers should fire on buyer-schema completion. If the AI voice agent dumps everything into a single "new lead" record, the routing rule has to do the branching work that the intake should have done. That introduces lag, errors, and the well-known failure mode where a $20,000 listing call sits in a buyer-rep queue for nine hours.
Vendors that let you define schema-specific webhook destinations are doing this correctly. Vendors that send one webhook with a "lead type" field and expect Zapier to route it are forcing you to maintain branching logic in two places.
After-hours is when the asymmetry hurts most
During business hours, a competent receptionist can branch the call manually. After 6pm, the asymmetry between listing-side dollar value and buyer-side volume becomes a missed-revenue equation. A brokerage that takes 40 calls a week after-hours and converts none of the listing leads because the answering service captured "wants to sell, will call back" is leaving meaningful money on the table. We covered the after-hours economics in after-hours real estate brokerage leads.
The schema-specific design is what makes after-hours intake work. A generic "we will have someone call you back tomorrow" message is acceptable for a buyer who is six months out. It is malpractice for a seller whose relocation closes in 45 days and is calling three brokerages tonight.
Five vendor-evaluation questions for branching schema capability
When evaluating AI voice intake vendors for a residential brokerage, the schema branching capability is the single most important technical question. The five questions to ask:
-
Can you define two completely independent field sets that load based on a single enum answer, without us writing custom code? If the answer involves "you can fork in our flow builder," ask whether the fork supports field-level branching or only message branching.
-
How do you handle the third branch (the "not sure" caller) without forcing a binary? Can the schema have a non-committal path that captures partial intent?
-
Can each schema have its own webhook destination, or its own field mapping into Follow Up Boss, kvCORE, Lofty, BoomTown, or Sierra Interactive? A single webhook with a "lead_type" field is the wrong answer.
-
How do you capture motivation or financing as a structured enum rather than free text? Free-text motivation fields cannot be searched, segmented, or used to trigger CRM action plans.
-
Can the agent re-prompt for a missed field without re-asking the entire schema? If a buyer says "I think I'm pre-approved, my wife handled it," the agent needs to capture "pre-approved, lender unknown" and move on, not loop back to the question.
If a vendor cannot answer these five questions concretely, they are selling a generic voice agent that you will have to glue branching logic onto post-hoc. That works until it does not, usually around the moment a high-value listing call hits a malformed schema.
The schema is the strategy
Brokerages that treat intake as a transcription problem end up with CRM records that all look alike. Brokerages that treat it as a schema problem end up with two different lead pipelines that get worked by two different humans with two different scripts. Same caller, same number, different outcome. The branching question is the cheapest piece of technology in the entire stack and the most consequential.
What this looks like in practice: read legal intake schema by practice area for the parallel concept in law firms, see AI voice questions to never ask first for what not to put before the branching question, and real estate lead handoff for what happens to these records after the call ends.
If you want to see schema-specific intake running on a residential brokerage account, book a call, start free trial, or look at the pricing page.