Almost every CRM you'll evaluate is priced the same way: per user, per month. It's the default of the software industry, and on a demo it sounds reasonable — a few hundred to a couple of thousand rupees a head. The problem isn't the number on the slide. It's that real-estate sales teams don't stay one size, and per-user pricing quietly charges you for that.
This isn't an argument that per-user pricing is a scam. For some teams it's genuinely the cheapest option, and we'll say exactly when below. It's an argument for doing the full math before you sign, because the per-seat figure hides more than it shows.
What does per-user pricing actually cost?
Start with real, published numbers. Zoho CRM — one of the most popular choices in India — publishes its pricing at ₹800 per user per month for Standard, ₹1,400 for Professional, and ₹2,400 for Enterprise, with a free tier for up to three users. ↗ HubSpot's Sales Hub, for international context, runs from a $9-per-seat Starter to $150 per seat for Enterprise. ↗ Vendor comparisons of Indian real-estate CRMs commonly put the going rate somewhere in the ₹400 to ₹1,500 per-user-per-month band.
Now put a team on it. Ten people — a sales head, a few closers, a couple of tele-callers, a CP coordinator, a marketing hand — at the low end of that band is ₹5,000 a month, or ₹60,000 a year. At ₹1,500 a head it's ₹15,000 a month, ₹1,80,000 a year. Same team, same software, and a three-times spread depending only on which plan and provider you land on. That's before anyone has added a feature.
The figure that gets quoted on the demo is almost always the per-seat one in isolation — "just ₹1,200 a user." Multiplied by a real team and twelve months, it's a materially different conversation.
What happens when the team flexes?
Here's the part the per-user model handles worst, and it's specific to how property actually sells. Real-estate sales headcount is not flat. It spikes for a launch and contracts after. You bring on closers for a new tower, hire seasonal staff for the festive buying season, add a few tele-callers when a campaign floods the top of the funnel — and then, months later, the team shrinks again.
Under per-user pricing, every one of those temporary people is a permanent-feeling line item while they're on. Add five launch-season closers to that ten-person team and your CRM bill jumps fifty percent overnight — for staff who might be gone in a quarter. Worse, the friction runs the wrong way: at the exact moment you want every closer in the system so no lead leaks during your busiest weeks, the pricing model makes adding them a cost decision. Teams respond by under-licensing — sharing logins, leaving the seasonal hires out of the CRM, working launch leads in a side spreadsheet — which quietly recreates the lead-leakage the CRM was bought to prevent.
The per-user model, in other words, taxes you most precisely when you're growing, and nudges you toward exactly the behaviour that loses leads.
What costs does the per-seat number hide?
The licence is only one line of the real bill. Three more rarely make it onto the comparison slide:
Setup and configuration. A general-purpose CRM has to be shaped into a real-estate tool before it's useful — modules, layouts, stages, document templates. That's either your time or an implementation partner's fee, and it's a real cost the monthly per-seat figure excludes.
Integration. Connecting the portals, your WhatsApp number, your ad accounts, and telephony is often where "it's only ₹1,200 a user" turns into add-on tiers, third-party connectors, or developer time.
Training and adoption. Every seat you pay for only returns value if the person uses it. A complex platform with a steep learning curve means weeks before a tele-caller is productive in it — and seats that sit half-used are pure cost.
Counted honestly, the cost of a per-user CRM is the seats times twelve months, plus setup, plus integration, plus the adoption drag. The headline per-seat number is the smallest of those for many teams.
Is there an alternative to per-user pricing?
The other model prices by what you're actually running — your projects — rather than how many people log in. Sthan, for instance, charges ₹8,000 per active project per month, or ₹25,000 a month flat for unlimited projects and unlimited users, with published figures and no per-user fees. The number doesn't move when you add a launch-season closer, a seasonal tele-caller, or your whole marketing team. A three-person team and a fifteen-person team running the same two projects pay the same.
That flips the incentives the per-user model gets wrong. Because adding a person costs nothing, you put everyone in the system — every closer, every seasonal hire — so no lead works around the CRM during your busiest weeks. The full reasoning, and a like-for-like per-user-versus-per-project breakdown, is in our pricing and ROI transparency guide.
Which pricing model should you choose?
Be honest about your own shape, because per-user genuinely wins for some teams. If you have three or fewer users, Zoho's free tier is hard to beat and you should take it. If your team is tiny and stable — say two or three people who never flex with launches — a low per-seat plan can work out cheaper than any flat fee, and you should run that math rather than assume otherwise.
Per-project pricing starts winning when two things are true: your headcount moves with your launches, and you'd rather every person be in the system than ration logins to control cost. For most developers running active projects with a sales team that grows and shrinks, that's the normal state — and it's the case where the per-user "bargain" slowly becomes the expensive option. The trap isn't that per-user pricing is dishonest. It's that it's quoted as a single small number, and the real bill is that number times a team that doesn't hold still. Do the full math — seats times twelve, plus setup, integration, and the cost of the people you'll add at your busiest — and then decide. For a small fixed team, you might still pick per-user. For a real estate operation that flexes, the model that charges for projects rather than heads usually costs less and fights you less.