Invisible CRM

The brokerage's agents worked primarily inside WhatsApp. A separate CRM had already failed to stay current, while listing and buyer requirements still had to be matched manually.

• ▸Voice notes and messages are turned into structured client records automatically
• ▸Natural-language search — ask "Jounieh buyers under $300K" and get the list
• ▸Auto-match alerts: when a new listing fits an old buyer's criteria, the agent is notified
• ▸Zero learning curve — the whole thing runs inside the WhatsApp the agent already uses

• ·Natural language queries ("Jounieh buyers under $300K")
• ·Auto-match alerts when new listings fit old clients
• ·Zero learning curve

The brokerage's agents spend their whole day inside WhatsApp — buyers send voice notes, listings arrive as photos, and the agent who replies first usually wins the deal. Two CRM attempts had already failed for the same reason: any tool that asks a busy agent to stop, open another app, and fill a form simply doesn't get used. The design constraint was absolute: zero change to how agents work.

Messages flow from the WhatsApp Business API into a Node.js service, where Claude turns voice notes and free-text chats into structured client records — budget, area, property type, urgency — without manual tagging. Those records are embedded for vector search, which lets an agent ask in plain language ("Jounieh buyers under $300K") and retrieve matching records. A matching engine runs in the other direction: every new listing is compared against stored buyer criteria, and when something fits, the assigned agent gets an alert.

Most CRM projects fail at adoption, not engineering. Here the CRM has no interface an agent must learn: capture, organisation, and matching all happen behind chats that were happening anyway. The brokerage gets the memory and follow-up discipline of a CRM while agents just keep selling.

The delivered workflow captures, structures, searches, and matches client requirements from WhatsApp without requiring agents to maintain a second interface.

Measurement note: this case study documents delivered functionality and architecture. Client-approved before/after KPIs, adoption data, and revenue impact are not measured or published here.