Leticia Sant'Ana
HomeAboutLinkedInSay hi
© 2026 Leticia Sant'Ana · designed and built by meFlorianópolis, Brazil© 2026 Leticia Sant'Ana · Designed and built by me · Floripa 🇧🇷
← Back to home

Product Design · Kenlo web and mobile CRM

Customer inquiriesunification

Kenlo treated every property a client looked at as a separate inquiry, so brokers juggled duplicated cards and fragmented history. I co-led the move to one inquiry per client across web and mobile, a structural change that unblocked the product roadmap.

1inquiry per client, holding multiple properties
~4 moof development and testing
43agencies in the phased rollout (3 pilots, then 40)
CUSTOMER-INQUIRIES-HERO-COMBINED-INSET.PNG
Customer inquiries unification hero visual
RoleMobile App Lead
CompanyKenlo
Year2023
DomainPropTech · CRM

The problem

  • Duplicated inquiry cards for the same client
  • Fragmented history and follow-ups
  • Confusing prioritization in the Kanban view

What I did

  • Co-led the inquiry architecture rethink across platforms
  • Redesigned every touchpoint: properties, visits, proposals, history
  • Owned JIRA stories, app prioritization and timeline alignment

Result

  • Eliminated duplicated inquiries per client
  • Clearer Kanban prioritization and less cognitive load
  • Scalable foundation for proposals, visits and automation

01 · Context

A foundational redesign under heavy technical dependencies.

I co-led the unification of customer inquiries across Kenlo’s web and mobile CRM, consolidating multiple property interests into a single inquiry per client. This foundational redesign reduced lead fragmentation, clarified broker priorities, and enabled scalable growth across platforms—while coordinating a complex, multi-team delivery under heavy technical dependencies.

Role
Mobile App Lead, partnering end-to-end with Product Designer Valdir Primo
Team
Product, Design, Engineering, Data, Backend
Scope
Data migration, cross-product integration, end-to-end journeys
Monitoring
Hotjar (web), Firebase (app), pilot agency feedback loops

02 · The problem

One client, many properties, many inquiry cards.

Brokers often work with the same client across multiple properties. However, Kenlo’s pipeline treated each property as a separate inquiry, creating:

  • Duplicated inquiry cards for the same client
  • Fragmented history and follow-ups
  • Confusing prioritization in the Kanban view
  • Higher cognitive load and missed actions
“Users needed a single source of truth per client, without losing visibility into multiple properties.”

03 · Opportunity

Structural debt that blocked future product growth.

Research conducted in 2022 had already identified inquiry unification as a top priority. The challenge wasn’t just UI: it involved data migration, cross-product integration, reworking end-to-end journeys, and aligning different usage contexts (desktop vs mobile). We needed to redesign the experience without breaking existing workflows users relied on daily.

  • Reduce churn risk caused by operational complexity
  • Improve pipeline clarity for brokers and managers
  • Enable better scalability across web and mobile
  • Support long-term evolution of the Digital Pipeline
Customer inquiries unification: Structural debt that blocked future product growth.
Mapping the inquiry architecture across web and mobile.

04 · Solution

One inquiry per client, holding multiple properties, actions and history.

We restructured the inquiry model so that each client has one inquiry, capable of holding multiple properties, actions, and history.

01

Inquiry cards (Kanban, web)

Property code replaced with property count; new interest triggers a badge; status prioritized by urgency: action required, pending, completed.

02

Search and filters

One result per client, grouped by funnel stage, with property count visible at a glance.

03

Inquiry creation (app and web)

Select or create a client, define intent (rent/sell), source, and properties. Built early to support unification seamlessly.

Customer inquiries unification: One inquiry per client, holding multiple properties, actions and history.
Unified inquiry cards and creation flow.

05 · Complex flows

Every touchpoint the unification touched.

We redesigned all key touchpoints impacted by unification. To reduce risk, we tested primarily on web first, where usage was highest, validating mental models before full rollout.

  • Adding/removing properties
  • Visit scheduling (now multi-property)
  • Proposal creation (property selection per inquiry)
  • Inquiry history (property-tagged actions)
  • Pending actions and prioritization logic
Customer inquiries unification: Every touchpoint the unification touched.
Multi-property visits, proposals and history.
Customer inquiries unification: Every touchpoint the unification touched.
Customer inquiries unification: Every touchpoint the unification touched.
Customer inquiries unification: Every touchpoint the unification touched.

06 · Delivery

A high-risk architectural release, planned as a design task.

This delivery required full alignment across Product, Design, Engineering, Data, and Backend. I helped establish “war room” handoff sessions and took ownership of writing JIRA stories, prioritizing app deliveries during the PO’s absence, and aligning timelines with web teams. Delivery was structured into before, with, and after unification; due to dependencies, it shipped as a single coordinated release.

  • ~4 months of development and testing
  • Phased rollout via TestFlight / Beta: 3 pilot agencies at 15-day intervals, then 40 early-adopter agencies
  • Ongoing monitoring via Hotjar (web), Firebase (app events), and direct feedback loops with pilot agencies
Customer inquiries unification: A high-risk architectural release, planned as a design task.
Delivery plan across before, with and after unification.
Customer inquiries unification: A high-risk architectural release, planned as a design task.

07 · Impact

Unification unlocked product evolution that was previously blocked.

  • Eliminated duplicated inquiries per client
  • Improved Kanban clarity and prioritization
  • Reduced cognitive load for brokers managing multiple properties
  • Established a scalable foundation for proposal flows, visits, and automation initiatives

08 · Takeaways

Structural problems require structural solutions.

  • Structural problems require structural solutions
  • Unification is as much data design as UI
  • Platform differences matter, but the mental model must stay consistent
  • Clear delivery planning is a design skill

On this page

01Context02The problem03Opportunity04Solution05Complex flows06Delivery07Impact08Takeaways
Next case · PropTech · 2023Notifications→

Let's talk

Remote-first · Flexible timezone

← Back to homeleticiasantanaux@gmail.com