Each stage has a different useful question
At enquiry and qualification, the useful question is whether the owner need, service fit, and responsible contact are understood.
Read the details
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
- Checked — this describes the documented business lifecycle, not current automation coverage.
- Proposed next state
- 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.
Checks to include when changing this section
- 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
A familiar display name is not enough to join a departure, cleaning task, and next arrival.
Read the details
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
- Checked — the handoff specifically warns against relying on familiar display names for overlapping units or listing variants.
- Proposed next state
- 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.
Checks to include when changing this section
- 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
If provider information is old, incomplete, or cannot be matched, the response is to confirm coverage or ask for a new source read.
Read the details
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
- In progress — current provider freshness and all transition acceptance need live evidence before a result is asserted.
- Proposed next state
- 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.
Checks to include when changing this section
- Check “old source” and “assigned without evidence” remain separate states.
- Use the contextual panel to prepare an investigation prompt without sending or executing it.
Apply with care
A concrete safe example
Example, responsibilities & checklist
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.
An incoming need can become a supported operational result with a named exception when it cannot.
Traceability without sensitive material
Source pointers and exports
This page expands the approved handoff into plain-language guidance. It does not include runtime logs, credentials, databases, private evidence, internal QA artifacts, or developer planning history.
Documentation references
- Handoff / pages/workflows.html
- Handoff / pages/organisation.html