Renter Loop · Viewing Journey
Goal
Convert qualified renter intent for a specific unit into a resolved outcome. A "resolved outcome" is one of: application made, application rejected, re-matched (the journey loops back to matching with updated brief), rescheduled (the viewing is moved without restarting the journey), or closed unsuccessful (archived with a logged reason).
This is the operational expression of the "Rentiful owns viewing booking" commitment — the second anti-drift commitment alongside ADR 0003's concierge thesis. A more specific ADR for this commitment is scheduled for Commit 3 alongside the operations that implement it.
Entry conditions
The Viewing Journey starts when all of the following are true. Until they are, the renter is in matching/engagement, not in this journey.
- Renter has been qualified per the Initiation domain. At minimum: location, bedrooms, budget, timescale.
- At least one option matching the renter's brief has been surfaced via the Matching domain — recurring digest or perfect-fit alert.
- Renter has shown signal of viewing intent on a surfaced option. Today this signal is detected by the generic in-conversation-qa operation; a dedicated
intent-detectionoperation lands in Commit 3.
Stages
The seven stages below are ordered. Each stage has one or more Operations that do the work; the Journey itself executes nothing — it defines what should happen and what failure looks like.
1 · Intent capture
Detect and confirm that the renter is signalling readiness to view a specific unit (or shortlist of units). Distinguishes "ready to view" from generic interest, browsing, or information-gathering questions.
Operations referenced:
renter-loop.conversion.intent-detection— specialises viewing-intent classification.renter-loop.engagement.in-conversation-qa— remains the generic question handler. The two coexist: in-conversation-qa handles non-viewing questions and feeds candidate signals to intent-detection.
2 · Option anchoring
Constrain the renter's surfaced choices to 1–2 justified options before triggering the booking ask. Reduces decision friction; prevents the journey from drifting into portal-style "here are five, pick one."
Operations referenced:
renter-loop.conversion.option-anchoring— applies the 1–2 justified-options rule. The honest-brokerage rule from ADR 0003 is the constraint: every option must carry an inspectable justification against the renter's current brief.
3 · Booking trigger
Rentiful proactively asks for the viewing slot. The system rule is unambiguous: Rentiful asks first, the renter does not have to chase. Reactive bookings are a defining-feature failure mode for this journey.
Operations referenced:
renter-loop.conversion.booking-trigger— emits the proactive booking ask in the renter's preferred medium. The operation is structurally proactive — it fires after option-anchoring, not in response to a renter prompt. See ADR 0006 — Rentiful owns viewing booking.
4 · Viewing coordination
Schedule the viewing, coordinate with the operator, dispatch reminders to both sides. Scope is scheduling-and-logistics only — post-viewing follow-up moved to its own operation.
Operations referenced:
renter-loop.conversion.viewing-coordination— slot selection, operator coordination, confirmation by both parties, reminders.
5 · Attendance confirmation
Resolve the scheduled viewing into a captured state: attended, cancelled, rescheduled, or no-show. Every scheduled viewing must end in one of those four states; "we don't know what happened" is not a valid terminal.
Operations referenced:
renter-loop.conversion.attendance-confirmation— captures the attendance state and routes to the appropriate next stage (post-viewing-decision on attended; re-coordination on rescheduled; recovery on cancelled or no-show).
6 · Post-viewing decision
Capture the renter's decision after an attended viewing — interested-and-want-to-apply, declined, want-more-options, or ambiguous. Decision must be captured within the defined window after the viewing; ambiguous responses route to engagement for follow-up rather than being silently dropped.
Operations referenced:
renter-loop.conversion.post-viewing-decision-capture— produces a decision state within the defined window.
7 · Handoff or close
On a positive decision, hand off for lease execution and let the journey terminate as application made. On a negative decision, the journey routes back to matching with an updated brief, or archives as closed unsuccessful with a logged reason.
Operations referenced:
renter-loop.conversion.lease-execution-handoff— executes the positive-decision path. Refactored in Commit 3 to fire only on positive post-viewing decision.renter-loop.engagement.stuck-conversation— catches journeys that stall at any prior stage and don't progress within the defined timeouts.
Required transitions
Each transition has an explicit precondition. A stage cannot be skipped; if a precondition is not met, the journey is in a failure state and must be handled by the failure chain below.
| From | To | Precondition |
|---|---|---|
| intent-capture | option-anchoring | Ready-to-view intent detected for a specific unit or shortlist |
| option-anchoring | booking-trigger | 1–2 justified options anchored against the renter's current brief |
| booking-trigger | viewing-coordination | Renter offers ≥1 candidate slot |
| viewing-coordination | attendance-confirmation | Viewing scheduled and confirmed by both renter and operator |
| attendance-confirmation | post-viewing-decision | Attendance state captured (attended path only; cancelled/rescheduled/no-show route elsewhere) |
| post-viewing-decision | handoff-or-close | Decision state captured |
Failure states
A failure state is reached when a required transition's precondition is not met within the stage's defined timeout. Numeric timeouts live in renter-loop/metrics.md once the operations land in Commit 3.
| Failure state | Description | Handled by |
|---|---|---|
| stalled-at-stage | Stage timeout exceeded without next-stage transition. | renter-loop.engagement.stuck-conversation |
| unresolved-viewing | Scheduled viewing did not produce an attendance state. | renter-loop.engagement.stuck-conversation (system rule: every scheduled viewing must resolve) |
| undecided-post-viewing | Attended viewing did not produce a decision state within the defined window. | renter-loop.engagement.stuck-conversation |
| closed-unsuccessful | Journey terminates without lease handoff (renter declined, re-matched, or archived). | Logged outcome on the conversation; no further escalation. |
Enforcement notes
These notes are the structural commitments the journey defends against drift. They are not negotiable under commercial pressure — if any erodes, the journey collapses back into portal behaviour, which is exactly what ADR 0003 (concierge as defining feature) and the planned ADR 0006 (Rentiful owns viewing booking) exist to prevent.
- Booking is Rentiful-driven. The booking-trigger stage MUST fire proactively from Rentiful, not in response to a renter request. Reactive bookings indicate the journey has degraded.
- Option anchoring constrains, not expands. Stage 2 MUST narrow surfaced options to 1–2 justified candidates. Surfacing more is the honest-brokerage breach ADR 0003 names.
- Every scheduled viewing resolves. No scheduled viewing is allowed to terminate without an attendance state captured.
- Every attended viewing produces a decision. Within a defined window. Silence is not a decision.
- Failure chains are deterministic. Stalls trigger stuck-conversation → re-engagement → re-match → escalation → archive-with-reason. The journey does not "drift" without the failure chain firing.
- Loop ownership is unchanged. The Renter Loop owner is accountable for every journey outcome. Operations execute the work. The journey defines correct progression and the failure responses; it does not own, execute, or introduce a new accountability seam.
Notes on this file
The Viewing Journey was the prompting case for introducing the Journey construct in Commit 2 — a goal-shaped sequence that crosses several Operations across the conversion and engagement domains. With Commit 3, all seven journey stages now reference real Operations rather than planned ones; the journey is fully resolved.
The two anti-drift commitments embedded in this journey — option anchoring constrains rather than expands and booking is Rentiful-driven — are formalised in ADR 0003 — Concierge as defining feature and ADR 0006 — Rentiful owns viewing booking respectively.