The Operator Loop

Companion to the Rentiful Organisational Design. This file is the top-level overview; each domain has its own file under operator-loop/. Vocabulary used here is defined in renter-loop.md.

The loop in one sentence

The Operator Loop is responsible for everything related to units on the Rentiful marketplace — from the first conversation with a prospective operator through to that operator's units being live, accurate, discoverable, and converting at an acceptable rate.

The Operator Loop is a unit-level job, not an operator-level job. Operator relationships are the mechanism through which unit quality is achieved. Unit-level outcomes are what produce revenue. The loop owner's focus is therefore on units, not on operators-as-relationships.

On commercial vehicles

The Operator Loop onboards supply through two distinct commercial vehicles. Both produce the same unit-level outputs and flow through the same domains once an operator is live, but they differ in how operators are acquired, how their units are brought online, and how Rentiful is paid.

Standard marketplace listing. The operator lists units on rentiful.ai. Renters discover and are matched to those units through the Rentiful-branded Renter Loop. Rentiful earns commission on signed leases that originate from rentiful.ai.

Rentiful White Label. Rentiful provides the operator with a co-branded leasing microsite — operator brand foregrounded, co-signed "powered by Rentiful" — on an operator-owned subdomain, with live unit sync from the operator's PMS (Yardi first, others to follow). There is no upfront cost to the operator; Rentiful is paid £750 per signed lease originated from the microsite.

What this changes inside the loop

The acquisition conversation (Area A) and the onboarding operation (Area B) each have a vehicle-specific variant. A standard marketplace pitch sells access to Rentiful demand; a White Label pitch sells a complete leasing surface. Onboarding a standard listing ends at accurate units on rentiful.ai; onboarding a White Label customer additionally ends at a branded microsite configured, a subdomain pointed, and the Yardi sync running. Every other domain — quality, pricing, signal-to-action, revenue reconciliation — is vehicle-agnostic.

Commercial vehicles are configurations of the same two primary loops, not separate loops. One Operator Loop owns supply under both vehicles; one Renter Loop owns conversations on every surface those vehicles produce. Treating them as separate loops would re-introduce the handoffs the model exists to eliminate.

See ADR 0004 — Co-branded white label for why White Label is co-branded rather than fully white-labelled.

The shape of the loop

The Operator Loop is the supply side of the Rentiful marketplace. It is structured around seven domains, each containing one or more operations. There are no sub-loops at present — the loop owner owns every activity directly, with execution happening through some combination of personal work, AI automation, and contractors as appropriate.

Unlike the Renter Loop, where domains roughly follow a single renter through a funnel, the Operator Loop runs on multiple parallel cycles per operator. A new operator is being acquired (Area A) while an existing operator's units are being quality-checked (Area D), another operator is being given pricing feedback (Area E), and the monthly financial close runs across all operators (Area G). The loop is wide and continuous, not sequential.

Why this loop is structurally demanding

The Operator Loop has a structural property that makes it harder to run than the Renter Loop: it has no automatic forcing function. Renters arrive every day with their own urgency, and the Renter Loop has to respond. Operators do not generate the same daily pressure. Unit data goes stale silently. Listings drift out of date silently. Operators churn slowly. If the Operator Loop is under-resourced or under-attended, the symptoms appear in the Renter Loop weeks or months later, when conversion has already degraded.

The discipline this requires: the Operator Loop must be run proactively, on a cadence the loop owner sets, not reactively to incoming pressure. Diagnostic signals from the Renter Loop are one of the few external forcing functions; they should be treated as priority inputs, not as background noise.

The concierge dependency

With the Renter Loop's concierge matching established as a defining feature of Rentiful (see ADR 0003), one aspect of the Operator Loop has been elevated in importance: how fast new units become available to the Renter Loop. A unit that takes hours or days to surface after the operator publishes it is a missed concierge moment. The new-unit publishing operation is now a hard dependency of the perfect-fit alert operation in the Renter Loop.

Domains at a glance

Area	Purpose
A. Operator acquisition	Bringing new operators onto the platform
B. Operator onboarding	Moving a signed operator to live, with units published
C. Listings and unit publishing	Ongoing management of what appears on the marketplace
D. Unit data quality (incl. ROD)	Maintaining the quality bar across all operator and unit data
E. Pricing and conversion signals	Translating Renter Loop diagnostics into operator action
F. Operator health and retention	Keeping signed operators active, engaged, and expanding
G. Financial close with operator	Ensuring signed leases translate into invoiced revenue

Sub-loops

There are no sub-loops within the Operator Loop at present. The loop owner owns every activity directly. The Operator Loop is wide enough that this is genuinely demanding — but splitting it prematurely would re-introduce exactly the handoffs the model is designed to eliminate.

Future candidate sub-loops

Candidate	Signal → Closed state
Operator Acquisition Sub-Loop	Prospective operator surfaces → operator signed. The natural first split, because acquisition is materially different work from running an existing operator base.
Operator Success Sub-Loop	Operator signed → units live, converting, and operator retained. The counterpart to Acquisition; everything post-signature.
Data Operations Sub-Loop	Source data in → ROD-grade curated data out. If unit data quality becomes a full-time discipline, it becomes a candidate sub-loop in its own right.

The most likely first split is Acquisition / Success. The skill profile for winning new operators is meaningfully different from the skill profile for running and growing existing ones. When operator volume reaches the point where one person cannot do both well, this is the cut to make.

Cross-loop dependencies

The Operator Loop is internally self-contained but deeply connected to every other loop. The connections to the Renter Loop are the most operationally important; the connections to the Platform Loop drive the bulk of platform requests. The full dependency graph lives in cross-loop.md; summary here.

Other loop	What flows between
renter-loop	Receives: diagnostic signals on unit-level conversion patterns (pricing, representation, availability, data) and concierge-process friction attributable to supply, plus lease-execution handoff package. Provides: live, accurate, discoverable units, plus near-real-time notification of new and updated units for perfect-fit matching.
platform-loop	Receives: shipped infrastructure capabilities (data model, integrations, ROD platform, event emission for Renter Loop, multi-brand config for White Label). Provides: specs for blockers, validation of shipped changes.
financial-loop	Receives: invoicing infrastructure, cash reconciliation. Provides: confirmed leases per operator, dispute resolutions.
strategy-loop	Receives: strategic priorities (operator targeting, market focus, commercial terms). Provides: operator and market intelligence.

The two most important cross-loop dependencies

Renter Loop ↔ Operator Loop diagnostic feedback. The Renter Loop sees in real time which units are converting and which are not, and which matches succeed or fail. The Operator Loop is the only place that can act on what those signals say. Treating these signals as priority inputs — not as background noise — is what allows the marketplace to compound. Every signal received should result in a documented outcome: action taken with operator, action declined with reason, or signal acknowledged with a planned action and timeline.

Operator Loop → Renter Loop new-unit notification. The perfect-fit alert operation can only function if the Operator Loop surfaces new and updated units in near-real-time. This flows from operator-loop.listings.new-unit-publishing into renter-loop.matching.perfect-fit-alert. Publication latency in the Operator Loop is a direct determinant of concierge quality on the Renter side.

What success looks like

The Operator Loop is measured at the unit level, not the operator level. Unit-level outcomes are what produce revenue; operator-level activity is a means, not an end.

Primary metrics

Live units on the marketplace — growing month-over-month.
Unit-level conversion rate — what percentage of published units generate a lease within a defined window.
Units with zero conversion over 90 days — a leading indicator of supply-quality problems.
Revenue per operator — growing over time as operators expand on the platform.

Supporting metrics

New operators signed per month.
Time from first contact to operator live (acquisition + onboarding cycle time).
Time from signed to first unit published (onboarding only).
Publication latency — time from operator-side publication to Renter-Loop-consumable state (target: minutes).
Unit data quality score — composite of completeness, freshness, accuracy.
Operator retention rate and contract renewal rate.

Leading indicators of loop health

Manual interventions per unit published (should trend down as automation matures).
Stale unit rate — units not updated within an acceptable freshness window.
Diagnostic signals acted on — when the Renter Loop flags an issue, time to action and outcome.
Operator health score distribution — what fraction of operators are healthy, at-risk, or in intervention.

Financial integrity metrics

Leases signed but not invoiced — must remain at zero.
Monthly confirmation cycle compliance — confirmation completed for every operator before close.
Aged receivables — should remain controlled and not accumulate.

What this loop is not

The Operator Loop owner is not an account manager. Not a sales rep. Not a data ops manager. They are the accountable owner of the entire supply side of the marketplace, which traditional organisations split across all three of those functions plus operations and analytics.

Specifically, this loop does not include:

Renter acquisition, nurture, or conversion — renter-loop.
Platform architecture or product build — specced by this loop, owned by platform-loop.
Bookkeeping, accounts payable, statutory finance — financial-loop.
Setting company strategy — strategy-loop.

Failure modes

The Operator Loop fails in predictable ways — most of them quietly, because the loop has weak external forcing functions and degradation often only surfaces in the Renter Loop's metrics weeks later.

Becoming relationship-focused rather than unit-focused. Operators are well-managed but units are still poor. The loop owner is busy, the operators are happy, the marketplace is not converting.
Unit data quality degrading silently as the operator base grows. Automation for quality monitoring must scale ahead of manual capacity, not behind it.
Publication latency creeping upward. Manual review queues grow, units sit unshipped, perfect-fit alerts fire too late or not at all. This is new as a named failure mode because of the concierge dependency.
Diagnostic signals from the Renter Loop being acknowledged but not acted on. The most common failure of cross-loop discipline.
Operators signed but never reaching "live with converting units". The loop appears to close at signature but actually hasn't. Onboarding cycle time should be tracked relentlessly to prevent this.
The monthly financial close slipping. Once it slips once, slipping becomes normal, and aged receivables grow.
Treating ROD as a side effect of operations rather than a first-class output. Neglected ROD compounds into a strategic data weakness.
The loop owner spending disproportionate time on Area F (relationships). Because it's the most human, at the cost of Areas C, D, and E — the work that actually moves unit-level outcomes.

Using this document

When something inside the loop is unclear or contested — find the domain, find the operation, ask whether the structure or the execution is the issue.
When considering a change to how the loop runs — check whether the change is at the activity level (small, frequent) or at the structural level (rare, requires updating this document).
When eventually splitting the loop into sub-loops or hiring additional loop owners — the domains and operations here are the source material for scoping new accountabilities.

Changes to this document should be deliberate and tracked. Changes to specific tools, automation platforms, or week-to-week tactics should not require updating this document — those live one layer below the operations described here.