In Development
A knowledge base for
multifamily operations
Building a centralised knowledge infrastructure to enable reliable, scalable AI across multifamily workflows.
Duration
12 Weeks
My Role
Product Designer
AI systems design · Information architecture · UX strategy
Methods Used
Stakeholder interviews · AI fallback query analysis · Information architecture · Thematic clustering · Workflow mapping · Human-in-the-loop AI framework design · Iterative wireframing & prototyping
The Ask
As Accolade expanded AI-assisted workflows across leasing, maintenance, payments, and resident communication, automation could not scale without structured, validated operational knowledge.
The Goal
Design a centralised knowledge infrastructure that would power AI with accurate, property-specific responses while maintaining governance and explainability.
The Outcome
A structured Knowledge Base with human-in-the-loop validation and AI retrieval logic, transforming fragmented documentation into a scalable intelligence layer.
300+
Structured knowledge entries powering AI responses across 9 operational domains
35%
Reduction in AI-to-human escalations through confidence-gated responses
30%
Reduction in time spent searching for operational information
What I was working with
Multifamily operations involve continuous communication between prospects, residents, leasing agents, and property managers across domains such as leasing terms, payments, maintenance requests, and community policies.
As digital engagement increased, property teams began adopting AI assistants to respond to inquiries instantly and support operational workflows. These assistants were expected to answer questions ranging from lease conditions and deposit rules to maintenance processes and move-in procedures.
For AI systems to operate effectively in such environments, they require access to structured, validated operational knowledge that reflects both global policies and property-specific variations.
"Research indicates that responding within the first 5 minutes increases the probability of qualifying a lead significantly and contact odds drop precipitously with delays, in some analyses more than 8× after a 5-minute delay."
Where things start to break
Multifamily operations involve continuous communication between prospects, residents, leasing agents, and property managers across domains such as leasing terms, payments, maintenance requests, and community policies. As AI assistants were adopted to respond to inquiries and support workflows, a critical gap emerged.
Critical information is spread across emails, spreadsheets, internal documents, and agent memory, making it difficult for both AI and human teams to retrieve accurate answers quickly.
Many policies are global, but operational details often vary by property, such as pricing, amenities, lease terms, or parking rules.
Without structured knowledge, AI assistants frequently encounter queries that lack clear answers or contain conflicting information.
As new properties, policies, and edge cases emerge, undocumented questions repeatedly surface in conversations with residents and prospects.
Hence, the big question was,
How might we enable AI to deliver accurate, context-aware responses by structuring fragmented operational knowledge
into a scalable, continuously evolving system?
Introducing Knowledge Base
A centralised intelligence layer that structures operational knowledge and powers AI with reliable, property-specific answers at scale.
Unified Knowledge Dashboard
One view across all operational categories
Provides a domain-based view of all operational categories, allowing teams to quickly access leasing, maintenance, payment, and policy information.
Key Design Decision
Organised knowledge by operational frequency rather than internal org hierarchy, to align with real-world query patterns.
Operational Visibility
Intent-Aligned Knowledge Entries
Structured for how questions are actually asked
Every entry includes a structured question, standardised response, property context, and knowledge level (Organisation vs Property-specific).
Key Design Decision
Designed entries as atomic, policy-specific units instead of long-form documentation to improve AI intent matching and reduce ambiguity.
Knowledge Structuring
Proposed Knowledge Queue
Turning fallbacks into future knowledge
Logs unresolved AI queries along with full conversation context and human agent responses for review, so every knowledge gap becomes an opportunity to expand the repository.
Key Design Decision
Built automatic logging of fallback queries to prevent knowledge loss and eliminate repetitive manual escalations.
Knowledge Gap Detection
Validation & Publishing Workflow
Governed publishing with admin control
Admins review, edit, categorise, and publish Proposed Knowledge entries into the repository, ensuring every entry meets accuracy and policy standards before going live.
Key Design Decision
Restricted publishing rights to designated admins to maintain policy integrity and prevent conflicting edits across properties.
Controlled Publishing
PHASE 1 - INFORMATION ARCHITECTURE
How I structured the knowledge
A mixed-method study combining workflow mapping, stakeholder interviews, and system audits uncovered critical gaps in how knowledge is structured, governed, and accessed across multifamily operations. I analysed a mix of help centres, internal knowledge systems, and property management platforms to identify patterns in how information is grouped, retrieved, and maintained.
Three parameters were evaluated across all systems:
Structure
Most platforms organise knowledge through categories, but the strongest systems balance broad domains with clearly scannable subtopics.
Retrievability
Searchability depends on how well content maps to real user questions, not just internal documentation labels.
Governance
Reliable knowledge systems include clear ownership, validation, and update workflows to keep information accurate over time.
Three patterns consistently emerged
Domain Clustering
The most usable systems group information by operational intent rather than by internal team ownership.
Zendesk · Intercom · AppFolio
Question-to-Answer Format
Strongest systems make answers easy to retrieve because content is broken into focused, answerable units rather than long-form documents.
Notion · Confluence · Zendesk
Global vs. Local Context
Several systems revealed the importance of separating organisation-wide rules from location- or case-specific details.
Intercom · AppFolio
The final taxonomy
Structured around high-frequency operational domains and real-world query patterns.
Leasing
Application process
Violations & policies
Lease signing
Early termination
Lease renewals
Move in / out
Payments
Transfers
Maintenance
Basic troubleshooting
Requesting maintenance
Emergency repairs
Collections
Late payments
Payment plans
Notices & legal steps
Waiver requests
Vendors
Approved list
Onboarding process
Work orders
Vendor payments
PHASE 2 - DASHBOARD DESIGN
Deciding how the knowledge can be managed
Structuring the taxonomy felt like the core challenge, until I started thinking forward. Six months after launch, with dozens of properties active and the Proposed Knowledge queue running continuously, the repository would need active management. Policies change. Entries go stale. Coverage gaps form silently. The dashboard was the answer to that problem.
Before designing anything, I mapped the specific problems that would emerge at scale. Two stood out as the most critical to surface through a dashboard view.
Knowledge going stale without anyone noticing
An entry retrieved hundreds of times a month could be months out of date with no one aware. Without visibility into the combination of high retrieval frequency and low recency, an admin has no way of knowing where the risk is concentrated.
Coverage blindness across domains
As the repository grows, thin categories are easy to miss, and they're often the ones generating the most fallback queries. An admin needed to see coverage mapped against actual query demand, not just entry count.
SOME CONCEPTS
Two directions were explored before arriving at the final design. The first prioritised knowledge health and coverage. The second introduced trend lines and activity tracking to show how the repository was evolving over time.
Concept A
Surfaced total entries, entries needing review, and domain coverage side by side. Gave admins a clear view of what existed and where gaps were concentrated.
Concept B
Added activity charts and coverage trend lines. Useful for understanding trajectory, but introduced complexity that wasn't necessary at MVP stage.
Concept A was taken forward for the MVP. The trend view was deferred, valuable once the system has enough history to make trends meaningful, but premature at launch when the primary job is establishing baseline coverage.
The final DASHBOARD
Knowledge Health stats
Total entries, entries needing review (amber), and domains below coverage threshold (red), the three numbers an admin needs to assess system state at a glance.
Flagged entries table
Entries overdue for review, ordered by retrieval frequency. High-use, low-recency entries surface first, the highest-risk state in any knowledge system.
Domain coverage bars
Coverage percentage per domain shown as horizontal bars with entry counts. Immediately reveals which domains are thin relative to query demand.
Proposed Knowledge queue
Count of pending AI-proposed entries awaiting admin review, broken down by domain. Direct link to the review flow keeps the loop visible and actionable.
PHASE 3 — SYSTEM EVOLUTION
Turning fallbacks into future knowledge
When designing the knowledge entry flow, a question surfaced that wasn't immediately obvious: what happens when the AI simply doesn't have an answer? Fallback queries aren't edge cases. They're a recurring signal that something real is missing. Left unaddressed, the knowledge base stays static while resident needs evolve around it. This made the fallback path a first-class design concern, not a graceful degradation, but an active learning mechanism.
When a resident or prospect asks a question, the AI searches the knowledge base for a matching entry. If a match is found, the response is delivered directly. If not, the query is transferred to a human agent who answers it.
From there, the query is automatically logged as a Proposed Knowledge entry, capturing the original question and the agent's response. An admin reviews, edits if needed, and approves it into the repository. The system improves with every gap it encounters.
KEY DESIGN DECISION
The agent's only job is to answer the resident. Logging, structuring, and routing the proposed entry for review happens automatically. Adding to the knowledge base becomes a byproduct of doing the job, not additional work on top of it.
The impact this created
Across four key dimensions, the Knowledge Base strengthened AI reliability, operational speed, and scalability.
82%
AI answer coverage
Increased by enabling structured retrieval from a validated, centralised knowledge taxonomy.
35%
Reduction in AI-to-human escalations
Through confidence-gated responses and continuous validation via the Proposed Knowledge workflow.
30%
Reduction in operational search time
By consolidating fragmented policy documentation into a single structured repository.
300+
Structured knowledge entries
Across multi-domain operational workflows to support scalable AI automation.
Thank you for stopping by!
I’m always learning, evolving and designing with curiosity, so if you have thoughts, feedback or just want to say hi, I’d love to hear from you!
© 2026 Anushka Belsare | Created With Empathy