Tenant view
Search → listing → conversation → application → identity/payment → booking → move-in → help/protection.
Reduce uncertainty without making the tenant understand the company’s internal tools.
04 / Blueprint
Three audiences.
One operational truth.
A generic rental-marketplace systems exercise: tenant experience, landlord experience and the operating system the company uses to keep both true.
Independent design exercise. Not a description of any employer’s internal systems.
Three audiences. One booking ID. Assist never moves money.
01 / Three audiences. Shared state.
Three audiences. Shared state.
Landlord view
Onboarding → listing → availability → demand → application decision → booking → payout → portfolio health.
Supply needs speed without sacrificing identity, booking integrity or money controls.
Staff view
Tenant + landlord + booking + money + risk + ticket. Add a named owner, SLA, last customer-visible response and audit trail.
The internal operating surface is a third product, not the public product with admin flags.
02 / One object. One owner.
One object. One owner.
One object. One owner. One system of record. Everything else is a view or a satellite.
In this design, ownership means responsibility for meaning, allowed changes and correction—not unrestricted access.
Objects of record · one possible owner mapping
| Object | Meaning | Typical owner |
|---|---|---|
| Person | Tenant or landlord identity | Trust / Identity |
| Account | Managed landlord organisation | Account Management |
| Listing | Property and availability | Supply / AM |
| Conversation | Marketplace communication | Marketplace |
| Application | Intent to rent | Booking Operations |
| Booking | Accepted stay | Booking Operations |
| Payment Hold | Funds secured before release | Finance |
| Payout | Settlement to landlord | Finance |
| Ticket | Exception outside the happy path | Customer Care |
| Risk Case | Identity / integrity / fraud review | Trust & Safety |
| Campaign | Acquisition / lifecycle experiment | Marketing |
| Event | Record of a committed change | Producing domain owner |
03 / A booking is a sequence of commitments.
A booking is a sequence of commitments.
A timeout is not proof of payment failure. Provider callbacks need verification, deduplication and reconciliation. An exception keeps its booking reference; it does not create another booking.
04 / Attach the organisation to the same truth.
Attach the organisation to the same truth.
CRM owns pipeline. Admin owns platform state. Tickets own exceptions. Internal chat owns coordination. Email owns delivery. None of them gets to invent a second Booking.
“Admin” here means a permissioned interface to the platform—not a separate database or an unrestricted write path. Knowledge, analytics, identity/SSO and telemetry are shared capabilities.
Organisational responsibilities · illustrative boundaries
| Team | Marketplace job | Primary view |
|---|---|---|
| C-level / Leadership | Capacity, economics, marketplace health, risk | BI / aggregates |
| Marketing | Acquisition, attribution, lifecycle | Campaign + Person events |
| Sales / Supply Acquisition | New landlords and supply | CRM lead / Account |
| Account Management | Live landlord portfolio | Account + Listing |
| Booking Operations | Applications, state and exceptions | Staff OS |
| Customer Care | Help, move-in and post-booking issues | Ticket + Booking |
| Trust & Safety | KYC/KYB, fraud, listing integrity | Risk + Person / Listing |
| Finance Operations | Holds, payouts, reconciliation | Money state |
| Platform / Internal Ops | Workflows, contracts, internal UX, assist | Staff OS |
05 / Channels are arrival points, not records.
Channels are arrival points, not records.
Prefer the in-platform thread for tenant–landlord booking context. Overflow phone, email or hypothetical WhatsApp interactions must attach to Person / Booking. Before a booking exists, use Person / Listing / Application instead.
Phone interactions need identity confirmation before sensitive action. A chatbot can retrieve and cite knowledge or create a ticket; it cannot confirm a booking or release money. Internal chat coordinates work and links to the recorded decision.
06 / Staff need a product too.
Staff need a product too.
A staff user should not need six tools open to answer one customer correctly.
Show the current state, its source, freshness and permitted next action together. Sensitive documents and elevated controls appear only to the appropriate role.
07 / Separate capability from authority.
Separate capability from authority.
Edge + identity
DDoS and bot defence; abuse limits. Separate tenant, landlord and staff roles. Staff SSO and MFA; no shared admin account.
Authorization
Least privilege and explicit scopes. Elevated actions require stronger authority. Assist/classification has no direct payment-write permission.
Data classes
Separate public listings, PII, identity documents, payment tokens / financial state and staff-only notes. Access and retention follow purpose.
Money boundary
A bounded service checks an authorized instruction before payout or refund. The model cannot grant that authority.
Audit
Every material action records actor, before/after state, reason and timestamp. Preserve evidence of retries and correction.
Vendor boundary
CRM, tickets, mail and chatbot receive identifiers, events and bounded views—not independent transactional truth.
08 / Same objects. Different questions.
Same objects. Different questions.
Marketing, Operations, Finance and leadership consume a governed metrics layer. Define what “confirmed” means, how late or corrected events are handled, and which owner can change that definition.
Example measures · design choices, not historical results
| Audience | Questions made measurable |
|---|---|
| Leadership | Confirmed bookings; time-to-book; availability; conversion; tickets per booking; loss; hold-to-payout cycle; acquisition cost per booking; retention; unit economics / take-rate |
| Marketing | Source → application → confirmed booking; CAC by market; lifecycle drop-off; campaign quality; retention / reactivation |
| Sales | Leads → qualified leads → first listing → activation → first booking; sales-to-live-supply conversion |
| Account Management | Account / listing health; reply time; acceptance; payout issues; listing decay; retention risk |
| Booking Ops / Care | Queue age; ownership; first reply; resolution; tickets per booking; repeat contact; exceptions |
| Finance | Unmatched transactions; failed payouts; refunds; reconciliation exceptions; hold-to-payout latency |
| Trust | Review queue age / SLA; fraud; false positives; conversion impact; money at risk |
09 / Where marketplaces drift.
Where marketplaces drift.
Smell
Channel becomes the database
Failure. A promise lives only in a private message. Hidden state; no reliable audit.
Design response. Attach the interaction to Account / Booking.
Smell
CRM becomes the booking engine
Failure. CRM says confirmed; platform says pending. Two truths.
Design response. CRM owns pipeline; platform owns Booking.
Smell
Ticket has no Booking ID
Failure. “Tenant unhappy” triggers repeat investigation and wrong-refund risk.
Design response. Attach Person, Booking, Listing and permitted money context.
Smell
Chat contains approvals
Failure. A refund approval exists only in chat. Finance cannot rely on it.
Design response. Chat coordinates; Staff OS records the authorized decision.
Smell
Knowledge has competing owners
Failure. Help centre, internal document and bot disagree.
Design response. One canonical article, owner and review date.
Smell
AI mutates irreversible state
Failure. A bot releases money or passes identity review. Accountability disappears.
Design response. Assist prepares; bounded authority commits.
Smell
Growth optimises the wrong event
Failure. Signups rise; confirmed bookings do not.
Design response. Use platform-state outcomes, with conversion and risk together.
Smell
Executive dashboards disagree
Failure. Sales, Marketing and Finance define booking differently.
Design response. Governed definitions derived from platform events.
10 / What I would improve first.
What I would improve first.
Design bets to test against observed work, not a prescribed implementation. Start with one exception path and find where an operator loses the current answer.
One Booking ID everywhere
Mail, tickets, CRM, chatbot and analytics resolve to the same object.
Staff OS as a product
Make ownership, evidence and allowed actions visible together.
Channel gate
Identify → attach → enrich → route.
Exception-first ticketing
Create a ticket when work leaves the normal state machine.
Canonical knowledge
One answer, one owner, one review date.
Event-derived telemetry
Report product outcomes, not channel guesses.
Assist without delegated authority
Summarise, classify, retrieve, draft, suggest routing and flag anomalies.
Risk against conversion
Measure prevented loss and added friction together.
Observe → propose → preview / check → owner decision → commit → receipt.
No approval means no change. AI does not independently release payouts, materially refund, pass KYC, ban users or finalise booking-state mutations. Validate permissions, idempotency and state preconditions at the write boundary.
Assist can make the operator faster. It does not make accountability disappear.
Pavilion → The DeskKeep the truth reviewable.
How persistent agents operate inside this system → Agents
One record per object. Explicit authority. Useful exceptions. Measures with meaning. These are the design principles I would carry into discovery—and test against the people doing the work.
Discuss the work →