0→1 Broker CRM for Multi-Step Workflows

Context

Accolade is a New York based PropTech company that wanted to enter India's residential rental market. They came to the project with two assets and one gap. They had a large volume of market data and an existing renter-facing mobile app. What they did not have was a product, a defined user, or a point of view on what to build next.

India's brokerage market is one of the largest in the world and almost entirely undigitized. Over 500,000 brokers operate in it. Most record client data manually and rely on memory to hold deals together.

Role and Contribution

I was the Lead Product Designer on a team of 3 designers. I fully owned the lead prioritization and client profile flows, led the visual direction for the entire CRM, and defined the system architecture: how information flows from the renter app into the CRM. I also supported my teammates while they designed their flows.

The team ran 21 broker interviews, 14 contextual inquiries and two weeks of secondary research to understand how residential real estate brokers operate in India. I did field research and interviews with brokers and analyzed the findings. For the secondary research, I ran the market taxonomy, feature analysis and evaluation of competitor platforms.

There was no product manager on this project, so I defined the zero-to-one product direction, translating research insights into opportunity areas, journey maps, information architecture and core system logic.

AI-integrated workflow: I used Granola to organize interview notes and NotebookLM and Perplexity to support research and synthesis. I regularly revisited raw notes to uncover nuances that summaries might miss. I also built interactive prototypes using Cursor AI, making it easier for non-technical stakeholders to explore and understand the proposed experience.

I translated the high-fidelity end to end designs from Figma canvas to a working prototype for stakeholders and engineering team using Cursor AI and Claude Code.

Hypothesis

Our starting hypothesis was that the fragmentation was a discovery problem: renters and buyers lacked good tools to find property. We began by exploring how discovery could be improved.

Research Revealed That Brokers Were the Operational Center of the System

We interviewed renters, brokers and PropTech professionals, and ran contextual inquiry, ecosystem mapping and competitive benchmarking across 8 platforms. I led the competitive work: market taxonomy, feature analysis and platform evaluation. A different pattern surfaced almost immediately.

The market gap made this worse rather than better. Platforms like MagicBricks and 99acres are built for renters and buyers searching for listings. Nothing existed for the operational work that happens after a lead arrives.

Four Insights defined the project

• Brokers were not struggling with lead generation. They were struggling with lead coordination.
• Client information lived across separate tools, which created repeated conversations and lost context.
• Lead tracking became mentally exhausting at scale because the workflow was memory dependent.
• Existing PropTech tools are optimized for discovery, not for daily operations.

Ecosystem Mapping

Ecosystem mapping made the strategic case clear: brokers are the connective tissue between property owners, renters and platforms. Improving their workflow lifts the entire transaction funnel. They manage listings, site visits, negotiations, paperwork and coordination between owners and renters. All of it runs through WhatsApp, phone calls, spreadsheets and scattered notes.

The AI preference-matching model brokers rejected

Before the pivot we tested a preference matching model with brokers. The idea was to score properties against stated client preferences and surface the best match. Brokers rejected it for three reasons:

• It felt like replacement, not support. Matching scores bypassed the judgment that brokers consider their actual professional value.
• Stated preferences decay fast. Client requirements shift within days of starting a search, so a model built on intake data is stale almost immediately. We needed to track what clients do, not what they said once.
• Onboarding cost was fatal. Brokers in tier 2 and tier 3 cities are time constrained operators. Anything that required 20 minutes of learning would be abandoned.

New Direction

Our hypothesis was wrong and so we pivoted from "How do we match renters to properties faster?" to "How do we help brokers manage leads faster?"

Three things changed as a result:

• Scope: from a preference matching model I shifted to a lead transparency and workflow model.
• Mental model: from "match properties" to "understand clients and manage their changing preferences."
• Product logic: from static intake of data to behavioral signals tracked over time.

System Architecture

Accolade already had a renter-facing mobile app, so I designed the CRM as one half of a two-sided system rather than a standalone tool. The renter app captures preferences, intent and behavioral signals. Those flow into the broker CRM, which organizes them into structured workflows that support the broker's decision rather than making it for them.

The flows I owned: lead prioritization and client profile

Intent is behavioral and explained, not scored. High, Medium and Low intent are derived from observable signals: inquiry submissions, property viewing activity, and whether browsing behavior matches the stated budget. The signals themselves are shown on the card. This was the direct answer to the trust problem that killed the first concept.

The broker stays in control. Accept or Deprioritize, with the broker free to disagree with the system. Lead intent is treated as dynamic and context dependent rather than a fixed property of a person.

Soft deprioritization instead of deletion. Deprioritized leads leave the active view but stay in the system and resurface automatically when engagement behavior changes. Brokers lose nothing by clearing their pipeline, which is what makes them willing to clear it.

Stated preference and observed behavior sit side by side. In the client profile, the left panel holds what the client said they want and the right panel holds what they actually did. The gap between the two is the insight, so the layout makes that gap visible instead of merging the two into one summary.

Flows my teammates owned

My teammates owned how a lead opens, client management, property management and communication management. I supported them while they designed these and kept the visual direction consistent across the CRM.

Status tags carry the navigation load. In the client database, stage tags replace filtering and manual sorting. Preference context sits in the table row so brokers can evaluate without opening a profile.

Matched properties come to the workflow. Property matches surface inside the lead card and client profile rather than requiring a separate search, so brokers open a conversation already holding options.

Prototype designed and coded in Cursor

Brokers were able to complete core tasks reviewing leads, understanding client preferences, and tracking progress with significantly fewer steps.

We tested the MVP with 10 brokers and received positive feedback on how the system simplified their day-to-day workflow. Instead of spending time organizing scattered information across multiple tools, brokers were able to focus more on understanding client needs, managing property searches, and progressing deals more efficiently.

68%

Reduction in lead management steps

~ 6 hrs/week

Estimated reduction in lead-handling effort

30%

Increase in lead prioritization

75%

Reduction in tool-switching

Limitations and reflection

Validation was prototype based with 10 brokers. The next step is testing long term adoption in live environments, where relationship driven behavior and habit are harder to shift than a task based usability test can capture.

The hardest part of this project was designing structure for a market that has almost none. There was no standard workflow to build on and no existing product direction, which meant constant tradeoffs between structure and the flexibility brokers actually rely on.

The biggest takeaway: good product design here was not about adding features. It was about removing chaos. The most valuable thing I did was push the team to reframe the problem once the research contradicted our hypothesis, rather than defend the original scope.

If I continued, I would explore how AI could help brokers read preference patterns and prioritize leads without eroding the human judgment that is the core of their work.