How to choose a real estate CRM in India — an evaluation framework
Most CRM evaluations start with a demo and a feature list, which is exactly backwards. The feature list is the vendor's framework, built to flatter the vendor's product. A developer needs its own framework first — then has to score every option, including the one it likes, against the same standard.
Why general-purpose CRM software fails Indian real-estate developers
A CRM is a model of how a business sells. A general-purpose CRM models a generic sales motion: a lead, a few pipeline stages, a "won" deal. That model is not wrong — it is just not real estate, and especially not Indian real estate, where the sale runs through brokers and portals, produces RERA documents, and continues for years after the booking through construction-linked payments.
Most products a developer evaluates fall into four categories, and the limits are structural, not cosmetic.
Horizontal CRMs adapted to real estate are general-sales platforms with property custom fields added. They are mature, configurable, and connect to everything — but every real-estate workflow, from the inventory grid to RERA documents to broker payouts, has to be built on top, and they are usually priced per user.
Indian sales-engagement platforms are Indian-built lead and sales tools, strong on lead management and local support. Most are not real-estate-specific, though, so the inventory, RERA, and construction-linked collections are simply absent.
Global vertical real-estate CRMs are real-estate-specific and often polished — but built for the US agent-and-brokerage model. They have no concept of RERA, construction-linked milestones, rupee-and-lakh notation, the Indian portals, or broker-payout logic.
Indian real-estate CRMs are the category built for the actual problem: Indian, real-estate-specific, developer-facing. They vary widely — some are legacy and enterprise-heavy with multi-month implementations, some are newer and lighter. Sthan is one of them, and the rest of this guide is the rubric to judge any of them, Sthan included.
Portfolio handling
What good looks like: every project a developer is selling lives in one workspace — its inventory, its leads, its team — switchable in a click, with portfolio-wide views management can open without asking three people for three spreadsheets.
When this is poor, it is a separate instance, login, or sheet per project. Each launch stands up a new silo, leadership never sees one number across the portfolio, and finance reconciles by hand at month-end. The CRM meant to consolidate becomes one more thing to consolidate.
This matters in India because developers rarely run one project at a time. A builder typically has several towers at different construction stages, plus the next launch in the pipeline, and the software should absorb a new project rather than require a new system for it.
Sthan handles this as a single workspace across unlimited projects — but the criterion cuts both ways. A builder with one project and no plans to add another gains little from a multi-project model, and at the far end, a developer running 200-plus units across multiple states may need more depth than Sthan has today. Portfolio handling matters in proportion to portfolio size; weigh it against yours. Worth checking against every candidate: whether adding the next project changes the bill at all. On Sthan it does not — what moves the price is the size of your own team, which the pricing and ROI guide works through.
Sales-channel model
What good looks like: the CRM captures and attributes every channel a developer actually sells through — direct inquiries, channel-partner brokers, the property portals, and walk-ins — and treats the broker relationship itself as a first-class object, tracking who sourced which lead and what payout it earns.
The failure mode is a CRM built for direct sales with brokers and portals bolted on as tags or manual imports. Broker-sourced leads arrive without attribution, payouts get rebuilt in a spreadsheet at the end of the quarter, and the channel that produced the most bookings is the one the system understands least.
In India this is not a minor channel — for many developers, brokers and the portals (MagicBricks, 99acres, Housing.com) produce the majority of qualified leads, not the direct website. A model that treats channel partners as second-class misses where the business actually comes from.
Sthan is built around this: a broker portal with its own logins, source attribution on every lead, and payout logic — the area customers describe most often. On the customers page, Jakesh Prajapati at Harnav Lavish calls Sthan "the simplest way for builders to track broker-sourced leads," and Mehul P at Agilent Infrastructure calls it "the operating system for any builder serious about broker-channel sales." Portal enquiries from MagicBricks, 99acres and Housing.com are captured automatically alongside Meta and Google, so partner-sourced and portal-sourced leads land in the same pipeline with their source attached. The capture and channel mechanics are detailed on the product page.
RERA and compliance
What good looks like: the CRM generates the RERA-aware documents a sale actually produces — allotment letters, demand notes, receipts, possession letters — from the builder's own templates, auto-filled from the booking record, with filings tracked against the relevant project registration.
When this is poor, the CRM is a generic file store. Compliance documents are created somewhere else — usually Word — and uploaded as PDFs with no link to the booking they belong to and no awareness of what RERA requires at which stage. The document and the data drift apart, which is exactly the gap that produces errors.
This is specifically an Indian criterion. RERA makes particular documentation and filings mandatory at defined points in a sale, and getting them wrong carries real penalties. A global CRM has no concept of any of it, because the regime does not exist in the market it was built for.
Sthan handles RERA filings and document generation from templates the builder controls, filled from the same record that ran the pipeline. The honest boundary — and Sthan states it plainly itself — is that this is a generation engine, not legal sign-off: Sthan produces the documents; the builder's counsel reviews and owns the final versions. A CRM that claimed to remove the lawyer from the loop would be the one to distrust. The document capability is described under RERA documents on the product page.
Built for Indian operations
What good looks like: the product fits how Indian buyers communicate and how Indian money works. WhatsApp is a native channel through the Business API, not a link; the interface is one a multilingual sales team can actually use; amounts are in rupees with lakh and crore notation; invoicing understands GST; and NRI buyers are handled rather than improvised around.
The poor version is a product localised on the surface. The "WhatsApp integration" is a click-to-chat button. The screens are dollars, commas, and English only. The invoice does not know what GST is. Each of these is survivable alone; together they are daily friction for the people who live in the system, and friction is what quietly kills adoption.
This matters in India because WhatsApp is the default channel a buyer will actually read, and sales teams across the country work in several languages at once. A product that treats these as afterthoughts asks its users to adapt to it, rather than the other way round.
Sthan is built for this end of the market — native WhatsApp Business API, rupee-and-lakh formatting, GST-correct invoicing, and an interface in English, Hindi, and Gujarati. Those three languages are the honest limit: a team operating primarily in, say, Tamil or Marathi should confirm the fit before committing. How the WhatsApp side runs as an automation engine is the subject of the marketing automation and drip campaign workflows guide.
Workflow scope: does it stop at the booking?
What good looks like: the record runs the full arc a developer's revenue depends on. It does not stop at the booking; it carries through the construction-linked payment milestones, the collections against them, and possession — on one system, so the buyer's whole history stays in one place.
The failure mode is the CRM that marks the deal "won" at the booking and stops. The next twelve to thirty-six months — the milestone collections, the demand notes, the possession handover — get handed to a separate accounts system or a spreadsheet, and the context built up over the sale is left behind at the handoff. The question to ask any CRM is simply: does it stop at the booking, or does it keep going?
This matters in India because the sale is construction-linked. The money does not arrive at booking; it arrives over years, milestone by milestone, and those milestones are precisely where booked revenue is either collected or quietly lost. A system that loses interest at the booking cannot help with the part where the revenue actually lands.
Sthan carries the record from inquiry through possession as one workflow. The honest qualifier: this depth matters most to a developer that runs its own collections; a builder that fully outsources post-booking accounting to a separate finance function may weigh it less. The full arc is walked stage by stage in the lead-to-possession process automation guide.
Pricing model
What good looks like: a pricing model with a stated, defensible answer to one question — who counts as a billed user? The right answer is the people on your payroll. Everyone else who needs a login to make the sale work — the channel partner submitting leads, the buyer following construction — should cost nothing to let in.
The poor version is per-user pricing that counts every login. Ask the vendor what happens when you hand a portal login to every channel partner on your list; if the answer is that each one is another billed seat, the model is quietly pricing your distribution network. That is the trap: the bill rises with every partner you onboard, so the rational move becomes to stop giving partners logins — which is precisely backwards for a channel-led sales motion.
This matters in India because most developers do not sell principally through their own desk. Brokers and the portals produce a large share of qualified leads, so most of the logins a real-estate CRM ever issues belong to people who are not employees. A pricing model that cannot tell those apart from staff will always be the wrong shape.
Here the criterion has to concede something, or it is not honest: per-user pricing that counts everybody is perfectly reasonable for a CRM whose users really are all employees, which is what most horizontal CRMs were built for. Sthan charges per staff seat — ₹6,999 a month for 1–3 of your own people, ₹14,999 for 4–8, ₹24,999 for 9+ — and brokers, channel partners and buyers are unlimited and free on every plan. So the question to put to any vendor, Sthan included, is not what a seat costs but what counts as one. The full breakdown is on the pricing page.
Frequently asked questions
How should an Indian real-estate developer evaluate CRM software?
Start with your own framework, not the vendor's demo. Decide which criteria matter for how you actually sell — portfolio handling, sales channels, RERA, Indian operational fit, workflow scope, and pricing model are a reasonable six — and weight them for your situation. Then score every option, including the one you are leaning toward, against the same criteria. A product should earn each criterion, not win it because it set the test.
What's the difference between horizontal CRMs and real-estate-specific CRMs for Indian developers?
A horizontal CRM models a generic sales motion and is adapted to real estate with custom fields, so booking, RERA, inventory, broker, and possession workflows must be built on top. A real-estate-specific CRM models the property sale itself. For an Indian developer the gap is widest around the things horizontal tools have no concept of — RERA documents, construction-linked milestones, the portals, and broker payouts — which are exactly where the operational work lives.
Should I choose a CRM built for US brokerages or one built for Indian developers?
It depends on where you operate. Global vertical real-estate CRMs are genuinely strong, but they are built for the US agent-and-brokerage model — no RERA, no construction-linked milestones, no rupee-and-lakh notation, no Indian portals. If you are a US developer, that category fits you and an India-first product like Sthan does not. If you are an Indian developer, a category built for that model will fit your operation far better than a polished product built for a different one.
How important is RERA compliance in CRM evaluation?
For an Indian developer it is close to non-negotiable, because RERA documentation and filings are mandatory and mistakes carry penalties. What to check is whether the CRM generates the documents from your booking data and tracks filings, or merely stores PDFs created elsewhere. One honest caveat: a CRM should generate and organise the documents, not replace legal review — your counsel still owns the final versions, and any product claiming otherwise is overstating what it does.
What pricing model makes sense for a developer running multiple projects?
Look at what the model counts before you look at the rate. A multi-project operation means more projects, more channel partners and many more logins, so a model that bills every login gets expensive fastest — and in Indian real estate most of those logins are brokers and buyers rather than your own staff. A model that prices on projects, or on staff seats only, keeps the bill tied to something you control. Sthan prices on staff seats: the project count never moves the bill, and broker, channel-partner and buyer logins are unlimited and free.
Is per-user pricing or per-project pricing better for Indian developers?
Neither is universally better — and the more useful question is what the vendor counts as a user. Per-user pricing is fine for a stable team when only your own staff hold logins, but Indian developers also give logins to channel partners and buyers, and a per-user CRM bills those too, so the cost of onboarding a partner becomes a reason not to. Per-project pricing sidesteps that by ignoring people entirely. Sthan takes the third route: it counts only your staff, and brokers, channel partners and buyers are unlimited and free on every plan.
How does Sthan compare to other Indian real-estate CRMs?
Within the Indian real-estate category, products differ mainly on the trade between depth and focus. Sthan's structural choices are a single multi-project workspace, published staff-seat pricing that never counts brokers or buyers as users, native WhatsApp with rupee-and-GST operations, and a workflow that runs past the booking into collections and possession. The honest summary is that Sthan trades enterprise depth for an Indian-operations focus; other products in the category make different trades, and a buyer should match the trade to their own scale and operating model.
How long does it take to evaluate and implement a real-estate CRM?
Realistically, evaluation takes two to six weeks — long enough to score a shortlist against your criteria, run a pilot project, and check the workflows that matter against real data. Implementation typically takes four to twelve weeks, depending on how many projects, documents, and integrations are involved. Anyone promising instant, zero-effort go-live is describing a signup, not an implementation; a real rollout means migrating data, configuring projects and templates, and training the team.
These answers focus on the evaluation. To go deeper on the criteria, see the guides on lead-to-possession process automation, marketing automation and drip campaigns, and pricing and ROI. For a worked example of applying this framework to a specific competitor, see Sell.do vs Sthan.
Score Sthan against your own rubric.
If Sthan is one of the options on your list, the fastest way to score it against these six criteria is to see it on your own projects. Book a demo and the team will walk the rubric with you — honestly, including where Sthan is not the right fit. Or email hello@sthan.org.