Building a Nationwide Channel Partner Network
ANAROCK depends heavily on independent channel partners (CPs) to source deals. These relationships were valuable, long-standing — and largely invisible to the system.
Deals closed, but the organisation had limited insight into:
How consistently brokers were engaged.
Where follow-ups broke down.
Which relationships were strengthening or decaying.
As paid lead channels became more expensive and less predictable, this blind spot started to hurt the business.
The goal wasn’t to “manage brokers better.” It was to understand how sourcing actually happens — and design around that reality.
Outcomes
Follow-up gaps surfaced within days, not weeks
Missed or delayed follow-ups were explicitly visible as pending or overdue actions, instead of being discovered only after deals stalled or relationships cooled.
Broker engagement could be assessed at a relationship level.
Managers no longer had to rely on closed deals as the primary signal. Recent activity, follow-up continuity, and engagement frequency provided a live view of relationship momentum.
Weakening relationships became identifiable before outcomes dropped.
Inactive or weakening broker relationships were identifiable before they impacted bookings or revenue, enabling corrective action while outcomes were still recoverable.
Agents spent less effort tracking work mentally.
The app externalised memory — who to follow up with, when, and why — freeing agents to focus on conversations and next actions rather than recall.
Team
Ahmed Raza (PM)
Rahul Yadav (VP)
Bappaditya Basu (CBO)
Industry
PropTech · SaaS · B2B
My Role
Solo Designer
Product Design
UX Strategy
Our starting point was the obvious one.
We explored a CRM-style dashboard approach, iterating through three versions of wireframes:
Broker Lists
Aggregated Activity Views
Performance Summaries
Manager-facing Overviews
On paper, these solutions looked complete. They matched how sourcing should work in theory.
What we learned from the field after speaking with sourcing agents:
Agents don’t operate inside dashboards.
They don’t think in terms of records or structured updates.
Relationships are managed through calls, memory, and informal follow-ups.
“Updating the system” is often deferred — or skipped entirely.
Each new CRM iteration added structure, but reduced alignment with real behaviour.
👆 Early wireframes of CRM-style exploration.
We made a deliberate call to throw away all three CRM-style directions.
Not to simplify them. Not to hide them behind better UX. But, completely remove them.
The key insight was simple but uncomfortable:
Sourcing agents don’t manage brokers.
They manage conversations.
That shifted the UX direction completely.
Instead of asking:
How do we give managers visibility?
We asked:
How do we support the next meaningful interaction in an ongoing relationship?
This pivot moved the system from:
System-centric → CP-centric
Record-driven → Event-driven
Retrospective → Forward-looking
Once the dashboard assumption was gone, the real problem became clear.
Critical sourcing behaviour existed, but:
Follow-ups lived in memory.
Relationship health was inferred too late.
Missed actions had no early warning.
I reduced the system to the smallest set of signals that actually mattered:
Events over records
Capture interactions as they happen, not after the fact.
Follow-ups as first-class actions
Missed follow-ups are leading indicators of relationship decay.
Patterns over profiles
Engagement trends matter more than static broker data.
Mobile-first by default
This work happens in motion, not at desks.
The experience was designed to sit inside existing behaviour rather than replacing it.
Agents could log and act on interactions quickly.
Follow-ups were lightweight and hard to ignore.
Engagement history accumulated naturally over time.
Managers gained visibility without asking agents to constantly report.
Beyond product decisions, several non-negotiable constraints influenced how the app was designed.
These weren’t aesthetic considerations. They were conditions imposed by real-world usage.
Field conditions and cost constraints.
Most sourcing agents operate on:
Low-end Android devices
Smaller screen sizes
Inconsistent hardware performance
This ruled out:
Dense layouts
Small touch targets
Visually complex components
Connectivity and offline behaviour.
Connectivity is unreliable for agents working in the field.
Because follow-ups and events are time-sensitive, the system could not assume constant access.
Offline support wasn’t treated as a feature. It was treated as a baseline requirement.
Critical actions needed to work without network dependency and reconcile safely once connectivity returned.
Accessibility and legibility
The app needed to remain usable while moving, multitasking, or under time pressure.
This led to deliberate accessibility decisions:
WCAG AA (and where possible AAA) colour contrast.
Non-disappearing form labels for clarity.
Larger touch targets (48px minimum) to reduce accidental taps.
Progressive disclosure instead of dense dashboards
Information appears only when needed.
Trade-off:
Less “all-in-one” visibility.
Gain:
Faster comprehension and lower cognitive load.
Automation over manual reporting
Patterns surface automatically rather than through compiled reports.
Trade-off:
Reduced customisation.
Gain:
Consistency, speed, and trust in the signal.
What we deliberately did not build
No heavy CRM workflows
No mandatory data entry
No broker “grading” systems
No predictive scoring without reliable signal
What changed because of the pivot
If the CRM-style solution had shipped:
Adoption would have been shallow
Data would look complete but be misleading
Relationship decay would remain hidden
By abandoning weeks of work and reframing the approach, the product aligned with how sourcing actually operates.
That decision mattered more than any screen.
The hardest part of this project wasn’t execution.
It was accepting that our initial idea of “visibility” didn’t match how sourcing agents actually operate day to day.
The early dashboard approach assumed that agents would pause, review status, and update the system.
In reality, their work is continuous, reactive, and driven by conversations — not by reviewing summaries.
The pivot forced us to stop designing for how sourcing should work and start designing for how it actually works:
Acting in the moment
Remembering who needs a follow-up
Moving quickly between calls, visits, and messages
