# Property lifecycle: from enquiry to review
> Checked · 20 October 2026 · Wiki version 2026.10.20.2
A property service lifecycle connects owner needs, identity, stays, readiness, settlement, and learning. It is a model to validate, not a claim that every handover is automated.
## Purpose
Show what should travel with a property through the service so a useful handover does not depend on memory or a familiar listing name.
## Diagram text alternative
Enquiry becomes qualification, onboarding, listing, reservation, stay, turnover, readiness, settlement, and review. The turnover, finance, and learning pages explain the high-care stages.
## Current / proposed status
- Current: Checked — the lifecycle stages are documented; automation and transition completeness are not assumed.
- Proposed: Validate each handover against a current property record and its authoritative provider source.
## Safe example
### A safe identity handover
When an owner enquiry becomes a listing, carry the confirmed property identifier and source context. Do not join records just because two display names look similar; units and listing variants can overlap.
## Responsibilities
- Selling qualifies the need and preserves owner context.
- Planning checks readiness information and commitments before a property enters active operations.
- Delivering follows current reservations, departures, and readiness evidence.
- Learning captures a repeated exception after settlement or review.
## Checklist
- Keep the property identity stable across enquiry, onboarding, reservation, turnover, and settlement.
- Name the authoritative provider for its own transaction rather than treating a dashboard projection as the source.
- Mark an unresolved transition with an exception owner and next check.
- Feed repeatable lessons into a reviewed SOP rather than leaving them in a chat or memory.
## Each stage has a different useful question
**Status:** Checked
At enquiry and qualification, the useful question is whether the owner need, service fit, and responsible contact are understood. At onboarding and listing, it is whether the property identity and required readiness information can be matched to provider records.
At reservation and stay, the operating date, arrivals, departures, and exceptions must be clear. At turnover and readiness, the team needs assigned work, evidence, and manager review. At settlement and review, it needs supported financial records, authorised review, and a lesson that can improve the next cycle.
**Current / proposed status**
- Current: Checked — this describes the documented business lifecycle, not current automation coverage.
- Proposed: Capture a real handover artifact for each stage before calling the transition complete.
**Expected outcome**
Every stage has a question, source context, and a handover another person can verify.
**Meaningful tests**
- Check all lifecycle labels are represented in the SVG text equivalent.
- Check no stage implies an accepted readiness result without supporting evidence.
## Identity is the thread through the lifecycle
**Status:** Checked
A familiar display name is not enough to join a departure, cleaning task, and next arrival. The same confirmed property identity must be present in the source record, task, and readiness decision.
When identity is incomplete, treat the ambiguity as an exception. A plausible match is not a safe substitute for a confirmed one, especially where unit names or listing variants overlap.
**Current / proposed status**
- Current: Checked — the handoff specifically warns against relying on familiar display names for overlapping units or listing variants.
- Proposed: Route unresolved identity to a named verifier before it affects a readiness or financial decision.
**Expected outcome**
A handover can be matched to the correct property without a heuristic becoming an unrecorded decision.
**Meaningful tests**
- Check the safe example and context prompt describe a confirmed identifier, not a fabricated property name.
- Check exception wording appears in both page and Markdown export.
## An exception is a visible work item, not a hidden gap
**Status:** In progress
If provider information is old, incomplete, or cannot be matched, the response is to confirm coverage or ask for a new source read. If a task is assigned but has no completion evidence, the response is to request the missing result. These are different states and should not share a reassuring label.
The wiki does not claim that all exception routing is complete in the installed system. It explains the decision boundary so an operator can investigate it safely.
**Current / proposed status**
- Current: In progress — current provider freshness and all transition acceptance need live evidence before a result is asserted.
- Proposed: Record exception owner, source window, next check, and closure evidence in the relevant current system.
**Expected outcome**
Uncertainty stays visible until the right person resolves it with supporting evidence.
**Meaningful tests**
- Check “old source” and “assigned without evidence” remain separate states.
- Use the contextual panel to prepare an investigation prompt without sending or executing it.
## Related pages
- [Turnover readiness: evidence before a ready decision](/workflows/turnover-evidence/) — A turnover prepares a property between stays. Assignment, cleaning completion, evidence, verification, and readiness are separate states that must refer to the same confirmed property.
- [Finance records: support the review before the conclusion](/workflows/finance-records/) — Financial planning and settlement work need identifiable source records, clear commitments, authorised review, and a traceable link to any learning that follows.
- [SOP learning: turn observations into a better next step](/workflows/sop-learning/) — Learning connects incidents, reports, and repeated exceptions to a reviewed procedure. It prevents a useful lesson from being stranded in a one-off conversation.
## Source pointers
- Handoff / pages/workflows.html
- Handoff / pages/organisation.html
## Context export
- Page context: ./exports/workflows--property-lifecycle.context.json