A broker-sourced lead is the most expensive lead a developer buys. You pay a percentage of the sale value for it — far more than a portal lead or an ad click costs — and in most sales offices it is handled the least carefully of any source. It arrives as a WhatsApp message with a name and a number on a rep's personal phone, gets copied into a sheet by whoever is free, and loses the one piece of information that made it expensive: who sent it.
Everything that goes wrong afterwards — the attribution argument at booking time, the commission dispute four months later, the partner who stops picking up — traces back to that moment. This is a guide to the moment, and to the three or four decisions around it that decide whether your channel-partner programme compounds or quietly bleeds.
What does a lost broker lead actually look like?
It is worth being specific, because "we lose broker leads" is four different failures with four different fixes.
The first is the lead that never reaches the pipeline at all. A partner sends a name and number at 9pm to a rep's personal WhatsApp. The rep is on site visits the next morning, the message scrolls up past a hundred others, and nobody in the company knows the lead exists. The partner does not know either — from where they sit, they handed you a buyer and you did nothing with them. This is the failure that costs you a booking and a relationship at the same time.
The second is the lead that reaches the pipeline without its source. Someone re-types the name and number into the system three hours later, and the source field ends up blank, or set to "walk-in", or set to the rep who entered it. The lead is worked and might even book. But the attribution was destroyed at the moment of entry, and no amount of arguing at booking time reconstructs a source that was never recorded. This is the most common failure and the least visible, because nothing looks broken until money is due.
The third is the same buyer arriving twice. Two partners submit the same person within a fortnight, both believing they introduced them, and the question of who earns the commission surfaces at booking — the worst possible time, because by then the amount is known and everyone is arguing about a specific number rather than a principle.
The fourth is the partner who quietly stops calling. Nothing dramatic happens. They just start routing their good buyers to a developer who pays on time and tells them where they stand. This is the expensive one, because you have not lost a lead — you have lost a source, and you will not see it in any report. Your broker submissions this quarter are simply lower than last quarter, and nobody can say why.
Why does the same buyer arrive twice?
Because that is how buyers shop, and it helps to stop treating it as misconduct.
Someone spending a crore or more on a home does not talk to one broker. They talk to three or four in the same week, visit two projects on a Sunday, and mention to each broker that they are looking. Each of those brokers registers the enquiry with the developers they work with, in good faith. When two of those registrations land on your desk for the same phone number, both partners are usually telling the truth. It is not a duplicate in the data-quality sense; it is two genuine claims on one buyer.
There is a third claimant you should not forget: yourself. That buyer may already have clicked a Meta ad, filled a form on your site, or walked into your sales office a month earlier, which means your own marketing has a claim that predates both partners. Developers who only adjudicate broker-versus-broker end up paying commission on buyers they had already bought once.
So duplicates are not an anomaly to be prevented. They are a normal, recurring event to be adjudicated — which means the only real question is whether you decided how to adjudicate them before or after the money was on the table.
What rule should decide who owns a broker lead?
There are three defensible rules, and the wrong move is to have none and improvise per case.
| What it rewards | Where it fails | |
|---|---|---|
| Registration-first | Speed, and evidence that is a machine timestamp | Bulk pre-claiming of buyers a partner never influences |
| First-visit accompaniment | The work that actually moves a property sale | A sourced buyer who then walks in alone |
| Hybrid | Fairness — registration provisional, accompaniment confirms | Two events to record per lead instead of one |
Registration-first, decided by timestamp. The partner who submitted the buyer first, in your system, owns the lead for a defined window. It is the simplest rule to administer and the hardest to argue with, because the evidence is a machine-generated timestamp rather than a memory. Its weakness is that it rewards speed of typing over actual work: a partner who bulk-submits every name in their contact list can pre-claim buyers they will never influence.
First-visit accompaniment. The partner earns the claim only if they physically bring the buyer to the sales office for the first site visit. This rewards the work that actually moves a property sale, and it is the rule the larger developers tend to publish. Hiranandani's public channel-partner terms credit a booking to a partner when an authorised representative of the partner accompanies the client on their first site visit, register that customer to the partner for 90 days, and resolve a contested deal inside the window with a 50-50 split of the brokerage. ↗ Its weakness is that it under-rewards a partner who genuinely sourced and warmed a buyer who then walked in alone.
Hybrid: registration creates a provisional claim, accompaniment or a first meaningful contact confirms it. Most developers end up here in practice. It is fairer and it is more work, because you now have two events to record per lead rather than one.
Whichever you pick, write down four things and put them in the partner agreement before you onboard anyone:
What creates a claim. Be exact. "Submitting the lead through the partner portal" and "bringing the buyer to the sales office" are different events and you should say which one counts.
What evidence proves it. A timestamp, a site-visit check-in, a call log. If the evidence is "the partner says so", you do not have a rule, you have a negotiation.
How long the claim lasts. Ninety days is a common window and a reasonable default. An open-ended claim is unworkable, because a partner will eventually assert a claim on a buyer they mentioned two years ago.
What happens when two claims collide — including yours. Split, first-in-time, or accompaniment-wins are all defensible. What is not defensible is deciding case by case. And state the house rule for a buyer who already exists in your database from an earlier source: does the earlier record win outright, does the partner get a reduced rate, or does the partner get nothing? Say it out loud at onboarding, not at payout.
How do you make the rule enforceable at capture?
A rule that only exists in a PDF gets applied at payout time, which is exactly when it is least useful. It has to be enforceable at the moment the lead is created, and that comes down to five unglamorous mechanics.
One submission route. Partners submit through one channel — a portal, a form, or a single business number that is not any individual's personal phone — and submissions arriving anywhere else do not create a claim. Say that plainly at onboarding, because half of the leakage above is a lead sitting in a rep's private chat.
A machine timestamp, not a typed date. If the time of submission is something a person enters, it is something a person can adjust, and a first-in-time rule adjudicated on a typed date is not a rule.
One phone-number format. This is the least discussed and most damaging detail in Indian real estate. The same buyer will appear as 9876543210, 09876543210, +91 98765 43210 and 91-9876543210 depending on who typed it, and those are four rows in a spreadsheet and one human being. If the number is not normalised to a single form on the way in, your duplicate check quietly never fires and your two-partner collision is discovered by a salesperson calling a buyer who has already been called.
A source field the system stamps, not one a rep types. The moment a source is a free-text field filled in after the fact, attribution becomes an opinion. It should be written at creation, by whatever captured the lead, and changing it afterwards should leave a trace.
An acknowledgement back to the partner within minutes. Tell them the submission was received, give it a reference, and tell them immediately if it collided with an existing record. A duplicate discovered at submission is a two-minute conversation. The same duplicate discovered at booking is a fight over a number.
Why do partners stop sending you business?
Ask a channel partner why they favour one developer over another and the answer is almost never the project. It is that they know where they stand.
Look at it from their side. They submitted forty leads over a quarter. They cannot see what happened to any of them — whether anyone called, whether anyone visited, whether one of them booked. Three did book, apparently. One commission arrived four months later with a deduction nobody explained. They have five developers to choose from, and their next genuinely good buyer will go to the one whose payouts they can predict.
A partner who cannot see their own numbers assumes the worst about yours.
Note that the complaint is rarely about the rate. Partners understand that rates vary and that a percentage is negotiable. What they cannot work with is opacity: not knowing what happened to their leads, not knowing what has accrued versus what has been paid, and not being able to reconcile a payment against their own book. Opacity does not lose you an argument; it loses you the top of your funnel, silently, over two quarters.
The cure is boring and cheap. Give a partner four things: the status of every lead they submitted, the commission accrued against each booking, a stated payout window, and a statement they can check against their own records. None of that requires generosity. It requires that the numbers exist somewhere a partner can see them without asking you.
And be honest about the payout timing itself. Commission is properly an accrual, not a due-on-booking payable — the prudent pattern is that it becomes payable once the money is actually received and the property registered, then is paid inside a stated window. That is a defensible position and partners accept it, provided you say it upfront and then hit the window every time. What destroys trust is not a long window. It is an undeclared one.
What should you measure per partner?
Most developers measure exactly one thing about a channel partner — bookings — which tells you what happened but never why, and gives you nothing to say in a conversation about improving it. Six numbers per partner, per month, are enough.
| What it tells you | |
|---|---|
| Submissions | Whether the partner is still active — a falling count is the earliest warning. |
| Contactable rate | Genuine sourcing versus a recycled database. |
| Site-visit rate | Whether they qualify a buyer before submitting. |
| Booking rate | The outcome you are actually paying for. |
| Accrued vs paid | Whether a payout will be a surprise. |
| Days payable → paid | Your reliability — the number partners rank you on. |
Submissions tell you whether a partner is still active, and a falling count is your earliest warning that a partner is drifting away. Contactable rate — the share of submitted leads that turned into a real conversation with a human — is the number that separates a partner sourcing genuine buyers from one recycling an old database; a partner at a very low contactable rate is submitting volume to pre-claim buyers, and you should discuss it before it becomes a payout argument. Site-visit rate tells you whether they are qualifying before they submit. Booking rate is the outcome. Commission accrued versus commission paid is the number that keeps your own books honest and stops a payout being a surprise.
The sixth is about you, not them: days from payable to paid. This is the number your partners actually rank you on, they discuss it with each other, and most developers have never calculated it. If it is long or erratic, that is your channel-partner problem, whatever else the scorecard says.
The purpose of the scorecard is not to rank partners for its own sake. It is to make the quarterly conversation evidential — "your submissions are steady but only one in five is reachable, let us look at where they are coming from" is a conversation that improves a partnership. "We feel you have not been sending good leads" is one that ends it.
Can you do this without software?
Yes, and it is worth saying so, because the version of this that runs on a form and a spreadsheet is genuinely better than a CRM used badly.
The minimum viable setup is four pieces. One accepted submission route — a single form, or one dedicated WhatsApp business number that nobody uses personally — and a stated rule that anything sent elsewhere does not create a claim. One sheet with one row per submission, where the form writes the timestamp automatically and the phone number is stored in a single normalised format. A duplicate flag: a formula that highlights a number that already exists in the sheet, checked before the lead is assigned, not after. And a one-page partner agreement stating the claim rule, the window, the collision rule, and the payout timing, plus a monthly statement per partner — even if it is a copy-pasted table in an email.
That will carry a small operation a long way. What breaks it is predictable: volume, more than one project, more than one person editing the same sheet, a partner list long enough that rates differ per partner, and the point at which commission has to be reconciled against receipts rather than against bookings. When two of those are true at once, the spreadsheet stops being a record and becomes a source of disputes of its own.
How does Sthan handle this?
We build a real-estate CRM, so treat this section as illustration rather than the argument — the rule, the single submission route and the statement matter far more than the tool, and everything above works without us.
That said, the channel is the part of Sthan we would point at first. Partners sign up, get approved, and log into their own portal with a PIN, where they submit leads and see the leads and deals they have brought — which is the visibility problem above, solved by giving the partner the view rather than by promising to send updates. Those submissions land in the same pipeline as Meta and Google campaigns, the portals, web forms, walk-ins and missed-call capture, tagged at capture with the source and the partner who submitted them, and that attribution follows through to the booking. Indian phone numbers are normalised on the way in, so the same buyer arrives in one form rather than four. Every status change, booking, payment and ownership change is written to an audit trail, which is what lets a contested deal be settled on a timeline rather than on recollection.
On the money: each broker carries their own commission rate, commission accrues against the booking and its receipts rather than against the booking date, there is a pay-commission action to record a payout against the partner, and a broker statement they can download and check against their own books. A leaderboard, channel mix and a broker performance report put what a partner brings next to what they cost. Because pricing is per project rather than per seat, putting every partner and tele-caller in the system does not change the bill — which matters, since the cheapest way to recreate all four leaks above is to ration logins.
What Sthan does not do is worth stating as plainly. It does not decide your commission structure or your attribution rule — those stay yours, and a system applied to undefined rules just produces fast, consistent mistakes. It does not compute TDS or GST on a broker payout, and it does not move money to a partner's bank account; recording the payout and producing the statement is the software's job, while the transfer and the deductions stay with your accounts team. The product detail is on broker management software, and the vendor-neutral mechanics of structures, accruals, escrow timing and the post-RERA tax layer are in our guide to channel-partner commission tracking.
Where to start
If you do one thing this month, do not buy anything. Write the claim rule, send it to every partner you work with, and change the submission route so there is exactly one. That single change closes the first two leaks, which are the two that lose you bookings rather than arguments.
Then calculate your days from payable to paid for the last four payouts. If you cannot calculate it, that is the answer, and it is probably also the reason your best partner has been quieter than they used to be. Broker channels do not usually collapse; they thin out, one unexplained payout at a time, and the developers who keep them are simply the ones who made the process boring enough to trust.