Automating lead qualification for a Dubai brokerage means exactly two things: extracting the answers a buyer gives (budget, timeline, purpose, area) into typed fields, and scoring those fields with rules a sales manager can read. The LLM does the extraction; plain code does the scoring. Teams that get this boundary right ship a system that survives audits and broker turnover. Teams that let the model "decide" get a black box that nobody trusts with a hot lead
This is the architecture we build for brokerages whose leads arrive through Property Finder, Bayut and Dubizzle faster than agents can read them
What does the qualification field map look like?
The system starts with a typed schema, agreed with the sales manager before any model gets involved. The standard Dubai-residential map:
| Field | Type | Why it matters |
|---|---|---|
| budget_aed | number range | Sorts the portal browser from the buyer |
| timeline | enum: now / 1-3mo / 3-6mo / exploring | The single strongest hot-lead signal |
| purpose | enum: end-user / investor / rental | Decides which agent and which listings |
| area | normalized community name | "Marina" must resolve to Dubai Marina, not a string |
| financing | cash / mortgage / unknown | Changes the realistic close timeline |
| name_contact | string + verified number | Junk leads die here, quietly |
The model's job is to fill these fields from a WhatsApp thread, a portal enquiry email, or a voice note. The model's job is explicitly not to emit a score
The structured record is what the rules score against
Why should rules score the lead instead of the model?
Because a scoring rule is auditable and a model's judgment is not. "Budget within 10% of listing price AND timeline under 90 days AND financing known = hot" is a rule a sales manager can read, argue with, and change on a Tuesday. A probability the model cannot explain is none of those things
In practice the split looks like this: the LLM normalizes "around 2 mil, maybe a bit more" into budget_aed: [2000000, 2500000]; the rule layer turns that plus timeline: 1-3mo into a hot flag and routes it to the right agent with a WhatsApp handoff. A lead the rules cannot score confidently does not get dropped: it goes to a review queue with the extracted fields and the reason attached
How does Arabic and mixed-language qualification work?
Buyers write in MSA, Khaleeji, English, and Arabic-English code-switching inside one message. The extraction schema does not care which language the answer arrived in, but the evaluation has to be honest about it: we test extraction against real production transcripts, including voice notes, before the system touches live leads. Confidence thresholds differ per language because accuracy differs per language
The deeper coverage of the WhatsApp intake flow (24-hour window, templates, the first-reply pattern that names the listing) sits in the portal leads article. The short version: qualification questions have to arrive inside the customer's active window and in the language they used
How do the portal sources feed the same flow?
Property Finder, Bayut and Dubizzle all deliver the same shape: a name, a number, a listing reference and a free-text question. The intake layer normalizes them into one schema so the rest of the system does not care which portal the lead came from. The differences sit in the details — Property Finder sends richer listing context, Bayut leads arrive via email or webhook depending on the plan — but the qualification logic after normalization is identical, which is why the per-portal custom work is in the intake adapter, not in the scoring rules
What gets written back to the CRM?
Qualification only earns its keep when it lands where the team already works. The write-back is boring on purpose: a contact, a deal with the score and extracted fields, a task for the assigned agent, and the source attribution (which portal, which listing). Any CRM with an API takes this shape; HubSpot, Salesforce, Zoho and Odoo all do, and we do not ask you to change CRM to get the automation
Stale inventory is the qualification system's silent killer: a bot that qualifies a buyer for a unit that sold last week burns trust faster than a slow human. On our inventory CRM build tracking roughly 8,000 units, status accuracy went from about 60% to about 98%, and the time to find a free unit dropped from ~2 hours a day to about 10 seconds. Qualification that checks live inventory before quoting is a different product than qualification that does not
On the 8,000-unit inventory build, status accuracy went from about 60% to about 98% once qualification checked live stock before quoting. A bot that quotes a unit that sold last week burns trust faster than a slow human.
What does a real qualification conversation look like?
Two to three questions, phrased to invite answers, not to interrogate. The buyer who messaged about a Marina 1-bedroom gets asked whether it is for living or investment and what the timeline looks like; the answer updates the score immediately. A buyer who does not respond to the second message does not get chased by the bot — the CRM task on the agent does the chasing instead. The questions themselves were agreed with the sales manager before launch; they are the same questions a good broker asks in the first call, which is why the flow feels like a broker and not a form
What are the failure modes worth knowing?
Two dominate. First, schema drift: the field map was written for a residential sales business and then the brokerage starts handling off-plan launches where "purpose" answers a different question. The schema has to evolve with the business or the score starts lying quietly. Second, language coverage: the system handles MSA fine and then a Khaleeji voice note arrives and the extraction confidence drops through the floor. We test Arabic extraction on real transcripts before the system touches a live lead — the broader WhatsApp language rules sit in the portal leads article
Where does the human enter?
A qualified hot lead routes to a human by design, not by failure. The agent gets the thread, the extracted fields, the score and the reason the rule fired. Everything the escalation rules look like in production (confidence, sentiment, value thresholds) is in the handoff article. The bot's job ends where a relationship has to start; automating the scoring is safe precisely because nobody automated the selling
The takeaway
Extract fields with the model, score with rules, route hot leads to humans, write back to the CRM you already have, and never let the system quote stale inventory. That is the whole pattern. The data-protection side of storing these lead records is covered in PDPL-compliant AI CRM
FAQ
How can I automate real estate lead qualification in Dubai?
Capture the portal enquiry, extract budget, timeline, purpose and area into typed fields, then score with auditable rules — not model opinion. Hot leads route to an agent; the rest get a nurture sequence
Can the bot qualify Property Finder and Bayut leads?
Yes. Both portals send structured lead events; a WhatsApp or email-first flow asks the qualification questions, writes the answers into the CRM and flags the lead score the manager defined
Can the AI qualify buyers and tenants in Arabic on WhatsApp?
With the right routing, yes. Khaleeji and MSA inputs need evaluation on real voice notes and mixed-script text; we test Arabic handling on production transcripts before trusting it with leads
Does it work with HubSpot, Salesforce, Zoho or Odoo?
Qualification writes back as standard CRM objects — contacts, deals, tasks — so any CRM with an API works. The scoring rules live in our system, not inside the CRM's automation builder
Should the model score the lead itself?
No. The model extracts fields; rules score them. A sales manager can audit 'budget within 10% of listing price AND timeline under 90 days' — nobody can audit why a model felt a lead was hot