A promise looks dependable in a chat. “I’ll send it this evening.” “I’ll get back after the meeting.” “I’ll check with the owner.” Then forty more messages arrive, and the promise goes to a small textual graveyard where finding it almost requires a conscience.
My broker CRM grew from wanting to see this work as a whole. The contact, source, history, next step, and prepared message need to sit together. Otherwise the agent spends time rebuilding their working memory rather than selling.
This screen brings together information about a fictional owner, their properties, and the working history. It shows how a contact becomes a working dossier rather than remaining a row with a phone number.
Owner dossier
Archived interface · demo data
Three databases for three kinds of information
The current architecture uses Cloudflare Workers and separate D1 databases for the CRM, secondary-market leads, and broker index. This separation helps avoid treating every phone number found as a full client with identical rights and history.
A separate screen shows a fictional buyer’s requirements. It lets you examine the other side of brokerage: what someone is looking for and which details are needed for the next round of matching.
Buyer requirements
Archived interface · demo data
The operational layer creates work batches and actions. Reprocessing has duplicate protection: a prepared step must not materialise again because a job was rerun. This is called idempotency. A long name for a simple everyday purpose: a computer should not double the work just because it failed to hear itself.
Sending messages remains a separate manual action. The system can prepare a contact and text, but an intention to write does not count as communication that has already happened. An opt-out blocks further work through that channel.
AI helps at the input; the database is needed at the output
A conversational interface helps express a task in ordinary words. But the result must become a concrete record, with a clear recipient, status, and next action. If everything stays inside the assistant’s answer, the CRM has learned nothing.
An external spreadsheet must not quietly remain a second active database either. Otherwise an operator updates a contact here, an agent reads an old export there, and both believe they are being careful.
Not every planned module became an operating workflow. The Comps Engine valuation module and associated PDF workflows are paused. Some recent technical changes still need separate checks in the working environment. I do not bundle plans, source code, and verified operations into a promotional claim that “everything is automated”.
In the CRM, I connect the contact, property details, and next step. Sending is separate from preparation: that makes promises and actions visible without presenting all the work as automatic. Comps Engine and its associated PDF workflows are described separately as a paused direction.
Related stories: Early WhatsApp tool · WhatsApp for the team · Comps Engine exploration.
@nevsky_alexander
On Instagram: Dubai beyond the postcard — family, the city, discoveries and life between projects. On Threads: thinking out loud about design and AI. On YouTube: videos that need more room than a story. Follow me wherever you feel at home, and let’s keep in touch