Sales automation for real estate teams, without writing code.

The 11pm portal lead is the reason this exists

Portal enquiries do not respect office hours. A serious buyer browsing 99acres at 11:40pm submits a form, receives an automated acknowledgement, and then waits. In most Indian brokerages the lead sits in a shared inbox until somebody opens it the next morning, gets screenshotted into a WhatsApp group, and is finally called around 3pm — roughly sixteen hours after peak intent.

The automation that fixes this is unglamorous and enormously valuable. Out-of-hours leads are acknowledged immediately with a WhatsApp template, queued, and fanned out at 9am to the broker who covers that locality and speaks that language, with load balancing so the same person does not receive eleven of them. First contact happens at 9:05am instead of 3pm.

Routing rules can consider territory, language, project, current load, and historical conversion. Round-robin with skip-busy is the common starting point; weighting by close rate is where teams end up once they trust the data.

• Immediate acknowledgement outside working hours
• Morning fan-out with load balancing across the team
• Routing by locality, language, project or conversion history
• Spillover when a broker is over capacity, without losing the queue

Follow-up cadence: the discipline nobody sustains manually

Every sales trainer in the country teaches the same cadence. Call within two minutes. If no answer, WhatsApp within the hour. Call again the next morning. Try a different time of day on day three. Most leads that convert do so after the fourth or fifth touch, and most brokers stop at two.

This is not a motivation problem. A broker holding forty live leads cannot hold forty separate schedules in their head while also running site visits. So the cadence becomes the system's job: the sequence fires on schedule, across call reminders, WhatsApp templates and tasks, and it stops the instant the buyer replies or the stage advances.

That last part is what separates a cadence from spam. A rule that keeps messaging a buyer who has already responded damages the relationship and, on WhatsApp, damages your number's quality rating. Skip-if-replied, skip-if-interested and skip-if-booked are defaults rather than options, and per-source playbooks let a portal lead be worked differently from a referral.

The clocks that are specific to Indian property

Real estate has deadlines that a generic sales CRM does not know exist. After a booking, an agreement has to be executed, stamp duty paid and the sub-registrar appointment completed — and a booking that stalls at that stage is a deal at genuine risk, not a formality. Payment milestones on a construction-linked plan need chasing months after the sale conversation ended. Brokerage tranches fall due on registration and possession, long after anyone is thinking about that buyer.

These are exactly the events automation should own, because they happen too late for human memory to be reliable. A booking without registration after thirty days raises an exception. A payment milestone due next week generates a reminder to the buyer and a task to the relationship owner. A brokerage tranche whose trigger has occurred but which has not been invoiced becomes a visible gap rather than a silent loss.

Escalation follows the same logic. A hot lead uncalled for two hours, a site visit that should have had a check-in twenty minutes ago, a deal that has not moved in a week — each is a rule, and each turns into one notification to the right person instead of thirty raw pings that get muted by Wednesday.

• Registration clock tracked from booking, with exceptions raised
• Payment milestone reminders to buyer and owner
• Brokerage tranches that came due but were never invoiced
• Quiet hours and severity-based channels, so alerts stay meaningful

Why this is built in, not bolted on

The usual answer to CRM automation in India is an integration platform stitched on top — a subscription, a per-task bill, a set of webhooks, and a person who understands it whose departure quietly breaks the whole thing. It also means your lead data travelling through a third party's servers, which is a poor answer to a DPDP question and an even poorer answer to a customer asking who can read their information.

SaudaFlow's engine runs inside the product, on Mumbai infrastructure, against data that never leaves the tenant boundary. Rules are rate-limited per workspace so a runaway rule cannot degrade another tenant, and every automated action is attributed in the audit trail exactly like a human action — you can always see that a stage moved because a rule moved it, and which rule.

Templates from real Indian playbooks are the starting point rather than a blank canvas: a builder pre-launch ramp, a channel-partner activation sequence, a site-visit close loop, and a possession handover. Start from one, change what is unique to you, dry-run it, arm it.