The developer-and-broker CRM: portal lead ingestion with deduplication, one-truth unit inventory with expiring holds, milestone-linked payment schedules, channel-partner attribution and brokerage, and RERA-aware document trails. Status: deployed and demonstrable.
The two calls this product exists to prevent
“Sir, that flat is already booked.” Said to a buyer who was shown it an hour ago by a different broker, because the availability sheet is updated by phone call and two people were confident at the same time. It costs the sale and it costs something harder to price, which is the buyer’s belief that you have your affairs in order.
“That lead was mine.” Said by a channel partner three months after a booking, about a buyer who arrived through a portal, visited with an in-house salesperson, and closed through the partner. Everyone is describing the same events honestly and nobody can prove anything, so the outcome depends on who argues hardest.
Both are records problems wearing commercial clothes, and both are solved by deciding in advance what gets written down.
What the system covers
- Unit inventory, one truth. Available, held, booked, sold — with holds carrying an owner and an automatic expiry, so nothing stays blocked because somebody forgot.
- Lead pipeline with attribution at capture. Portal, partner and walk-in sources recorded and deduplicated on entry, stages managed, follow-ups queued. Marketing spend finally reports on itself.
- Payment schedules against construction milestones. Demand letters generated on trigger, receipts posted, buyer ledgers kept clean, and an overdue report that is honest rather than optimistic — the ledger discipline applied to collections.
- Channel-partner module. Registration, attribution, brokerage computed by rule and reconciled on a schedule rather than negotiated at quarter-end.
- Document trail per unit and per buyer, in the shape disclosures draw on.
- Post-possession. Handover, snags, society transition.
Why attribution deserves its own build
Because it is the most expensive piece of missing data in this trade, and because it cannot be recovered afterwards. Once a booking has happened, every party’s recollection has been shaped by the outcome — not dishonestly, just humanly. The only version that settles anything is the one written at the moment of capture, before anyone knew it would matter.
Recording it takes a field and a rule agreed in advance. That is genuinely the whole fix, and it removes a recurring conflict that costs money, time and partner relationships every quarter.
What deployment looks like
The inventory goes in first, because it is the fastest visible win: every unit, its current state, its price, its hold history where one exists. Within days the availability question has one answer instead of several.
Then leads and attribution, which requires a short conversation about what your rules actually are — the conversation most developers have never held explicitly and which produces some healthy disagreement. Then payment schedules mapped to your construction milestones, then partner brokerage rules encoded.
The trade context and the wider operational picture sit at /industries/real-estate.
What it will not do
It will not sell units. It will not make a slow project fast, and it will not fix a payment schedule the market cannot bear.
What it does is remove the category of loss that comes from records — the double-shown flat, the demand letter that went out late, the brokerage argument, the buyer file with a gap discovered during a dispute. In a trade where single transactions are large, removing that category is usually worth more than any marketing improvement bought with the same money.
The reports that change behaviour
Inventory ageing by unit. Which flats have been available longest, at what price, with how many enquiries. Developers usually know their fast-movers and rarely know their slow ones with any precision, and the slow ones are where pricing decisions actually matter.
Source-to-booking conversion. Not leads by source — bookings by source, which is a different and far less flattering table. It routinely reveals that the portal generating the most enquiries generates the fewest sales, and that the partner generating few leads converts most of them.
Collections against milestones. What has been demanded, what has been received, what is overdue and by how long, per project. Construction-linked payment plans fail quietly when demands go out late, and the failure surfaces as a cash-flow problem months later.
Partner performance. Bookings, conversion and brokerage per channel partner, computed rather than remembered — which makes the annual conversation about terms a discussion of numbers.
Four reports, all drawn from data the system captures anyway. None of them require anyone to fill in a form for reporting’s sake, which is why they stay accurate.
Who it fits
Developers running one to a few projects at a time, brokers with a team rather than a desk, and channel-partner networks that need both halves of the picture. For very large developers with enterprise systems already installed, this is the wrong tool and I will say so rather than compete on price for a bad fit.
The clearest signal that it fits: your availability truth currently lives in a spreadsheet that more than one person edits, and reconciling it has quietly become somebody’s weekly job.
Related reading
/industries/real-estate — the trade context in full · /products/whatsapp-automation — site-visit confirmations and demand reminders · /industries/contractors — the construction-side sibling · /services/fintech — the collections discipline
Bring one tower
Bring the live availability sheet for a single project and the last brokerage disagreement you had. We will model both on the call, and you will see the double-booking become impossible. /contact.
Questions I actually get
Brokers or developers?
Both, with different cores. Brokers get the lead pipeline, attribution and brokerage tracking. Developers add unit inventory, milestone-linked payment schedules and demand-letter generation. Channel-partner networks need both halves, which is exactly why the two are one product rather than two.
Can it pull leads from the property portals?
Yes, with deduplication at entry — one buyer enquiring through three portals in a week becomes one record with three sources, rather than three leads inflating your pipeline and corrupting every attribution number downstream.
How do unit holds work?
A hold is a state with an owner and an expiry. When it lapses the unit returns to available automatically. That single rule makes it structurally impossible for two brokers to be confidently selling the same flat, which is the call this product exists to prevent.
Does it handle RERA compliance?
It maintains the trails that filings and disclosures draw on — bookings, agreements, receipts, buyer communications, all organised per unit. Your compliance owner files; the system makes the evidence a query rather than an archaeology project.
How is channel-partner brokerage calculated?
By rule, against attribution recorded at lead capture rather than reconstructed at settlement. The quarterly brokerage argument exists because attribution is remembered; rules applied to recorded attribution do not argue.
What about after possession?
Handover tracking, snag lists and society-transition support, because post-possession is where developer reputation is actually made and it is usually the least systematised part of the business.