Knowledge Base
UAE portal lead management in one CRM: deduplication, routing and response-time SLAs
Three portal integrations do not add up to a lead management system. The hard problems only appear once the enquiries are in the same place.
UAE portal lead management comes down to three decisions: how you recognise the same person arriving twice, who owns them when you do, and what happens when nobody responds. Each one is a policy question that a brokerage has to answer before it becomes a configuration question.
Individual portal integrations are covered elsewhere in this series. This piece is about the layer above them.
The same buyer, three times over
A buyer shortlists four apartments in Jumeirah Village Circle across a weekend. Two of your listings are among them. They enquire about one through Property Finder on Friday evening and the other through Bayut on Saturday morning, using a different email address the second time because they were logged into a different account.
Without cross-portal matching you now have two leads, two agents, and a buyer who is about to receive two calls from the same brokerage saying slightly different things. The buyer’s conclusion is that you are disorganised. Your conclusion, weeks later, is that two agents both think they introduced the client.
What to match on, in what order
Matching logic that works across UAE portals, in priority order:
- Normalised mobile number. The strongest signal, provided every number is stored in one format at the point of entry.
- Email address. Reliable when present, absent entirely on call enquiries.
- Name plus one corroborating field. Never name alone.
Two refinements that prevent the common failures. First, match but do not auto-merge when names differ substantially on a shared number — family members share phones, and a silent merge loses a real buyer. Second, treat a match as “same person”, not “same enquiry”: the second enquiry is still a separate event about a different property, and both need to exist.
Ownership: the policy question nobody writes down
Once you can recognise a returning buyer, you have to decide what that means commercially. Three workable positions:
| Rule | Effect | Risk |
|---|---|---|
| First agent keeps the client | Simple, avoids duplicate contact | An unresponsive first agent blocks a live buyer |
| Ownership expires after inactivity | Keeps buyers moving | Requires an agreed inactivity window, and disputes cluster around it |
| Listing agent handles their own listing | Matches how buyers expect to be answered | One buyer, several agents, needs a coordination rule |
Most brokerages end up with the second, plus an override for the third. Whichever you choose, the rule belongs in writing before it is automated. A CRM that enforces an unagreed rule generates more conflict than one that enforces nothing, because now the system is blamed.
Attribution is a separate question from ownership
Ownership decides who works the client. Attribution decides which portal gets credit — and they are not the same decision.
If a buyer first enquires through Dubizzle and later converts after a Property Finder enquiry, first-touch attribution credits Dubizzle and last-touch credits Property Finder. Both are defensible. What is not defensible is applying one silently and making renewal decisions on it.
Record every Portal Enquiry against the person, keep the full sequence, and decide the attribution model explicitly. Then you can report both and see whether they disagree. Method in measuring portal ROI in Salesforce.
One SLA, not three
Portals differ in volume and lead character, which tempts brokerages to set different response targets per portal. That produces a sales floor where some enquiries are quietly deprioritised by policy.
A single response SLA across all portals is easier to manage and easier to defend. Differentiate by band, not by source: if triage says this enquiry is low-intent, it gets a different treatment because of the triage result, not because of where it came from. The Dubizzle piece covers how triage works at volume.
Building the SLA so it survives contact with reality
- Start the clock at enquiry creation, not at agent login or first open
- Define working hours per team, and route out-of-hours enquiries to duty rather than pausing the clock silently
- Escalate twice: reminder, then reassignment
- Measure the 90th percentile, since the average hides exactly the cases that lose deals
- Exclude nothing from the report. Every exclusion becomes a place to hide
What UAE portal lead management is actually for
“One CRM for all portals” is usually sold as convenience. The real value is the three questions it lets a sales director answer at any moment:
- How many enquiries arrived today, and how many are still unanswered?
- Which agents are outside SLA, and by how much?
- Which portals produce enquiries that become viewings?
None of those require an elaborate dashboard. They require that every enquiry, from every portal and every channel, exists as a record with a timestamp and an owner. That is the whole architecture.
Where multi-portal setups usually break
One channel stays outside
WhatsApp is the usual culprit. If a meaningful share of enquiries arrive on agents’ phones, the unified view is a partial view, and every metric derived from it is understated in a way nobody can quantify. See WhatsApp lead handling for Dubai brokerages.
Matching is built once and never reviewed
Duplicate rates change as portals change their forms and as your lead mix shifts. Review the duplicate rate quarterly. A sudden rise usually means a field stopped arriving, not that buyers changed behaviour.
The rules encode last year’s team structure
Routing written for four community teams keeps running after a reorganisation into two. Enquiries still route somewhere, so nothing looks broken — they just route to the wrong people. Tie routing to a maintained team structure rather than hard-coded names.
Frequently asked questions
How do you deduplicate leads across different property portals?
By matching on a normalised mobile number first, then email, then name plus a corroborating field. Numbers must be standardised to one format at the point of entry, otherwise the same person appears as several.
Who should own a buyer who enquires through two portals?
That is a commercial policy, not a technical default. Common approaches are first-agent ownership, ownership that expires after a defined period of inactivity, or listing-agent handling with a coordination rule. Agree it before automating it.
Should response-time targets differ by portal?
Better to run one SLA across all portals and differentiate by triage band instead. Portal-specific targets quietly deprioritise whole sources, which is rarely the intention.
What is the difference between lead ownership and attribution?
Ownership decides which agent works the client. Attribution decides which portal receives credit for the enquiry. They answer different questions and should be configured separately.
How do you measure response time meaningfully?
Start the timer at enquiry creation and report the 90th percentile rather than the average. Averages stay comfortable while the slowest responses, which are where deals are lost, get worse.
What happens to enquiries for areas the team does not cover?
Decide explicitly: route to a named person, refer out, or close with a polite response. An unrouted enquiry sits in a queue nobody owns and ages until it is worthless.
Talk it through
If duplicate leads or ownership disputes are costing you deals, tell us how your portals and teams are set up. Get in touch — the first assessment is free.
Let us look at your lead flow end to end
Tell us which portals you run and how leads reach agents today. We will come back with scope, timeline and an indicative cost — free, and with no obligation.