Propkee · 2025

Reduced ownership ambiguity by ~80% through role-based governance.

0→1 B2B product for a real estate platform with multiple seller roles — agents, account owners, and admins — each needing different levels of access, control, and visibility.

Project Scope

Designed the end-to-end Propkee product ecosystem across customer-facing and internal experiences.

• Landing page
• Seller Panel
• Account Owner Workspace
• Admin Workspace

While this project spanned multiple products, this case study focuses on the governance system that connected them all.

The Situation

The system didn’t start with structure — it evolved into one.

Propkee initially approached us to design an admin panel — a contained brief with a general sense of the product and a few features to start with.

As clients came onboard, the scope expanded: a Seller Panel MVP covering lead management and analytics, then a much larger requirement — multiple roles, a role matrix, responsibilities that were partially defined but not fully worked out.

The clients had identified the roles. What wasn’t clear yet was how those roles should interact, what each one could and couldn’t do, and how the system should hold together as it scaled. That’s where the real work started.

As the ecosystem scaled, the gaps became visible:

• Ownership wasn’t clearly defined
• Permissions were inconsistent
• Lead and listing control were unclear

This led to operational breakdowns:

• Multiple agents handling the same leads
• Listings without clear ownership
• Confusion around critical actions

Impact

Defined governance for a growing seller ecosystem

Metrics estimated from client-reported coordination overhead before and after the governance model was introduced.

Core Decision

Authority needed to be defined before features scaled

As the system expanded into the Account Owner layer, the clients brought a starting role matrix. But a role list isn’t a governance model — it doesn’t tell you who controls what, where decisions escalate, or how the system stays stable when teams change.

I pushed to start with information architecture before any screens. I used their matrix as a reference, proposed how the roles should interact and what responsibilities should sit at each level, and worked through that structure with stakeholders before any interface decisions were made.

That conversation shaped what the product actually became — some responsibilities were reassigned, billing was scoped out, and compliance was handled separately by the client. The final architecture came out of that process, not directly from the original matrix.

Instead of building isolated flows, I structured a clear hierarchy of control:

• Execution flowed downward
• Control stayed with Account Owners

This shifted the system from flexible access → controlled governance.

Agents were intentionally restricted

• They could operate workflows
• But could not control system-level actions

Sensitive actions — billing, ownership, lead assignment, listing control — were restricted upward.

Permission Model

More flexibility created more risk

The first instinct — mine and the client’s — was maximum granularity: View • Edit • Delete • Assign • Export for every role.

But this led to:

• High cognitive load
• Risk of incorrect setup
• Confusion around access boundaries

More surface control created more room for error and users couldn’t clearly understand what they could or couldn’t do.

We simplified to View / Edit, and embedded real control into:

• Role inheritance
• Ownership logic
• Confirmation layers
• Restricted reassignment

Users saw less, but the system controlled more

Listing Control

Listings were controlled, not freely created

Unlike typical systems:

→ Agents could not directly add listings

Instead, they could:

• Submit listing requests
• Pitch properties through structured forms

Account Owners:

• Owned listings
• Managed inventory
• Controlled visibility

Prevented uncontrolled inventory creation

Publishing followed: Draft → Org Approval → Compliance → Publish

Lead Management

Leads were centralized before distribution

Instead of direct agent ownership the flow went like: Lead → Organization → Assigned Agent

Control sat with the organization

• Account Owners handled assignment and redistribution
• Agents worked only on assigned leads

Agents could:

• View leads
• Update status
• Handle meetings and bookings

Built for team changes

If an agent left:

• Leads reverted automatically to the organization

Team Management

Team control was centralized, not distributed

Account Owner:

• Managed team members
• Defined roles and permissions
• Controlled access levels

Agents:

• Had no control over team structure
• Operated within assigned permissions

Seller Panel

Governance started with the people using it every day.

While administrators governed the platform, agents needed a focused workspace to execute their daily tasks without unnecessary complexity.

The Seller Panel allowed agents to:

• View assigned leads
• Schedule meetings and site visits
• Track bookings and follow-ups
• Submit property listings for approval
• Host Live Property Showcases & Project Launches

Instead of exposing organizational controls, the experience focused on helping agents complete work efficiently while keeping governance intact.

Agents could execute work, but organizational control remained with Account Owners.

Analytics

Two views, two decisions

Analytics wasn’t a single dashboard. The information each role needed to make decisions was different, so the views were designed separately.

Account Owner — Aggregated Analytics

A cross-role operational view: active listings, total leads, lead-to-sale funnel, lead source mix, property type distribution, team performance summary, top performing properties, inactive listing alerts, and an agent leaderboard. Built for someone managing the business, not working individual leads. Every chart is filterable by project and time range — the Account Owner can drill from org-wide trends down to specific assets or agents.

Seller — Property & Spot Analytics

Scoped to the agent’s own listings: total properties, saves, unique leads, spot views, and CTR. A per-property breakdown table shows where leads are coming from (page vs. spot split) so agents can see which listings are performing. No org-wide data — agents see only what’s relevant to their own work.

The split reinforced the governance model: visibility matched authority. Agents got execution-level data. Account Owners got the operational picture.

System Resilience

Designed for change, not stability

The system needed to handle:

• Role changes
• Team restructuring
• Compliance requirements

Built safeguards into the system

The system remained stable even as the organization evolved.

Signing Off!

Key takeaways

This project involved navigating ambiguity, evolving requirements, and defining structure as the system scaled.

This project reinforced my approach: solve for systems first — interfaces follow.