Ask a developer's sales head what happened on launch day and you get the same story from Gurugram to Dubai. Two channel partners claim the same buyer. A unit gets sold twice because the hold expired in someone's head but not in the system. The price list changed at 11 am and half the team quoted the old one. By the end of the week, the truth about who booked what lives in a WhatsApp group and a spreadsheet that three people edit.
None of this is a people problem. It is a data model problem. The CRM was set up to track leads, and a developer does not sell leads. A developer sells inventory.
This is the blueprint we use when a property developer in India or the GCC moves lead-to-booking onto Salesforce. It is written for the sales head and the CFO, not for the admin.
The object model: inventory first
The mistake is starting with Lead and Opportunity. Start with what you are selling.
- Project, then Tower, then Floor, then Unit. A unit has a type, a carpet and built-up area, a facing, and a status: available, on hold, booked, allotted, handed over. That status field is the most important field in the org.
- Price List, versioned. A price list belongs to a project and has an effective date. When the price changes, a new version is created and the old one stays for audit. Every quote references the version it was made from, so "which price did you promise" is a lookup, not an argument.
- Hold, with an expiry. A hold is a record, not a note. It has a unit, a buyer, a channel partner if any, a created time, and an expiry time. When the expiry passes, an automation flips the unit back to available and notifies the salesperson. No human has to remember.
- Booking, then Payment Milestone, then Allotment, then Handover. Each is its own record with its own dates, so receivables reporting reads from the system instead of from finance's memory.
Lead and Opportunity still exist. They sit on top of this model, not instead of it. A lead converts to a buyer, a buyer holds a unit, a hold becomes a booking, a booking has milestones.
Double-booking prevention at the record level
Every developer has been told "the CRM prevents double booking" and every developer has seen it happen anyway. The reason is that the prevention was a warning, not a rule.
On Salesforce it can be a rule. The Unit's status is controlled by automation that fires when a Hold or Booking is created. If a second Hold is created against a unit that already has an active hold, the record is rejected before it saves, with a message naming the existing hold and its expiry. That is a validation, not a popup someone can click through.
Launch day changes completely when this is true. The inventory dashboard shows available, held, and booked counts per tower in real time, and every salesperson on the floor sees the same numbers because there is only one place the numbers come from.
Channel partners: attribution with a timestamp
Channel partner disputes cost developers more than any other single process failure, because the cost is paid twice: once in commission paid to the wrong partner, and again in the partner relationship that sours when the dispute goes against them.
The fix is boring and it works. A Channel Partner object with registration details and the partner's RERA registration number where applicable. A lead attribution record created the moment a partner submits a lead, with a server timestamp the partner cannot edit. A dispute audit trail that shows both claims side by side with their timestamps.
When two partners claim the same buyer, the answer is the earlier timestamp, and both partners can see it. Most disputes end there. The ones that do not get escalated with a record, not a memory.
On top of attribution sit the pieces partners actually care about: tiered commission calculation based on the booking value and the partner's tier, payout tracking against milestones, and a self-service portal on Experience Cloud where a partner sees their leads, their bookings, and what they are owed. Partners who can see their own pipeline stop calling your sales team to ask.
WhatsApp is the channel, Salesforce is the record
Buyers in India and the GCC live on WhatsApp. Fighting that is pointless. The goal is not to move buyers off WhatsApp; it is to make sure everything that happens on WhatsApp lands on the record.
Site visit scheduling, document collection for KYC and booking, and payment reminders against milestones all run on WhatsApp through an approved business messaging integration, and each message is logged to the buyer and the booking in Salesforce. The salesperson works in the chat. The CFO reads the record.
This is also where an Agentforce agent earns its place. A no-show recovery agent that follows up a missed site visit within the hour, a payment milestone chaser that sends the reminder and logs the response, and a first-line qualification agent for portal leads at 2 am. Each is one topic, one workflow, and one number that tells you whether it paid for itself.