Real Estate Agency Listings: Private AI for Market Monitoring and Client Matching

the agency lists condos and landed property across four platforms: DDProperty, Hipflat, FazWaz, and their own website. each platform has its own dashboard, its own notification system, and its own format for listing data. when a new condo project launched units in Ari or a townhouse price dropped in Ekkamai, individual agents would find out whenever they happened to check. sometimes that was the same morning. sometimes it was three days later, after a competitor had already contacted the seller. buyer management was worse. the agency maintained a shared Google Sheet with buyer preferences: budget range, preferred areas, condo or house, Thai or international buyer, financing needs. matching a new listing to the right buyer meant scanning rows, remembering conversations, and hoping the sheet was up to date. it rarely was. transaction coordination lived in Line group chats. contract deadlines, transfer dates, document requirements, and commission splits were scattered across dozens of conversations. finding the status of a specific deal meant scrolling through chat history or asking three people. the agency had grown to 18 agents, a mix of Thai nationals working the local landed market and bilingual agents handling international condo buyers. the manual processes that worked with six agents were breaking down. listings were missed, buyers were contacted too late, and deals fell through cracks between platforms. none of this required artificial intelligence. it required a system that could watch multiple sources, match structured criteria, and push information to the right person at the right time. the private AI layer made that system conversational and adaptive instead of rigid and rule-bound.

the system runs on a server in the agency's Bangkok office. it connects to four listing platforms via their APIs and web feeds, the agency's internal CRM database, a shared calendar for transaction milestones, and the team's Line group for notifications. the listing monitor runs on a scheduled cycle. it pulls new and updated listings from DDProperty, Hipflat, FazWaz, and the agency's own site. each listing is normalized into a common schema: price, area, district, property type, floor area, number of bedrooms, listing date, and price history. when a price drops on a monitored listing or a new property appears in a tracked district, the system evaluates it against all active buyer profiles. buyer profiles are structured records, not spreadsheet rows. each profile captures budget range, preferred districts, property type, size requirements, nationality and language preference, financing status, and timeline urgency. agents create and update profiles through conversation: "add a new buyer, budget 8 to 12 million, looking for a 2 bed condo in Thonglor or Phrom Phong, Thai national, pre-approved for financing, wants to move within 3 months." the system parses this into a structured profile and confirms the details back. when a listing matches a buyer profile, the assigned agent receives a notification through Line with the listing details, the match reasoning, and a link to the full listing. the agent decides whether to act on it. the system surfaces opportunities. it does not contact buyers or make decisions. transaction tracking is event-driven. when an agent marks a listing as "under offer," the system creates a timeline: deposit deadline, contract signing date, transfer date, and document submission deadlines. each milestone generates a reminder to the responsible agent and the office coordinator. if a deadline passes without being marked complete, the coordinator gets an escalation. the entire system is orchestrated by OpenClaw. the plugin architecture wraps each data source and action as a typed tool. the cron scheduler handles listing monitoring cycles, daily match reports, and deadline reminders. the messaging layer delivers everything through Line, where agents can ask follow-up questions and the system queries the same database the automated reports use.

the morning starts with a team digest pushed to the agency's Line group. new listings in tracked districts, price changes on monitored properties, and any buyer matches from overnight. each agent also gets a personal summary: their active buyers, any new matches, and upcoming transaction deadlines for their deals. throughout the day, agents interact conversationally. "show me all 2 bed condos under 10 million in Sukhumvit that listed this week" returns a filtered set from the normalized database, not a platform-specific search. "what's the status on the Ari transfer?" pulls the transaction timeline with completed and pending milestones. "update mrs. chen's budget to 15 million and add Sathorn to her preferred areas" modifies the buyer profile immediately. the office coordinator uses the system differently. "which deals have deadlines this week?" produces a summary across all active transactions. "how many new listings matched buyers this month?" gives a pipeline report. "which agents have uncontacted matches older than 48 hours?" flags follow-up gaps. when a new listing appears on DDProperty that matches three buyer profiles, the system notifies all three assigned agents simultaneously. it includes the listing details, the match score for each buyer, and which criteria aligned. the agents independently decide whether to reach out to their buyers. the system tracks whether the match was acted on so the coordinator can follow up on stale leads. market monitoring runs in the background. the system tracks average price per square meter by district, listing volume trends, and days-on-market averages. when an agent asks "how's the Thonglor condo market compared to last quarter?" the data is already aggregated. no manual research required.

the measurable difference is speed. the median time between a new listing appearing on a platform and the matched agent being notified dropped from an estimated two to three days (based on when agents reported finding listings manually) to under four hours. for high-priority buyer profiles, notifications arrive within the monitoring cycle. fewer listings slip through. before the system, agents estimated they caught roughly 60 to 70 percent of relevant new listings across all platforms. the rest were found by competitors first or discovered too late. with normalized monitoring across four platforms, coverage is effectively complete for tracked districts and property types. transaction coordination improved because deadlines became visible. before the system, missed deadlines were discovered when someone asked about a deal and found out a document was overdue. the milestone tracking and escalation removed the need to rely on memory or chat history. the buyer matching quality improved as profiles became richer. agents started adding more detail to profiles because the system actually used the information. a note about a buyer preferring high floors or avoiding main-road-facing units became a matching criterion instead of a forgotten detail in a spreadsheet comment. the coordination benefit compounds with team size. the system that helps 18 agents manage 350 buyer profiles and 2,400 listings would be unmanageable manually. the agency can grow without the matching and coordination overhead growing proportionally. the privacy aspect matters for the agency's clients. buyer financial details, preferred areas, budget ranges, and transaction timelines are commercially sensitive. the system processes all of this on the agency's own server in their own office. no client data flows to external AI services or cloud platforms. the agency controls their data completely.

the core is an OpenClaw instance running on a local server in the agency's office. the database is SQLite, storing normalized listings, buyer profiles, transaction timelines, match history, and market aggregates. each data source and action is wrapped as a typed plugin: listing ingestion, buyer profile management, transaction tracking, match evaluation, and market analytics. listing ingestion uses four paths: API polling for platforms that offer structured feeds, HTML parsing for platforms that do not, the agency's CRM database for their own listings, and manual entry through conversation for off-market properties. each platform adapter normalizes data into the common schema. adding a new platform means writing an adapter, not redesigning the matching logic. the matching engine is deterministic. buyer criteria map to structured queries against the listing database. price range, district, property type, bedroom count, and floor area are hard filters. secondary preferences like floor level, facing direction, and proximity to BTS stations are soft scoring factors. the system ranks matches and explains why each listing was surfaced. no opaque relevance score, just transparent criteria matching. the language model handles natural language interaction, daily digest composition, and conversational profile management. it does not make matching decisions. the boundary between structured computation and language model inference is explicit: matching is code, communication is the model. OpenClaw's cron scheduler runs the listing monitoring cycles (every four hours), morning team digests (07:00), deadline checks (twice daily), and weekly market summaries (Monday morning). the messaging layer delivers through Line using the Messaging API. agents interact in the same Line interface they already use for client communication. the system handles Thai and English natively. listing data from Thai-language platforms is processed as-is. buyer profiles and agent interactions work in both languages. international agents communicate in English, Thai-speaking agents in Thai, and the system responds in the language used.