operating-model / decisions/0006-rentiful-owns-viewing-booking.md
id: adr-0006type: adrstatus: accepted

ADR 0006 — Rentiful owns viewing booking

Status

Accepted 2026-04-29.

Context

Traditional UK BTR marketplaces hand off to the operator's leasing team at the point a renter expresses interest. The renter is told "we'll pass you to leasing" or asked "are you interested?" and the marketplace's role ends there. Whether the renter actually gets to see the unit, on what timeline, with what response, is then outside the marketplace's accountability. This is the lowest-effort path for a marketplace and the worst experience for a renter.

Rentiful's product position is concierge over portal. ADR 0003 — Concierge as defining feature establishes the first anti-drift commitment: the concierge mechanism (Learn / Monitor / Share / Feedback) must operate end-to-end and not silently degrade into "send a digest like everyone else" under commercial pressure. ADR 0003 is necessary but not sufficient; even a correctly-operating concierge mechanism can hand off at "interested" and let the operator close — at which point Rentiful's defining promise erodes one stage later, less visibly.

The Viewing Journey introduced in Commit 2 of the operating-model refactor exposes the gap explicitly. Six of its seven stages live in Rentiful's accountability — but without a structural commitment that booking is Rentiful-driven, the "easy thing" under operational pressure is to wait for the renter to ask for a viewing rather than offering one. Reactive booking is the failure mode.

Without an explicit commitment encoded as system rules and Operations, the journey will quietly converge toward portal behaviour exactly the way ADR 0003's concierge thesis would.

Decision

Rentiful owns the journey from intent to a resolved post-viewing decision. Booking is Rentiful-driven, not renter-driven.

This is the second anti-drift commitment alongside ADR 0003's concierge thesis. It is operationalised through the Viewing Journey and the seven Operations in the Conversion domain.

Three structural rules follow from the decision. Each rule has an Operation that enforces it; the rule is not a value statement that lives only in prose.

Rule 1 — Booking-trigger fires proactively

The system does not wait for the renter to request a viewing. After viewing intent is detected and 1–2 options are anchored, the booking-trigger Operation fires proactively. Rentiful asks the renter "When would you like to view?" — not the other way round.

A reactive booking — one that happens because the renter chased — is a defining-feature failure mode for the journey. Reactive bookings are not necessarily wrong individually; they become a problem when they're the dominant mode, because they signal that the system has degraded toward portal behaviour. The proactive-vs-reactive ratio is therefore a falsifiable measurement of this commitment, instrumented in the same way the alert-vs-digest ratio falsifies ADR 0003.

Rule 2 — Option-anchoring constrains rather than expands

Before booking-trigger fires, the option-anchoring Operation narrows the renter's surfaced choices to 1–2 justified options. Surfacing more is not a more thorough concierge; it is a portal-style "here are five, pick one" — which pushes choice complexity onto the renter rather than absorbing it into the concierge process.

The 1–2 limit is the same constraint that ADR 0003's honest-brokerage rule articulates from a different angle: every surfaced option must carry an inspectable per-renter justification against the renter's current brief. Anchoring is where the journey enforces that this happens at booking time, not later.

Rule 3 — Every scheduled viewing must resolve; every attended viewing must produce a decision

The attendance-confirmation Operation must produce one of attended / cancelled / rescheduled / no-show on every scheduled viewing. "Unknown" is not a valid terminal state.

The post-viewing-decision-capture Operation must produce one of interested-and-want-to-apply / declined / want-more-options / ambiguous within the defined post-viewing window on every attended viewing. Silence is not a decision; the Operation explicitly produces 'ambiguous' and routes to engagement rather than letting the conversation lapse.

These two operations together close the journey deterministically. A viewing that doesn't resolve, or an attended viewing that doesn't produce a decision, fires the corresponding failure state in the Viewing Journey and routes through stuck-conversation.

Commercial linkage

This decision is not separable from the commercial engine, in the same way ADR 0003 wasn't. The concierge → CAC chain established there extends:

  • Proactive booking compresses the time between intent and viewing.
  • Compressed intent-to-viewing time produces higher viewing-to-signed conversion at any given match quality.
  • Higher viewing-to-signed conversion lowers spend per signed lease.
  • The £350 CAC guardrail is therefore reachable in part because Rentiful owns the booking step, not despite it.

The inverse is load-bearing: if viewing-to-signed conversion is lower than industry benchmarks at correct match quality, this commitment is failing operationally even if individual Operations look healthy.

Failure tripwires

The defining commitment is empirically false under any of the following sustained conditions. "Sustained" takes its definition from renter-loop/metrics.md · Measurement conventions. Numeric thresholds live in metrics.md and are reviewed quarterly.

  • Reactive-booking ratio exceeds threshold. Share of viewings booked because the renter asked, rather than because Rentiful proactively offered, exceeds the threshold over a rolling window. Tests: the ADR itself.
  • Anchored-option count exceeds 2. Sampled conversations show option-anchoring routinely surfacing 3+ options. Tests: honest brokerage; reduces to ADR 0003 territory.
  • Unresolved-viewing rate exceeds threshold. Scheduled viewings terminating without an attendance state captured. Tests: the journey's structural integrity.
  • Undecided-post-viewing rate exceeds threshold. Attended viewings that don't produce a decision state within the defined window. Tests: whether the post-viewing operation is fit for purpose.
  • Viewing-to-signed conversion materially below benchmark at correct match quality. The commercial-linkage above is failing. Tests: the commercial claim of this ADR.

Consequences

Activity in the Conversion domain is rebuilt around seven operations, with viewing-coordination narrowed to scheduling-and-logistics only, and lease-execution-handoff refactored to fire only on a positive post-viewing decision (eliminating the earlier "renter ready to sign" ambiguity).

The Viewing Journey is the read-only orchestration of these seven operations into the goal arc this ADR commits to. The journey's enforcement notes mirror this ADR's three rules.

Renter-side metrics gain three new measurable proxies: reactive-booking ratio, unresolved-viewing rate, undecided-post-viewing rate. Each becomes part of metrics.md once a baseline exists.

This commitment has no architectural impact on the Operator Loop or Financial Loop. The handoff to the operator happens at lease-execution-handoff, which is unchanged in its consequences for the operator side — only its triggering signal is tighter.

Alternatives considered

  • Hand off at "interested" like other marketplaces. Rejected. This is exactly the failure mode this ADR exists to prevent.
  • Make booking optional / advisory ("we can help you book if you'd like"). Rejected. Optional concierge is no concierge — under commercial pressure the optional path dominates and the system reverts to portal.
  • Encode the commitment only in the Viewing Journey, no ADR. Rejected. Journeys describe correct progression; ADRs make the structural commitments behind that progression non-negotiable. Without an ADR, a future loop owner could quietly reshape the journey and the commitment would erode without surfacing.
  • Make this part of ADR 0003. Rejected. ADR 0003 is the concierge mechanism (Learn / Monitor / Share / Feedback). This ADR is about the conversion behaviour that follows from the mechanism. Bundling them obscures both — and ADRs are easier to supersede individually if one element of either changes.

Related

Comment on GitHub →