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. The economics of running several projects on one system are worked through in the pricing and ROI guide.
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." The honest limit: in v1 the portal feeds are a daily CSV import rather than a live API — full portal APIs land in v2 — so a developer running very high portal volume should weigh that timing. 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 that does not penalise the way a real-estate sales team actually scales. Priced by project, or as a flat bundle, so that adding reps for a launch, or brokers to a channel, does not multiply the monthly bill.
The poor version is per-user pricing for a team whose size is not stable. The bill rises with every login added, which means the CRM costs the most at exactly the moment a launch pushes headcount and ad spend to their peak — the software taxes the busiest month.
This matters in India because developer sales teams scale sharply and seasonally. A team of eight in a quiet quarter can be twenty-four for an October launch and back to eight after, and per-seat pricing turns that flexibility into a cost.
Here the criterion has to concede something, or it is not honest: per-user pricing is perfectly reasonable for a stable, single-project team that is not adding seats. It is a fair answer to one operating model. Sthan prices per project — from ₹8,000 — or as a flat ₹25,000 bundle for unlimited projects, which fits the scaling-and-seasonal model better than the stable-small one. Which is right depends on which describes you. 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?
Once you are past three or four active projects, a flat or per-project model almost always beats per-user, because a multi-project operation means more reps, more brokers, and more logins — all of which per-seat pricing charges for. A flat bundle makes the cost predictable regardless of how many people touch the system. For a single project with a small, stable team, the difference is minor; it grows with every project and every launch hire.
Is per-user pricing or per-project pricing better for Indian developers?
Neither is universally better — they answer different operating models. Per-user pricing is fine for a stable single-project team that is not adding seats. Per-project or bundle pricing is better when you are scaling projects or scaling seasonally, because it does not tax you for hiring during a launch. Indian developer teams tend toward the second pattern, which is why per-project and flat-bundle models suit them; a builder whose team genuinely never changes size may find per-user perfectly economical.
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, per-project and flat-bundle pricing rather than per-user, 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.