Case study

Rebuilding intake for a property brokerage

Zane ScalesFebruary 14, 20262 min read

The situation

A Dubai property brokerage with a dozen agents was taking enquiries from four portals, a website form, and WhatsApp. Each channel landed somewhere different, and agents worked from whichever inbox they trusted. Nobody could say how many enquiries came in last week, or which ones were never answered.

What the diagnosis found

The visible complaint was slow replies. The diagnosis found the real leak was that enquiries never became records. The same buyer existed three times under three spellings, portal leads were re-typed by hand, and the CRM they paid for was a graveyard because keeping it current was a second job nobody owned.

What we built

One intake layer that captures every channel into a single record on arrival, de-duplicates on entry, and structures the messy portal text with a small AI step that a person can override. It writes to the CRM they already owned, so no migration and no new tool to learn, only a pipeline that fills itself.

The outcome

[DECIDE]

enquiries reaching a real conversation

[DECIDE]

weekly hours of manual re-entry removed

[DECIDE]

duplicate records after cleanup

[DECIDE]

median time to first reply

Why intake, not speed

It would have been easy to sell this brokerage a faster auto responder. It is the obvious fix, and it would have made the real problem worse, because a faster reply to an enquiry that never becomes a record just loses the same lead more quickly.

The diagnosis traced one enquiry from each channel end to end and timed every handover. The delay was real, but it was a symptom. The cause was that four channels wrote to four places, so there was no single record to reply from, report on, or trust. Fixing the reply time without fixing the record would have papered over the leak.

What we built, and what we deliberately did not

We built a single intake layer in front of the tools they already used. Every channel, the four portals, the web form, and WhatsApp, lands in one place, becomes one record, and is checked against existing contacts before it is created, so the same buyer stops appearing three times.

The one place AI earned its keep was reading the unstructured portal text into clean fields: budget, location, bedrooms, timeline. It drafts, a person confirms, and the confirmation teaches the next draft. Everywhere a decision needed a human, an agent stayed in the loop by design. This is the line we hold on every AI system we build.

What we did not do matters as much. We did not migrate them to a new CRM, because the one they had was fine once it was being fed correctly. We did not build a chat bot to talk to buyers, because the agents were good at that part. The build was small on purpose, aimed only at the step the diagnosis had priced as the most expensive.

The shape of the result

The outcome numbers above are held until the brokerage clears them for publication, so they read as placeholders here rather than invented figures. The shape is consistent with the pattern: when intake becomes one clean record instead of four scattered ones, the enquiries that used to evaporate turn into conversations, and the hours agents spent re-typing turn back into selling.

If you recognise your own business in the situation, the same arc starts the same way, with a diagnosis that prices the leak before anyone writes code. The reasoning behind starting there is worked through in our guide to build versus buy.

Find out what to build.

A 20 minute call, or a message on WhatsApp. Either way you leave knowing the first thing to build.

Booking soonWhatsApp soon