An automated deal monitor for a Dubai luxury real-estate brokerage

The situation

A Dubai luxury-property broker working the higher end of the market had a simple, expensive problem: below-market listings were appearing in broker Telegram groups faster than one agent could read them. Reading six groups by hand, all day, while also doing the actual job of a broker, is not a job one person can do and win consistently. Qualifying deals were being missed, and the pipeline had no discipline.

What we built

We built a Python pipeline that polls six Telegram listing groups every 30 seconds, splits posts that bundle multiple listings into one message, and extracts price, size, bedroom count, building, and area from free-text ad copy. Every extracted listing gets benchmarked against a licensed dataset of 288,533 historical transactions across 101 communities and 3,594 buildings, using trailing 12-month averages per square foot. A listing priced more than 10% under that benchmark, with a minimum yield threshold and a minimum size filter applied, gets scored and pushed to a dedicated Telegram alert channel and logged to a Google Sheet the broker actually uses day to day.

On top of the monitor sits an agent layer, an open-source agent framework, routing between Discord, Telegram, and WhatsApp, with scheduled jobs, health checks, and an automatic restart if the process dies. The same workspace holds a simple CRM pipeline sheet for tracking a deal from inquiry to close, and a generated PDF investment brochure for qualifying opportunities.

How it went

On one representative day, 10 April 2026, the monitor scanned 1,010 messages, analysed 2,074 individual listings after splitting multi-listing posts, and flagged 13 deals that cleared the discount threshold. That is the honest measure of what this system does: it turns a firehose of broker chatter into a short, ranked list a working agent can actually act on. We do not have a commission or a closed-deal number attributable to the monitor, and we are not going to attach one; this was throughput instrumentation, not a sales report, and we would rather say that plainly than let a listings-screened number imply a revenue outcome it never measured.

We also know the system was not perfect. Five days after this stat run, a review of the logs found parsing errors on messages that bundled multiple competing offers, and only five of the six groups were being scraped correctly at that point, a limitation we noted at the time.

What we would do differently

We would have built the parsing edge cases, multi-offer messages among them, into the test suite from week one instead of discovering them in production logs after the fact. Free-text parsing of real broker chatter is messier than any sample data suggests. We would also push, next time, for an agreed definition of a business outcome before the automation ships, so the client and we are measuring the same thing from day one instead of settling for throughput numbers because they were the ones we had.