Blog — 2026-08-07
By Emad Yahya — web developer & IT systems engineer, Dubai
A real estate CRM that genuinely integrates with Bayut and Property Finder should do four things: capture every portal enquiry without anyone re-typing it, stamp it with its true source and arrival time, recognise that the same person has already enquired before creating a second record, and put it in the right agent's hands with a clock already running. Do those four and the reporting takes care of itself. Skip them and what you have is a database, not an integration.
I'm Emad Yahya, a web developer and IT systems engineer in Dubai. I built a brokerage CRM from scratch that runs a Dubai firm today, and I spend my working days inside real estate operations. This guide covers how portal leads actually arrive, what breaks when a human is the integration, and what a real integration has to do before you sign anything. One caveat first: portals change how they deliver leads, and what is available typically depends on your account and plan. Treat the shape of the problem here as stable, and confirm the current specifics with your portal account manager before the build starts, not after.
Portal enquiries typically arrive through more than one channel at the same time, and that is the detail most integration conversations skip. Before anyone quotes you for connecting a portal, map how leads reach your desk today. In most Dubai brokerages the answer is some combination of the following.
The practical consequence is that no single integration captures everything. A webhook or a parsed email will handle form enquiries beautifully and still miss the buyer who tapped the call button on your listing. Any developer who promises "all your portal leads in one place" without asking about phone and WhatsApp traffic has not thought about the problem yet.
Because the real cost is never the typing. It is the delay, the duplicates, and the history you never captured.
Portal enquirers typically message several listings at once, and the first agent with a substantive reply tends to own the conversation. When a human is the integration, the lead waits for that human — through a viewing, through lunch, through a Friday. The gap between arrival and first contact is where deals quietly leave, and nobody records the moment they go.
Then there is the duplicate problem. One serious buyer enquiring on four listings can become four separate records assigned to four different agents, all of whom call the same person within the hour. That is not a data-hygiene inconvenience. It is a poor first impression of your brokerage, delivered four times.
Re-entry also destroys attribution. Someone retyping a name and number rarely records which portal it came from, which listing reference triggered it, or the exact minute it arrived. Without those three fields you cannot answer the only marketing question that matters: which channel produces closed deals, not just enquiries. And manual re-entry fails silently — nobody can ever tell you what was never typed in.
It ingests, normalises, deduplicates, routes and timestamps — in that order, and it keeps a record of everything it received.
The last point is the one that matters most when something is disputed. An integration you cannot audit is an integration you simply have to trust, and portal lead disputes are precisely the situation where trust is not enough. In the CRM I built for a Dubai brokerage, every enquiry carries its source and arrival time from the moment it lands, which is what makes response-time reporting meaningful rather than decorative.
Match on phone number first, email second — and never discard the second enquiry.
The correct outcome when one buyer enquires on three listings is a single contact record with three enquiries attached, each keeping its own listing reference, portal and timestamp. Collapsing them into one enquiry throws away the fact that this person is interested in three properties, which is probably the most useful thing you learned all week.
Ownership then needs an explicit rule, because software cannot guess it. Does the agent who received the first enquiry keep the contact, or does each listing's agent get their own? Both answers are defensible, and both cause arguments when left unwritten. Decide it as a business rule, put it in the specification, and make sure the record shows every agent who touched the lead either way.
One more nuance worth building in: a reopen window. An enquiry from the same number six hours ago is a duplicate. The same number six months later is a new opportunity, and treating it as an old one buries it under stale history.
Record two timestamps — when the enquiry happened at the portal, and when it arrived in your system — and measure from the first one.
The gap between them is your integration latency, and it is real. A mailbox polled every fifteen minutes typically adds up to fifteen minutes of invisible delay before an agent has even seen the lead. If you measure only from the moment the record appeared in the CRM, you will credit your team with time it never had, and your reporting will look considerably better than your customer's experience.
Define first response honestly too. Opening the record is not a response. A call attempt, a WhatsApp message or an email to the enquirer is. Then report it in a way management can act on: by agent, by portal, by listing and by hour of day. The out-of-hours pattern usually explains more than the averages do.
Expect your numbers to disagree with any metrics the portal itself reports. That is normal — the two systems are typically measuring different events. What matters is that you know exactly which event yours is measuring.
These are the questions that separate a real integration from a demo. Ask them before the contract, and ask for the answers in writing.
A developer who answers all eight comfortably has built this before. A developer who treats the failure questions as pessimism has not.
If your brokerage is small and a mainstream real estate CRM already lists your portals as supported connectors, start there. You will be running this month, and I would rather tell you that than sell you a build you do not need yet.
A custom build earns its place when routing has to match your actual desk structure, when your agents live in WhatsApp and will never adopt a dashboard, when portal leads need to sit in the same pipeline as website enquiries, campaigns and walk-ins, or when per-seat licensing starts scaling faster than your headcount. Ownership matters here too — the code, database and accounts sit in your name.
On timelines, from my own delivery: a lead-capture-and-pipeline core takes 3–5 weeks, and a fuller system with commissions, approvals and reporting takes 6–10 weeks. If you want a straight answer for your setup, send me your portal arrangement and how your desks are organised. You get a fixed written quote within 24 hours — including "keep the connector you already have", if that is the honest recommendation.
In most cases, yes. Where the portal supports structured delivery for your account, enquiries can flow straight into the CRM by webhook or API; where it does not, a monitored mailbox that parses the notification email is the usual fallback. Either route should tag the source, keep the listing reference and stamp the arrival time. What neither route captures on its own is a buyer who tapped call or WhatsApp on the listing — that needs handling separately.
A properly built integration matches on phone number first and email second, then attaches each enquiry to the one existing contact rather than creating rival records. You end up with three enquiries, each keeping its own listing reference and timestamp, under a single person — and an explicit ownership rule decides which agent holds the contact.
Not automatically by a lead integration. Calls and WhatsApp taps from a listing typically go straight to an agent's phone and never pass through any inbox. If those matter to you, they need a deliberate answer in the design — call-tracking numbers, or a quick logging step in the CRM. Ask about this specifically — it is an easy gap to leave unplanned.
A lead-capture-and-pipeline core takes 3–5 weeks; a fuller system with commissions, approvals and reporting takes 6–10 weeks. Those are my own delivery times from a CRM now running a Dubai brokerage.
It happens, which is exactly why the integration should be built to fail loudly rather than quietly. Alerts on ingestion failures, stored raw payloads and a re-import path mean a changed template or endpoint costs you an afternoon of adjustment instead of a week of leads nobody noticed were missing.
It depends entirely on scope — how many portals, which delivery methods they support for your account, and whether the integration sits on a CRM you already have or one being built alongside it. Send me your setup and you get a fixed written quote within 24 hours.
CRM Development in Dubai — full service page · What a custom CRM for Dubai real estate should actually do · Real Estate Website Developer in Dubai — the lead-generating front end · Custom Software Development in Dubai