Plenty of brokers run on three phones and a diary. Portal leads on one phone, WhatsApp on another, site visits scribbled in the diary. A buyer with an ₹80-lakh budget goes cold, and not because they found a better flat. The follow-up lived on the phone that was charging at home.
Every decision below is one a real estate portal has to make. How to model a buyer's requirement, where portal leads land, what happens when the same buyer inquires twice. This is how to build a real estate CRM around those decisions rather than around a generic contact list.
The general foundations are elsewhere: the four-table core, the pipeline state machine, buy-versus-build all live in my custom CRM development guide. This post is only what real estate adds on top.
Three assumptions real estate breaks
A generic CRM assumes a deal is one buyer, one product, a few weeks. Property breaks all three at once.
A buyer is not attached to a listing. They are attached to a requirement — 3BHK, Vaishali Nagar or nearby, under 90 lakhs, ready to move — and you evaluate many listings against it. The cycle runs in months rather than days, so a CRM tuned for hot leads quietly loses the majority who buy in month three. And the pipeline has a physical heartbeat, which is the site visit. Nothing predicts closure like a completed one, so the whole system should bend toward getting one scheduled and then following it up.
Then there is the intake problem. Leads arrive from portals, from WhatsApp, from a hoarding with a phone number on it, from walk-ins and referrals, often all for the same buyer in the same week.
Get those into the architecture and the rest is engineering. Miss them and you have built a contact list with extra steps.
The requirement is data, not a note
This is the schema decision that matters most, and it is easy to get wrong because the wrong version is faster to build.
The moment "3BHK under 90L in Vaishali Nagar" is a sentence in a notes field, matching becomes a human rereading notes, and the CRM's best feature is dead before it shipped.
-- On top of the CRM core (contacts, leads, activities) real estate adds:
CREATE TABLE listings (
id uuid PRIMARY KEY DEFAULT gen_random_uuid(),
purpose text NOT NULL, -- 'sale' | 'rent'
property_type text NOT NULL, -- 'flat' | 'house' | 'plot' | 'commercial'
bhk int,
locality text NOT NULL,
price numeric NOT NULL,
status text NOT NULL DEFAULT 'active', -- 'active' | 'sold' | 'withdrawn'
attrs jsonb, -- furnishing, floor, facing, age…
created_at timestamptz NOT NULL DEFAULT now()
);
CREATE TABLE requirements (
id uuid PRIMARY KEY DEFAULT gen_random_uuid(),
lead_id uuid NOT NULL REFERENCES leads(id),
purpose text NOT NULL,
property_type text NOT NULL,
bhk_min int,
budget numrange NOT NULL, -- Postgres range type: '[6000000,9000000]'
localities text[] NOT NULL, -- 'Vaishali Nagar', 'Jhotwara'…
timeline text, -- 'immediate' | '3-months' | 'exploring'
created_at timestamptz NOT NULL DEFAULT now()
);
CREATE INDEX idx_req_localities ON requirements USING gin (localities);The numrange for budget and the text[] for localities are doing real work there. Postgres gives you honest range and array queries out of the box, so "find every buyer whose budget covers this price and whose localities include this one" is one indexed query instead of an application-side loop over every open lead.
The mistake here is over-modelling on day one. Thirty columns for facing, vastu, floor preference, parking. Keep the matchable fields structured, which means purpose, type, BHK, budget, locality and timeline, and push soft preferences into jsonb until matching on them proves necessary. It usually does not.
Matching is the feature that earns the name
This is the moment a real estate CRM becomes worth building rather than buying. A new listing goes live and within a minute every agent knows which of their open buyers it fits. Buyers stop being rows in a table and become demand you can act on.
Once requirements are structured, the query is almost embarrassingly simple:
-- New listing just went active — which open buyers does it fit?
SELECT l.id AS lead_id, ct.full_name, ct.phone, r.timeline
FROM requirements r
JOIN leads l ON l.id = r.lead_id AND l.stage NOT IN ('closed-won','closed-lost')
JOIN contacts ct ON ct.id = l.contact_id
WHERE r.purpose = $1 -- listing.purpose
AND r.property_type = $2 -- listing.property_type
AND (r.bhk_min IS NULL OR r.bhk_min <= $3)
AND r.budget @> $4::numeric -- budget range contains listing price
AND r.localities && $5::text[] -- localities overlap
ORDER BY (r.timeline = 'immediate') DESC, l.created_at;Run it on listing creation, drop the results into each agent's queue as a task, and log the shortlist share as an activity so you can see later who got told what.
Run it in reverse too. When a requirement is captured, generate the buyer's first shortlist on the spot, because speed to first shortlist is real estate's version of speed-to-lead and it is the one thing a buyer notices in the first conversation.
Point the pipeline at the site visit
Every stage in a real estate pipeline is either before the visit, where it exists to get one scheduled, or after it, where it exists to convert one. That framing hands you the stage flow for free:
new → contacted → requirements captured → shortlist shared → visit scheduled → visited → negotiation → token → closed won / lost
Enforce it as a state machine, only explicit transitions, each logged as an activity. The mechanics are in the custom CRM guide; what it buys you specifically here is worth spelling out.
The two metrics that run a brokerage are inquiry-to-visit rate and visit-to-close rate, and both fall straight out of transition logs with no spreadsheet archaeology. A lead cannot reach visited without a scheduled visit activity behind it, so whether anyone took the buyer to the site is never a matter of opinion. And lost → contacted has to be a legal transition, because property buyers resurface after three months constantly, and a pipeline that cannot reopen a lead is throwing away demand you already paid for.
Because the cycle is long, follow-ups have to be owned by the system rather than by someone's memory. Every stage carries a next-action date. A lead with no future action is leaking, by definition, and that is a query you can run daily.
One intake, deduplicated by phone
The broker with three phones was not disorganised. He had three lead channels and no convergence point. Your intake layer is that convergence point, and it has two non-negotiable properties.
Every intake endpoint is idempotent. Portals re-send webhooks and email parsers re-run, and without an idempotency key you create duplicate leads, two agents call the same buyer, and your brokerage looks exactly as chaotic as the diary it replaced. Portals will exercise that retry path weekly, so the natural key and the upsert are part of the feature rather than hardening work for later. The full pattern is in idempotent APIs and webhooks.
And the phone number is the identity key, normalized to E.164 at the door. The same buyer inquires on a portal listing on Monday and calls the hoarding number on Saturday. That is one lead with two source activities.
If your CRM serves many brokerages rather than one, tenancy is a day-one decision and not a retrofit. I compare shared-schema against schema-per-tenant in multi-tenant data isolation.
Scope the MVP ruthlessly
Real estate software has infinite tempting features. Valuation models, 3D tours, EMI calculators, AI-written descriptions. None of them save the ₹80-lakh buyer whose follow-up got forgotten.
Version one captures every channel into one phone-deduplicated queue with the source recorded. It captures structured requirements on first contact, matchable from day one. It matches both directions, so a new listing alerts open buyers and a new requirement gets an instant shortlist. It runs the visit workflow end to end: schedule, remind, mark done, capture the outcome as an activity. And it carries next-action dates, so a months-long pipeline cannot silently leak.
Everything else waits until the core is trusted. The discipline to cut is a product skill rather than an engineering one, and the tenancy decision belongs in the same first week as all of this.
Where I would start
Model the domain honestly and the exotic tech never comes up. Requirements structured and queryable rather than written down. The pipeline pointed at the site visit. Matching turning a buyer list into live demand. Every chaotic channel forced through one idempotent, phone-keyed intake.
That is the system that still remembers the buyer in month three, long after the diary forgot him.
Starting from zero, read the custom CRM development guide first for the core model.