Five people looked hard at the “what does Clara know about this property” page — the code behind it, the actual data being stored, and two live screenshots. Here’s what actually matters, pulled together into one plan.
Right now, every fact Clara knows about a property — a pet policy, a late-fee rule, a special someone waived for one tenant — gets saved and displayed exactly the same way. There’s no way to tell “this is a rule for everyone” apart from “this was a favor we did for one person, one time.” That’s a direct miss on the two calls made today: every manager answer has to be sorted into rule-or-one-off before it’s saved, and every concession needs someone to explicitly say whether it’s a one-time exception or a new standing offer. Today, neither question ever gets asked. If a manager tells Clara “we’ll waive the late fee for the Petersons this month,” and that gets folded into the property’s knowledge the way the system works right now, Clara could end up offering that same waiver to the next tenant who calls. Every single reviewer flagged this as the top problem, independently.
1. There’s no rule-vs-one-off distinction anywhere — in the data or on the screen. The underlying storage for a property’s knowledge simply has no field for “does this apply to everyone” versus “this was about one person.” Every reviewer hit this first. It’s not a UI gap you can paper over — it has to be added to how facts are stored, and then enforced the moment a new fact is about to be saved.
2. Concessions have the identical problem, and money makes it worse. Rent specials and waived fees are stored the same flat way — no field for “one-time deal” versus “we’re doing this for everyone now.” A one-off financial favor for one tenant currently looks identical to a real, standing discount that Clara might repeat to every prospect who calls.
3. When something on file turns out to be wrong or outdated, it just gets silently overwritten — nobody is ever told there was a disagreement. If a manager corrects something Clara believed, the old version just quietly disappears. There’s no moment where the system says “hey, this doesn’t match what’s on file — which one is right?” That’s the exact pattern the team’s own research just pointed to as the right way to do this (the industry example cited: a system that flags contradictions instead of picking one silently). Right now we do the opposite.
4. The system already tracks who said what and when — it just throws that information away before showing it to anyone. This was the most surprising finding. The database already stores who taught Clara a fact, which conversation it came from, and whether it was later corrected. But the property page doesn’t display any of that — it shows one flat word like “manual” or “clara” and nothing else. A property manager can’t currently answer “who told Clara this, and when” without opening the database directly, even though the data to answer that question already exists.
5. The one freshness date on the page is misleading. There’s a single “Synced [time]” stamp at the top of the whole knowledge section. It only reflects when the website was last scraped — it has nothing to do with when a policy was last confirmed true, or when a taught fact came in. A manager glancing at “synced 10 minutes ago” would reasonably assume everything on the page is current. It isn’t. A policy sitting a few rows down could be months stale and look identical to something added this morning.
6. Knowledge is scattered across mismatched formats, and has no internal organization as it grows. Some property knowledge lives in a free-text list (policies, pricing, amenities). Other knowledge — renewal rules, turnover rules — lives in separate, differently-styled cards elsewhere on the same page, with no shared visual language. And within the free-text list itself, there’s no grouping by topic (pets, parking, fees, etc.) — it’s just a flat scroll that gets harder to use every time a new fact gets added. One property already has 9 items in that list with no sub-structure.
7. This is the highest-trust part of the page, and today it looks like the least cared-about part of the page. Right above this section, the occupancy and revenue numbers get real visual design — color, hierarchy, polish. The knowledge section, which determines whether Clara sounds right when she’s on the phone with a resident, currently reads like a plain settings form: gray text, tiny badges, no visual weight. That mismatch matters because this section is the one an operator should trust most.
(A related, lower-urgency finding: several reviewers noted that this page currently can only answer “what does one property know” — there’s no way to see or fix a policy across many properties at once. Not urgent with the current small number of live properties, but worth planning for before it becomes painful. More on that below.)
Stage 1 — Build the gate, before anything else grows on top of it. Add the missing field to how facts get stored: is this a standing rule, or is it tied to one specific person/situation? Then make that an actual question, asked at the moment a fact is about to be saved — whether a manager is typing something in directly, or Clara is capturing it automatically from an escalation reply. For concessions, add the parallel question: one-time exception, or policy going forward? Nothing should be able to get saved anymore without answering these two questions. This has to come first, because every day this doesn’t exist, more unclassified facts pile up that will need to be sorted retroactively later.
Stage 2 — Show the receipts. Once facts are properly classified, make what’s already being tracked in the background actually visible: who said it, when, and (for anything Clara learned from a real conversation) a link back to that exchange. Replace the single “synced” stamp with a real date on each individual fact — “confirmed on [date]” — instead of one timestamp pretending to cover everything. Split the display into two clearly separate sections: standing policy (what Clara tells anyone) and exceptions (tied to one person, never repeated to anyone else). This stage is mostly a matter of showing data that already exists — it doesn’t require new backend work, which makes it a relatively fast follow to Stage 1.
Stage 3 — Catch disagreements instead of overwriting them. Add a simple check: when a new fact is being saved, does it plausibly contradict something already on file about the same topic (same subject, different answer)? If so, don’t silently replace the old one — flag both and ask a human to pick: keep the new one, keep the old one, or keep both because they actually apply to different situations. This doesn’t need to be fancy at first — catching obvious same-topic contradictions is enough to close most of the risk.
Stage 4 — Make it look and feel like one coherent page. Bring the renewal/turnover/vendor cards into the same visual family as the rest of the knowledge section — same source-and-freshness treatment throughout, so an operator isn’t guessing which format holds which fact. Group the flat list by topic. Add a short “what’s new since you last looked” summary at the top. Swap technical labels for plain words a property manager would actually use. Give the whole section real visual weight — it should look like the most trustworthy part of the page, because functionally, it is.
Stage 5 — Scale it across properties (later, not now). Once the single-property version above is solid, add a portfolio-level view: one place to see and edit a policy across every property at once, with per-property overrides only shown where they actually differ from the default, plus a dashboard that flags properties whose knowledge has gone stale or drifted out of line with the rest. This isn’t urgent yet with only a couple of properties live, but it gets expensive to retrofit the longer it’s put off, so it’s worth having on the roadmap rather than a surprise later.
One page per property where every single fact — a policy, a price, a note about a resident — shows three things at a glance: what it says, who said it and when (a real trail you can click into, not a one-word tag), and whether it’s a rule for everyone or a favor for one person. Rules and one-off exceptions never sit in the same list — they’re visibly two different lanes. Nothing gets quietly overwritten: if a new answer disagrees with what’s already on file, the page stops and asks a human to settle it, the same way a good coworker would say “hey, that doesn’t match what we told the last tenant.” A property manager should be able to look at this page for ten seconds and know exactly what Clara currently believes, what’s solid policy versus a one-time favor, and what (if anything) is stale and needs a second look — without ever having to open the database.