nesaku
Talk to us Initial conversation
Writing

Real estate systems 29 August 2026 8 min read

How to Bring Property Finder, Bayut, Website and WhatsApp Leads Into One Record

Create one reliable record for Property Finder, Bayut, website and WhatsApp leads while preserving source, listing context and enquiry history.

By Alejandro at Nesaku

Bring Dubai property leads into one record by keeping one contact for the person or buying group, then attaching every enquiry, property interest, conversation, assignment, and outcome as a separate timestamped event. Do not overwrite the original portal source when the conversation moves to WhatsApp, and do not merge uncertain identities just to make the CRM look tidy.

This article separates three kinds of statements. Platform behaviour described by Bayut, Property Finder, or Dubai Land Department is an observed fact. The record model and operating controls are Nesaku recommendations. The buyer example is illustrative, not a client story or evidence of a measured result.

Key Takeaways

  • One inbox collects messages. One operating record preserves identity, source, property context, ownership, and history.
  • Keep contacts, enquiries, property interests, conversations, and opportunities separate.
  • Preserve the original source and raw event before matching, routing, or scoring it.
  • Use deterministic identity evidence first and send uncertain matches to review.
  • Reconcile source totals against captured events so a quiet integration does not hide missing leads.

Why is one inbox not one lead record?

An inbox answers where a message can be read. A lead record should answer what arrived, who it concerns, which property prompted it, what happened next, and who owns the next action.

Those questions need different records because the same person can generate several enquiries. A buyer may ask about two apartments on Bayut, submit a website form for a broader area search, and then continue on WhatsApp. Combining those events into one large note loses the order and source of the evidence. Creating four unrelated contacts loses the relationship between them.

Bayut’s own tools show this distinction. Profolio reports Bayut and dubizzle enquiries across Email, SMS, Phone, WhatsApp, and Chat, with an Excel export and listing context (Bayut, Best Features of Profolio, accessed 2026-08-29). Bayut also documents that several Chat enquiries from one registered user to the same agent can appear as one lead while retaining the properties discussed (Bayut, Introducing Bayut Chat, accessed 2026-08-29).

That grouping is an observed Bayut Chat behaviour. It does not prove that phone, email, Property Finder, a website form, and WhatsApp are deduplicated across the agency. The recommended design is therefore to preserve each inbound event and connect it to a contact only when the match is dependable.

Which records should stay separate?

A workable model has five parts:

RecordWhat it meansWhat should not overwrite it
ContactOne person or buying groupA new portal enquiry
EnquiryOne inbound expression of interestA later WhatsApp reply
Property interestOne listing or requirement being consideredA second property request
ConversationMessages or calls on one channelThe acquisition source
OpportunityOne active path toward a viewing or other outcomeThe person’s unrelated enquiry

This model is a recommendation, not a portal requirement. Its value is practical. A contact can have several enquiries. An enquiry can mention one or more properties. A conversation can move between channels. An opportunity can continue after the original listing becomes unsuitable.

The wider Dubai real estate lead-management guide places this record model inside the full enquiry-to-viewing workflow. The next chapter on qualifying Dubai property leads defines what the team should learn before deciding whether to propose a viewing.

What should be captured before any merge or route?

Capture the source event without improving it first. A minimum inbound event should include:

  • source and channel;
  • source event or lead identifier when supplied;
  • received timestamp;
  • name, phone number, and email exactly as received;
  • raw enquiry text or call reference;
  • listing reference, property URL, and portal agent when supplied;
  • ingestion method, such as API, webhook, export, or forwarded email;
  • processing status and any capture error.

Property Finder documents an Enterprise API 2.0 route through which agencies can receive and process its leads directly in an external CRM (Property Finder Help Center, Integrate your CRM with PF Expert 2.0 using the Enterprise API, updated 2026-02-19). Its public article does not publish the complete lead payload. An implementation must inspect the authenticated documentation and actual events rather than inventing a common portal schema.

Bayut’s cited documentation supports reports and Excel export. It does not establish a public Bayut lead API. A website form and WhatsApp setup are agency-controlled sources with their own payloads. Each connector should map what it actually receives into the event contract and mark missing values as missing.

How should identity matching work?

Normalise phone and email values for comparison, but keep the raw values for evidence. Match a trusted source identifier first where one exists, then an exact normalised phone number or email address. Use several signals when the match remains uncertain.

A phone match is not infallible. Numbers can be shared, entered incorrectly, or reassigned. A household may use one number while two people make decisions. An investor may use different numbers in different countries. The recommended control is an exception queue for ambiguous matches, with the proposed contact, evidence, reviewer, decision, and time recorded.

Do not let an automatic merge destroy history. A reversible link is safer than deleting one record into another. When staff confirm that two records concern the same person, retain both source events beneath the chosen contact.

Which source should attribution use?

Keep the acquisition source immutable. If the first enquiry arrived from Bayut and the buyer later replied on WhatsApp, the original source remains Bayut. WhatsApp becomes the current conversation channel. Those fields answer different business questions.

Also keep source detail below the top-level label. Bayut > Chat, Property Finder > form, website > valuation form, and WhatsApp > direct inbound are more useful than four records labelled only online. Store the campaign or page value when the source provides it, but never manufacture one when it does not.

This distinction makes the metrics in how to measure real estate lead handling possible. Source, response, contact, qualification, and viewing need their own timestamps and denominators. Changing the source when a conversation changes channel would make attribution impossible to audit.

When should routing happen?

Create the enquiry event before routing it. Otherwise a failed assignment can also become a failed capture.

The recommended order is:

  1. accept and store the raw event;
  2. validate required technical fields;
  3. connect it to a contact or open a match exception;
  4. attach property and listing context;
  5. apply the current routing rule;
  6. record the owner, rule version, and assignment time;
  7. create a visible next action or fallback.

Routing should not change the original portal agent field. The portal agent, CRM owner, and current action owner may differ for legitimate reasons. Keep each explicit. The chapter on real-estate lead-routing rules explains how listing ownership, area, language, capacity, and fallback precedence can be applied after capture.

How do you know the integration is still working?

A successful connector response proves only that one request completed. It does not prove that every source event reached the CRM.

Run a reconciliation process by source and time period. Compare the portal or channel count with accepted events, rejected events, duplicates, and unresolved exceptions. Every difference needs a reason. Monitor the age of the oldest unprocessed event and the oldest match exception. Give both queues a named owner.

Preserve replay information so a failed event can be processed again without producing another enquiry. Test with controlled enquiries after connector, portal, form, or field changes. Email parsing can be a fallback when no structured route exists, but it needs format-change detection because a valid email can still produce an empty or misread record.

What listing and permit context should remain attached?

Dubai Land Department’s advertising terms require a RERA permit and permit number for property advertising, require the real-estate company name, and make the advertising company responsible for the validity of approved ad content (DLD, Real Estate Ads Terms and Conditions, Circular 2-2022, dated 2022-08-02).

That circular does not prescribe a CRM schema. As an operating recommendation, retain the listing reference, advertised URL or snapshot reference, company, permit number or Madmoun QR data when available, and the property facts supplied with the enquiry. This helps an agent answer about the same advertised property and helps the business trace what the buyer saw.

Illustrative record: one buyer, several events

Consider a fictional buyer named Samira. She asks about Bayut listing B-104 and later B-208. A week later she submits the agency’s website form asking for any two-bedroom apartment in the same area. She then replies to the agent on WhatsApp.

The recommended result is one contact, three enquiry events, two listing-specific property interests, one broader requirement, and one WhatsApp conversation. The first Bayut enquiry remains the acquisition source. The website form and WhatsApp reply remain visible as later events. If B-104 is unavailable, the opportunity can continue without rewriting what originally happened.

This is illustrative data, not an account of a Nesaku client. The representative real-estate routing and viewing case study shows the same kind of connected workflow without claiming named-client results.

Put one reliable record before more automation

Before adding scoring, automated replies, or viewing booking, verify that every source creates a recoverable event, uncertain matches reach a review queue, original attribution survives, and one owner has a dated next action.

If your agency cannot reconstruct one enquiry across portal, CRM, and WhatsApp, show Nesaku where the record splits. We can map the current sources and define the event, identity, and exception rules before another tool makes the history harder to trust. Our Dubai real-estate automation service explains where that implementation work fits.

Sources