I'm parked on you

Everything I could decide myself is decided. What's left needs you. Each one has a recommendation from Fable — if you agree, pick it and press Done. "I'm not sure" is a real answer and becomes work for me. You don't need to open the session — pressing Done sends your answer back and it picks up.

122 questions on this

In plain terms. The settings end-state design has 22 open product decisions, each with a recommendation. Which do you accept and which do you overrule?

5 of 22 answered

Tried first, unsuccessfully: Fable 5.1 ran six domain agents over the settings codebase and produced the end-state design with a recommendation per decision (docs.propflowai.co/a/settings-placement-decisions.html, decision register). Each of the 22 is a product, pricing or legal choice only the founders can make; Fable's recommendation is the first option on every card.

1Number topology. Today PHONE_TO_PROPERTY_MAP is an env map and Property.twilioNumbers is absent everywhere; each number is a source PR. Recommendation: one line per building, voice+text together, auto-assigned from a company pool at onboarding; company main line opt-in, never default.

In plain terms. Should every building get its own phone number for calls and texts, or should the company have one main number that asks which building? Today the number-to-building link lives in code, so each new number is an engineering change, and the called number is how Clara knows which building a caller belongs to without asking.

Answered: So this is the whole effort. Maybe you could read about it here. 70690853-5b94-4113-98e2-bf555c46d0b8 So maybe yeah, you might have to ingest a lot of the architecture decisions, but essentially this answer should kind of follow for most is that we haven't figured out the best architectural design because we're going to have hybrids, we're going to have one to many, many to one. We're going to have a lot of different structures for things where we could have one phone number for an organization work for three properties, but then properties four and five have their own number. So like we have to be able to be dynamic. We want to make it clear that it's represented in our settings page. And also the same thing is for calendar, right? So calendar could be like we have a org only calendar outlook, right? Or a calendar that's for several properties but not all or the opposite where it's like all properties have their own calendar. So like things like this, it could be in many forms, not just those two examples, which is why I want to make sure that the settings page is intuitive enough that based off if you're on the property focus on the nav or if you're on like the all properties or like no property selected so you're on the org things like that

2Calendar of record. User.calendarIntegration (types.ts:12726) is written but never read; tours read Property.leasingCalendar (3060). Recommendation: offered personal calendars by default (first-free, round-robin optional), company shared calendars as the scale path; stop writing the unread person-level connection until it is read.

In plain terms. Whose calendar should tours land on: a leasing agent's own connected calendar that they offer to their buildings, or a shared company calendar? Today Clara only reads a calendar connected per building, and the calendar a person connects on their own account is saved but never used.

Answered: So this is the whole effort. Maybe you could read about it here. 70690853-5b94-4113-98e2-bf555c46d0b8 So maybe yeah, you might have to ingest a lot of the architecture decisions, but essentially this answer should kind of follow for most is that we haven't figured out the best architectural design because we're going to have hybrids, we're going to have one to many, many to one. We're going to have a lot of different structures for things where we could have one phone number for an organization work for three properties, but then properties four and five have their own number. So like we have to be able to be dynamic. We want to make it clear that it's represented in our settings page. And also the same thing is for calendar, right? So calendar could be like we have a org only calendar outlook, right? Or a calendar that's for several properties but not all or the opposite where it's like all properties have their own calendar. So like things like this, it could be in many forms, not just those two examples, which is why I want to make sure that the settings page is intuitive enough that based off if you're on the property focus on the nav or if you're on like the all properties or like no property selected so you're on the org things like that
Gera's own words from question 1 (phone numbers), which he asked to apply to the shape questions and confirmed in chat 2026-09-08 ('close out the decision questions for those that have already been answered'). Recorded by session settings; no option was picked on his behalf.

3Sending domain. sendGridSenderIdentity is script-only per property; no domain verification UI. Recommendation: customer domain with a verified-status chip, clara@<customer>.propflowai.co as the zero-setup fallback.

In plain terms. Should Clara's emails come from the customer's own domain, or from a PropFlow address? Today every customer's email goes out as clara@propflowai.co, so residents see PropFlow rather than their landlord.

Answered: So this is the whole effort. Maybe you could read about it here. 70690853-5b94-4113-98e2-bf555c46d0b8 So maybe yeah, you might have to ingest a lot of the architecture decisions, but essentially this answer should kind of follow for most is that we haven't figured out the best architectural design because we're going to have hybrids, we're going to have one to many, many to one. We're going to have a lot of different structures for things where we could have one phone number for an organization work for three properties, but then properties four and five have their own number. So like we have to be able to be dynamic. We want to make it clear that it's represented in our settings page. And also the same thing is for calendar, right? So calendar could be like we have a org only calendar outlook, right? Or a calendar that's for several properties but not all or the opposite where it's like all properties have their own calendar. So like things like this, it could be in many forms, not just those two examples, which is why I want to make sure that the settings page is intuitive enough that based off if you're on the property focus on the nav or if you're on like the all properties or like no property selected so you're on the org things like that
Gera's own words from question 1 (phone numbers), which he asked to apply to the shape questions and confirmed in chat 2026-09-08 ('close out the decision questions for those that have already been answered'). Recorded by session settings; no option was picked on his behalf.

4Platform spend ceiling. Today one spend field lives in maintenancePolicy with no platform cap. Recommendation: $5,000/job platform ceiling; autonomous dispatch above $1,500 requires the org cap raised by an org admin; under the ceiling 'Act with approval' auto-accepts quotes, otherwise the ceiling means nothing.

In plain terms. What is the most a customer may let Clara spend on a repair without a person approving it? The page proposes a hard platform limit of $5,000 per job, and that anything above $1,500 needs a company admin to raise the cap rather than a property manager.
Fable recommends: $5,000 platform limit; above $1,500 needs a company admin
A ceiling protects every customer from a runaway approval, and putting the raise with an admin keeps a single PM from lifting it alone.

5What Off means. capabilityStage.off currently equals shadow suppression (silence). Recommendation: park to a named human; for collections, onboarding forces a choice and an Off building shows a persistent banner. Must change before Off is offered in the UI.

In plain terms. When a building turns Clara off for something like collections, should Clara go silent, or hand the work to a named person? Today off means silence: nothing happens and nobody is told.
Fable recommends: Hand it to a named person, never silence
Silent off means rent goes uncollected and no one knows; parking to a person keeps a human in the loop.

6Company cap vs building already above it. Recommendation: cap wins, building clamps, badge reads 'Clamped by company cap on <date>', no grandfathering.

In plain terms. If a company lowers its spending cap and a building is already set above it, should the building be pulled down to the new cap, or keep its old value? The page recommends the cap wins and the building shows a note saying when it was clamped.
Fable recommends: The company cap wins; the building is clamped and labelled
A cap that does not apply to existing buildings is not a cap; the label tells the PM why the number changed.

7What the plan gates. Recommendation: modules, channels, languages only. Autonomy, compliance and the contact ceiling are never plan-gated.

In plain terms. Which settings should depend on the customer's plan? The page says only modules, channels and languages, and never autonomy, compliance, or the contact limits.
Fable recommends: Only modules, channels and languages
Safety and compliance are not upsells; a customer on a cheaper plan must still be protected.

8Seats. subscription.unitCount exists; no seat concept. Recommendation: none — unlimited users, pay per unit.

In plain terms. Should customers pay per user seat, or only per unit with unlimited users? Today billing already counts units and there is no seat concept anywhere.
Fable recommends: Per unit, unlimited users
Adding people to PropFlow should never be a cost decision; more users means Clara gets more hand-offs answered.

9Published rental criteria. Screening criteria have no home today. Recommendation: yes, one sentence verbatim from the company criteria sheet; never 'you would/wouldn't qualify'; the transfer stays for 'would I qualify?'.

In plain terms. May Clara tell a prospect the published rental criteria, like the income requirement, when asked? The page says yes, one sentence verbatim from the company's criteria sheet, and never a judgement about whether that person would qualify.
Fable recommends: Yes, one verbatim sentence, never a judgement about the person
Prospects ask this on every call; stating public criteria is information, judging the person is fair-housing risk.

10Renewal negotiation floor. Recommendation: company-level, default 0% (today's behaviour), never above the minimum increase; everything outside the floor and the offered terms still escalates.

In plain terms. Should companies be able to set a floor below which Clara may negotiate a renewal increase on her own? The page proposes a company-level floor, default zero, which is what happens today, so nothing changes until a company opts in.
Fable recommends: Yes, a company-level floor, default zero
Default zero keeps today's behaviour; a company that wants Clara to close small gaps can turn it on.

11Payment plans. Recommendation: never as the default even after the field exists; ship 'propose only, PM approves' greyed until counsel signs off per state.

In plain terms. Should Clara ever offer a resident a payment plan on her own? The page says never by default, and to ship the option greyed out until a lawyer signs off state by state, so that Clara can propose one for a PM to approve.
Fable recommends: Never on her own; propose for PM approval once lawyers sign off
Payment terms are a legal act in most states; propose-and-approve gets the benefit without the exposure.

12Autonomous for collections. Today Colorado only, California declined, counsel sign-off skipped. Recommendation: never for a customer; Admin unlock per state after counsel sign-off; customer sees the rung greyed with 'Requires PropFlow legal review for <state>'.

In plain terms. Should a customer ever be able to let Clara chase rent fully on her own, with no person reviewing? The page says no: PropFlow unlocks it per state after legal review, and the customer sees it greyed with a note saying why.
Fable recommends: No; PropFlow unlocks it per state after legal review
Collections law differs by state and the penalty lands on the customer; the unlock has to follow a lawyer, not a toggle.

13Who owns staff assignment. Recommendation: Org › Team owns who works where (assignedPropertyIds); the building's People card chooses primary/escalation owner here and adds non-staff rows (crew, owner, counsel).

In plain terms. Who decides which staff work on which building: the company Team page, or each building's own People card? The page recommends the Team page owns the assignment and the building card only picks who is primary or escalation owner among those people.

Answered: So this is the whole effort. Maybe you could read about it here. 70690853-5b94-4113-98e2-bf555c46d0b8 So maybe yeah, you might have to ingest a lot of the architecture decisions, but essentially this answer should kind of follow for most is that we haven't figured out the best architectural design because we're going to have hybrids, we're going to have one to many, many to one. We're going to have a lot of different structures for things where we could have one phone number for an organization work for three properties, but then properties four and five have their own number. So like we have to be able to be dynamic. We want to make it clear that it's represented in our settings page. And also the same thing is for calendar, right? So calendar could be like we have a org only calendar outlook, right? Or a calendar that's for several properties but not all or the opposite where it's like all properties have their own calendar. So like things like this, it could be in many forms, not just those two examples, which is why I want to make sure that the settings page is intuitive enough that based off if you're on the property focus on the nav or if you're on like the all properties or like no property selected so you're on the org things like that
Gera's own words from question 1 (phone numbers), which he asked to apply to the shape questions and confirmed in chat 2026-09-08 ('close out the decision questions for those that have already been answered'). Recorded by session settings; no option was picked on his behalf.

14Maintenance tech: login or crew. Recommendation: crew = in-house vendor membership (no login, gets SMS); a tech who needs the app = staff role. The People card accepts either; the resolver reads the phone off the person.

In plain terms. Is an in-house maintenance tech a PropFlow login, or a crew member who just gets texts? The page says both are allowed: a crew member is an in-house vendor with no login, and a tech who needs the app is a staff role.
Fable recommends: Either: crew gets texts with no login; app users get a staff role
Most techs only need the text; forcing a login on them adds accounts nobody uses.

15The escalation ladder. Today nag constants are 3 tries / 24h and stuck matters go to PropFlow Slack; silent when no escalation owner. Recommendation: company knob with bounds (4–72h, 1–5 tries) → regional manager → org admin → PropFlow Slack only when no customer role resolves.

In plain terms. When nobody answers Clara's question about a stuck job, how often should she ask again, when should she move up to a manager, and when should PropFlow's own team be paged? The page proposes a company setting within bounds: ask again every 4 to 72 hours, stop after 1 to 5 tries, then the regional manager, then the company admin, and PropFlow only when no customer role exists.
Fable recommends: Company sets the cadence within bounds; PropFlow is the last rung only
Today's fixed 3 tries every 24 hours then PropFlow Slack means customers' stuck jobs land on our staff; the ladder keeps it inside their company.

16Expired vendor insurance. No COI/license fields exist today. Recommendation: 'Warn' platform default; 'block except emergencies' selectable at company level.

In plain terms. When a vendor's insurance has expired, should Clara warn and still dispatch, or refuse to dispatch except for emergencies? The page recommends warn as the default, with block available at company level.
Fable recommends: Warn by default; companies may choose to block
At onboarding nobody has certificates on file yet; blocking by default would strand every job on day one.

17Vendors not in AppFolio. Recommendation: allow a PropFlow-only vendor row the sync later links.

In plain terms. Can a company add a vendor in PropFlow that does not exist in their property-management system? The page says yes, as a PropFlow-only vendor that a later sync can link, since otherwise customers on Yardi or Buildium have no vendor list at all.
Fable recommends: Yes, PropFlow-only vendors that a later sync links
AppFolio is the only system we sync vendors from; every other customer needs a way to add one.

18Quiet-hours narrowing per building. Recommendation: yes, narrower only — the one compliance override a building gets. One quiet hours, on the building's clock, stays settled.

In plain terms. May a building set stricter quiet hours than its company, for example no texts after 7pm instead of 9pm? The page says yes, narrower only, never wider, and this is the one compliance setting a building may override.
Fable recommends: Yes, narrower only
A building can be more careful than its company without risk; wider hours could break the law the company setting exists to follow.

19Retention floors. Recommendation: conversations 7y, consent/opt-out ≥4y as coded, audit 7y; the DPA cites the registry, not the reverse.

In plain terms. How long must PropFlow keep conversations, consent records and audit logs before they may be deleted? The page proposes 7 years for conversations and audit, and at least 4 years for consent and opt-out records, which is what the code does today.
Fable recommends: 7 years conversations and audit, 4 years consent and opt-out
These match the statutes the texting rules cite; company-chosen retention would let one customer delete evidence another law requires.

20Voice as its own capability. Recommendation: yes, separate from texting.

In plain terms. Should phone calls be a separate on-off capability from texting? The page says yes: a customer who lets Clara text but not take calls is a real profile.
Fable recommends: Yes, calls and texts are separate switches
Several customers want texting first and calls later; one switch forces both or neither.

21Tone. Recommendation: three-variant evaluated select (warm/professional/firm), shipped greyed until the variants are graded; never a free-text persona field (persona is code).

In plain terms. Should companies be able to change Clara's tone? The page proposes a three-way choice, warm, professional or firm, shipped greyed out until each variant has been tested, and never a free-text personality box.
Fable recommends: Three tested variants, greyed until each is tested
Free text lets a customer rewrite Clara into something we never tested; three graded variants stay inside what we can stand behind.

22A level between company and building. Recommendation: no. Region = permission scope (assigned properties); a PMS account = an integrations binding. Build a bulk-apply gesture on Property Settings instead.

In plain terms. Should there be a settings level between the company and the building, such as a region or a portfolio? The page says no: region is a permission scope, and the way to set many buildings at once is a bulk-apply action on the property settings page.

Answered: So this is the whole effort. Maybe you could read about it here. 70690853-5b94-4113-98e2-bf555c46d0b8 So maybe yeah, you might have to ingest a lot of the architecture decisions, but essentially this answer should kind of follow for most is that we haven't figured out the best architectural design because we're going to have hybrids, we're going to have one to many, many to one. We're going to have a lot of different structures for things where we could have one phone number for an organization work for three properties, but then properties four and five have their own number. So like we have to be able to be dynamic. We want to make it clear that it's represented in our settings page. And also the same thing is for calendar, right? So calendar could be like we have a org only calendar outlook, right? Or a calendar that's for several properties but not all or the opposite where it's like all properties have their own calendar. So like things like this, it could be in many forms, not just those two examples, which is why I want to make sure that the settings page is intuitive enough that based off if you're on the property focus on the nav or if you're on like the all properties or like no property selected so you're on the org things like that
Gera's own words from question 1 (phone numbers), which he asked to apply to the shape questions and confirmed in chat 2026-09-08 ('close out the decision questions for those that have already been answered'). Recorded by session settings; no option was picked on his behalf.

cc498ef8 is parked on this.

Pick an option above, then press Done.
PropFlow Docs