How a Dubai Real Estate Brokerage Unified Bayut, dubizzle and Property Finder on Zoho CRM
Customer Overview
The client is a Dubai-based real estate brokerage operating in both the secondary market and off-plan sales, with approximately 65 RERA-registered agents across residential and investor-focused teams. The firm advertises its inventory on all three major UAE portals — Bayut, dubizzle and Property Finder — which together account for the overwhelming majority of its inbound enquiry volume.
Portal subscriptions were the brokerage’s single largest marketing cost. Despite that, leadership could not reliably answer two basic questions: which portal actually produced closed business, and how long an enquiry sat before an agent touched it.
The Challenge
1. Three portals, three different data models
A common assumption is that Bayut and dubizzle, being part of the same group, share one listing pipeline. They do not. Each portal consumes a separate feed with its own field tags, its own controlled vocabularies, and its own reference number space. Dubizzle expects fields like refno, size and locationtext; Bayut and Property Finder use reference_number, sqft, and community/sub-community structures.
Property types, sub-types and amenities are portal-controlled picklists — anything outside the accepted enum is silently dropped rather than rejected visibly. Locations must be resolved through each portal’s own lookup mechanism; free-text addresses simply fail validation.
The practical consequence was that every new listing was entered three times by hand, taking roughly 40 minutes in total, with transcription drift between portals that nobody noticed until a client did.
2. Leads arriving without attribution — and WhatsApp invisible entirely
Portal enquiries arrived as email notifications that an office coordinator re-keyed into a spreadsheet. That approach loses the portal’s own lead identifier, which is precisely the data needed for attribution. Worse, it captured only form fills — while a substantial share of real buyer intent in Dubai arrives as a WhatsApp message or a phone call straight from a listing page.
Duplicates compounded the problem. Portals broadcast the same buyer enquiry to multiple agencies, and a single buyer enquiring on three of the brokerage’s own listings generated three separate records. Source performance reports were inflated in ways nobody could quantify, and two agents periodically called the same buyer within an hour of each other.
3. Trakheesi permit lifecycle managed in a spreadsheet
Every property advertisement in Dubai requires a valid Trakheesi advertising permit from the Dubai Land Department, and the permit number must appear on the listing — it is a mandatory field in the portal feed, not an optional reference.
This stopped being a paperwork matter some time ago. The DLD now operates an AI-enabled real estate advertising governance platform that monitors listings across Property Finder, dubizzle and Bayut and reconciles advertised data against DLD records. In figures published by the DLD, the platform had monitored over 279,000 advertisements, with 29% automatically modified. Separately, the Madmoun service issues a QR code for every advertising permit that must be displayed on all advertisements.
The brokerage tracked permit expiry dates in a shared spreadsheet. Listings were being pulled down without warning, and the compliance exposure was real.
4. Agent turnover was breaking the system structurally
This was the problem leadership had not connected to its CRM at all. Dubai brokerages are hiring aggressively while retention deteriorates — press reporting indicates average agent tenure has fallen to around six months or less, with new and rental-focused agents churning fastest.
In a portal-integrated setup, agent identity is embedded in the listing feed itself. When an agent left, their listings’ feed records broke, their open enquiries were orphaned, and the conversation history that justified a buyer’s position in the pipeline left with them. Reassignment was treated as an exception to be handled manually. At six-month average tenure, it is not an exception — it is a routine operating event.
The Solution
Techvaria implemented Zoho CRM as the brokerage’s own system of record, with custom portal integration built on top. The guiding principle was that the CRM holds one canonical listing, and each portal receives its own correctly-shaped projection of it — rather than attempting to push one shared payload at three different specifications.
1. One listing record, three portal projections
A custom Properties module was built to hold the canonical listing, with separate projection logic per portal handling field mapping, enum translation, location resolution and independent reference numbers. Bayut and dubizzle are served by compliant XML feeds; Property Finder is integrated through its Enterprise API rather than legacy XML, since Property Finder is moving agencies off XML toward its newer API.
Agents now publish once. Validation failures surface inside the CRM against the specific portal and field that rejected them, instead of being discovered when a listing quietly fails to appear.
2. Full lead ingestion, including calls and WhatsApp
Bayut’s Leads API was integrated to pull not just email enquiries but call logs, phone views, SMS clicks and WhatsApp leads — engagement events, not only form submissions. Property Finder leads are received by webhook. WhatsApp Business API was connected so that agent conversations are captured against the contact record rather than living on personal handsets.
A deduplication layer keys on phone and email together with portal lead ID, property reference and a time window. It merges to a single primary contact while preserving every originating portal source, so attribution survives the merge — and assigns one unambiguous owning agent.
3. Trakheesi permits as first-class CRM state
Permits were modelled as a tracked object with status, issue and expiry dates, linked listings and the Madmoun QR reference — not as a text field. Automated escalation begins well before expiry, and a listing cannot be submitted to a portal without a valid linked permit. TruCheck and verification status are tracked per listing per portal so the team can see which listings carry trust badges and which do not.
4. An agent lifecycle designed for six-month tenure
Rather than treating departures as exceptions, offboarding became a defined blueprint: bulk reassignment of listings and open enquiries, automatic regeneration of affected portal feed records, and retention of full historical attribution against the original agent for commission and reporting purposes. BRN expiry is tracked per agent with renewal reminders, since an expired registration invalidates listings.
5. Dubai transaction workflow and commission logic
The deal pipeline was built around the actual Dubai process rather than a generic sales funnel: Form A authorisation gating listing creation and portal verification, Form B for buyer representation, and Form F as the trigger for NOC, trustee appointment and transfer. Off-plan was deliberately modelled as a separate path — developer inventory, unit availability and reservation state, payment plans, and SPA through Oqood registration to title deed — rather than forced into the same object as secondary-market resale.
Commission was implemented as two distinct layers: co-brokering splits between agencies as recorded on Form F, and internal agency-to-agent splits with tiered rates against annual production.
The Impact
Measured across the two quarters following go-live:
Single entry with automatic fan-out to all three portals, with validation errors surfaced per portal and field.
Driven primarily by capturing call and WhatsApp events rather than email notifications alone.
With original portal sources preserved, so attribution reporting became trustworthy for the first time.
Permit expiry now escalates in advance rather than surfacing as a removed listing.
Reassignment as a routine blueprint, with feed records regenerated automatically.
With clean attribution, the brokerage reallocated subscription budget between portals based on closed revenue per source rather than raw lead counts.
What We Would Tell You Honestly
A few limitations worth knowing before you scope a project like this, because they are not advertised:
- Zoho has no native UAE portal connector. There is no off-the-shelf Bayut, dubizzle or Property Finder integration. Every element of the syndication described above is a custom build, and it is the single largest line item in the project. Any partner implying this is configuration is misleading you.
- Zoho’s API and automation limits are the real constraint on lead polling — not the portal’s. Bayut imposes no cap on how frequently a CRM pulls its Leads API; Zoho’s per-edition limits do. Polling strategy has to be designed around that.
- Property Finder is moving off XML. Building new integrations on legacy XML feeds is a dead end. We could not verify a published cut-off date, but the direction of travel is clear and worth designing for.
- You cannot run Property Finder’s own PF Expert and a third-party CRM for listing management at the same time. It is an explicit either/or. With a CRM feed you keep view access and verification submission in PF Expert, but listing control moves to the CRM. That is a migration decision, not a parallel-run option.
- TruCheck cannot be automated away. It requires an agent to physically attend the property and capture geotagged, timestamped photographs through Bayut’s own Profolio app, within a short radius of the property. A CRM can track and chase that workflow. It cannot replace it.
- Native Zoho reporting ran out of room. Cross-module analysis across listings, leads, deals and commissions required Zoho Analytics. Treat it as a necessary component rather than an optional upgrade.
Conclusion
Dubai brokerages tend to buy CRM to solve a lead problem. The lead problem is usually real, but it is rarely the expensive one.
The expensive problems are structural: three portals that look similar and behave differently, a regulator now machine-reconciling every advertisement against its own records, and an agent population that turns over roughly twice a year and takes institutional memory with it each time. A portal’s own CRM cannot address the first, and a generic sales pipeline cannot address the third.
What made this implementation work was not clever automation. It was accepting the actual shape of Dubai brokerage operations — permit lifecycles, Form A to Form F, co-broker splits, constant reassignment — and building for that, rather than configuring a generic CRM and hoping the business would adapt to it.
This case study is representative of a Dubai real estate brokerage engagement. Client details are anonymised and performance figures are illustrative of outcomes achievable in comparable deployments. Regulatory and portal integration details — including Trakheesi permit requirements, DLD advertising governance figures, Bayut Leads API capability, TruCheck verification requirements and Property Finder integration constraints — are drawn from Dubai Land Department and portal documentation current as of late 2026. Agent tenure context is drawn from UAE press reporting. Verify current portal specifications and DLD requirements before relying on them for your own implementation.
