Back
Delivered
Workflow Optimization
0 - 1 Flow
MVP Design
Designing a broker CRM where there wasn't one to Structure India’s Fragmented Real Estate Workflows
Accolode is a New York-based PropTech company who wanted to build a real-estate system for India's $265B fragmented real estate market. There was no product, no data, and no blueprint. Over 8 weeks I led the design of a broker CRM from zero. From research across 8 competitors and 34 interviews to a shipped system that reduced lead-management complexity by 68% and saved brokers ~6 hours a week.
-68%
Reduced Lead-management workflow complexity
~6 hrs
Saved per broker per week on triage and follow-up
34
User interviewed
1
Major Pivot
My Role in the Team
Research, systems design, IA, all high-fidelity screens, the pivot decision, usability testing.
I owned the design end-to-end within a cross-functional team of 4 designers and 3 stakeholders
Company
Deal Meridian (Name changed to Accolode) , New York, USA
Timeline
From blank slate to shipped MVP. One full pivot at week 4 — we threw away the original direction and rebuilt from a new problem framing.
THE BRIEF
A $265B Market Running on Fragmented Workflows, WhatsApp and memory
India's urban real estate market is one of the largest in the world — and almost entirely unstructured. Property search, leasing, and client communication happen across offline channels, informal relationships, and a patchwork of disconnected tools. While platforms like MagicBricks and 99acres handle discovery, nobody had built the operational layer that sits behind it: the broker's workflow.
Accolode wanted to change that. The brief was to design a product for the Indian brokerage market. No existing product, no user data, no understanding of how brokers actually work. We started from scratch.
500K+ brokers, almost none of them digitised
India's real estate brokerage network is one of the largest in the world. Most agents record data manually, rely on memory, and have no structured system for managing clients or leads.
No end-to-end CRM exists for brokers
Existing tools (MagicBricks, 99acres) are built for renters and buyers. No platform integrates into how brokers actually work — matching clients, tracking conversations, closing deals.
RESEARCH INSIGHTS
What user interviews with renter, broker actually taught us.
Through these user interviews, we discovered that brokers sit at the center of this unorganized ecosystem they act as a connectors between property owners, renters, and platforms yet lack the digital tools to manage their workflows efficiently. This insight helped us focus our solution on streamlining and structuring broker operations, with the belief that empowering brokers can uplift the entire real estate interaction funnel.
80% of property seekers don’t trust listings on the internet
6 out 10 property seekers preferences evolve during search
99% property seekers consult with multiple brokers
PROBLEM SPACE
Inefficiency in broker's workflows are the root cause of rental and ownership friction, they manage the real estate journey without a proper system.
Brokers handle everything from matching renters to properties, coordinating visits, to closing deals. But they manage this using calls, WhatsApp, and memory, with no structured system.
This leads to missed leads, repeated work, and poor tracking across the entire journey, so instead of building another discovery tool, we focused on fixing broker workflows.
Three findings came back from every single interview:
Any system that outputs a "match" without showing the reasoning is immediately questioned. Trust comes from seeing why — not just what.
A client says ₹80K budget. Three weeks later they're looking at ₹1.2L properties. Static preference data is wrong data. The system needs to track behavior, not just declarations.
Local knowledge, relationship history, gut feel about a client. No algorithm encodes this. Any system that routes around the broker's judgment will be rejected.
These three insights became the design guardrails for everything that followed. They're also what killed our first approach.
INITIAL DIRECTION
We started with automation. It was the wrong instinct.
The first hypothesis was obvious: automate property matching using preference scores. If we surface the right properties at the right time, brokers close deals faster. Simple, clean, and completely wrong for this context.
We tested rough concepts with brokers. The rejection was immediate and unanimous. Three problems made it untenable:
Rejected
Instead
Decision support, not decision replacement
Rejected
Instead
Behavioral signals over time, not static snapshots
Rejected
Instead
Familiar patterns - tables, search, status tags, things they already understand
PIVOT
The hardest call: reframe the problem entirely.
At week 4, after testing our automation approach, I argued for a full pivot. The renter-facing preference app which had been our original scope was deprioritized. The broker CRM became the core product. We threw away two weeks of work and rebuilt from a different premise.
The reframe was simple, but it changed everything we designed:
Right Question
"How do we help brokers make better decisions, faster?"
Leads to decision support, signal surfacing, human-in-the-loop. Keeps the broker in control.
Three things changed with re-framing
Scope: Renter app deprioritized. Broker CRM became the core product.
Mental model: Moved from "match properties" to "understand clients."
Product logic: Moved from static preference data to behavioral signals tracked over time.
The core principle we held from this point:
The goal is not to automate decisions, it's to make good decisions easier.
DESIGN PRINCIPLES
Four guardrails that governed every decision.
After the pivot, we defined four principles. Every screen decision was checked against them. If a feature violated any of them, it didn't ship.
Surface behavior, not just static data
Show how users act over time and not just what they said when they signed up. A client who viewed 12 properties in 2 days tells you more than their stated budget.
02
Reduce cognitive load in decision-making
Brokers are context-switching constantly. Prioritize clarity and quick understanding over feature richness. If you need to explain it, simplify it.
03
Support broker judgment , don't replace it
Enable better decisions instead of automating them out of the process. The broker's local knowledge and relationship history are features, not bugs.
04
Build trust through transparency
Make data and interactions visible and interpretable. A broker won't use a system they can't interrogate. Show sources. Show reasoning.
SYSTEM OVERVIEW
A two-sided system: one for renters, one for brokers.
The final architecture is two-sided. The renter-facing mobile app captures preferences and behavioral signals. Those signals flow into the broker CRM, which organizes them and surfaces them in a way that supports broker judgment and not replace them.
DESIGNS SCREENS
Dashboard
The dashboard had one job: give a broker everything they need to start their day without making them drill into five different sections. The design decision was to treat it as a launchpad, not a report.
Pipeline at a glance
Four KPI tiles — New Leads, Qualified Leads, Scheduled Visits, Negotiation Stage, give the broker their full pipeline number before they do anything else. No drilling required. The data is there when they open the app.
Source-aware lead acquisition chart
The lead chart breaks down acquisition by source (ShiftHona, MagicBricks, 99acres). Knowing that leads came in is useful. Knowing which channel produced them is actionable. Brokers can double down on what's working.
Action-first design "View New Leads" is the primary CTA
The most important thing a broker does every morning is check new leads. We put that one click away, at the top of the page. The dashboard is not a report — it's a launchpad
Client Database — a flat list becomes a prioritized action queue.
The key design decision on the Client Database was the status-tagged view. Rather than a flat alphabetical list, each client has a status - Active Lead, Awaiting Action, Completed, visible at a glance. The table is not a contact book. It's a work queue.
Status tags as the primary navigation signal
Active Lead, Awaiting Action, Completed. One column tells the broker exactly where to focus without filtering or sorting. The most important clients surface first.
Full preference context in the table row
Property type, preferred location, budget range — visible directly in the list. Brokers don't need to click into a profile to remember who a client is.
Client Profile — single source of truth for every client relationship.
The profile is where brokers manage one client completely. The design challenge was putting preferences, tasks, documents, property matches, and activity history in one place without overwhelming a broker who has 20+ active clients.
Preference + behavioral history on the same page
The left panel shows static preferences (what the client said they want). The right panel shows what actually happened — the activity log. A broker can see in 10 seconds whether a client's behavior matches their stated preferences.
Tasks with clear ownership
Every client has a task list attached to their profile — "Schedule property tour for 123 Maple Street," "Share mortgage pre-approval options." The next action is always visible, not buried in a calendar or WhatsApp thread.
Matched properties surfaced from preference data
Properties matching the client's stated and behavioral preferences appear directly on the profile. The broker doesn't search for matches — the system surfaces them.
Smart Leads — the hardest problem, and the most important screen.
When a broker has 20 active leads, how do they decide who to call first? This was the problem that conventional CRM tools hadn't solved. We built Smart Leads as a decision layer on top of the client database — prioritizing leads by behavioral intent, not by a hidden score.
Intent is behavioral, not scored
High, Medium, and Low intent are derived from observable actions — inquiry form filled, number of properties viewed, consistency of stated budget with browsing behavior — not from a black-box algorithm. The reasoning is always visible.
Broker stays in control: Accept or Deprioritise
The broker can Accept (add to active pipeline) or Deprioritise a lead. Deprioritising doesn't delete the lead — it removes them from the active view and resurfaces them automatically if their behavior changes. Intent is moment-in-time, not permanent.
Preference pattern and behavioral signals shown together
Every lead card shows the full preference pattern budget, location, property type, timeline alongside the behavioral signals that produced the intent classification. The broker can disagree with the system's suggestion. And they should be able to.
Matched properties surface automatically
Properties matching each lead's preference pattern appear at the bottom of the lead card. The broker's first conversation with a high-intent lead starts informed, not from scratch.
Messages — one inbox, zero context switching.
The Messages screen had one job: eliminate the #1 friction point brokers described in every interview. They were managing client conversations across WhatsApp, phone calls, and SMS with no unified view — and losing track of conversations constantly.
All client conversations in one searchable inbox
Every client thread in one place. Searchable and filterable. The broker doesn't switch to WhatsApp, check missed calls, and then look at email. One place.
Presence indicator know when to reach out
The online status tells brokers not just who to reach out to, but when. A client who is online right now is more likely to respond than one who was last active 3 days ago.
Recency timestamps surface cold leads
The message list is sorted by recency. A client with no contact for 15+ minutes bubbles to the top. No leads fall through the cracks due to simple forgetting.
Impact of the first design role out and user testing
Brokers were able to complete core tasks reviewing leads, understanding client preferences, and tracking progress with significantly fewer steps.
Brokers were able to evaluate leads 2–3X faster during testing → ~60–70% reduction in back-and-forth clarification questions before initial contact
Reduced tool-switching from 3–4 tools to 1 unified system → ~50–60% reduction in context switching during core tasks.
Improved visibility into client preferences and interaction history
DESIGN DECISIONS
What we chose not to build — and why that mattered.
Knowing what to cut is as important as knowing what to ship. These four decisions shaped the product's adoption.
Skipped
Instead
Smart Leads with visible reasoning and broker override
Skipped
Complex onboarding flow
Brokers in tier 2/3 cities won't invest 20 minutes learning a new tool. Adoption requires zero learning curve at the start.
Instead
Familiar Patterns like table view, search, status tags , things they already understand
Skipped
Instead
Daily refresh with clear behavioral signal explanation
Skipped
Instead
Soft deprioritization its removed from active view, retained in system
Impact : What shipped, what changed, what I'd do differently.
-68%
Reduced Lead-management workflow complexity
~6 hrs
Saved per broker per week on triage and follow-up
2–3×
Faster lead evaluation during usability testing
-50%
Context switching from 3–4 tools to 1 unified system
What I did do differently
Test the pivot direction with real brokers before committing to rebuilding. We validated after rebuilding, not before. It worked out but a 2-hour interview at week 3 could have confirmed the new direction before we threw away a week of work.
Copyright ©2026. All right reserved Ananya Vashist
