What we mean by end-to-end
"End-to-end" is doing a lot of work in our description of Tukt, so it is worth being precise about what we mean — and what we do not.
What it means
End-to-end means the operations lifecycle is covered: the booking, the turnover, the cleaner, the maintenance job, the compliance filing, the payout. Not covered as in "there is a field for it", but covered as in the system knows the step exists, who owns it, whether it happened, and what it cost.
The test we hold ourselves to is simple. If a step in running a property lives in a spreadsheet, a group chat, or somebody's memory, then the software has not covered it — it has just moved the problem somewhere the software cannot see.
What it does not mean
It does not mean autonomy.
This is the part people most often assume, so it is worth stating plainly: a step that asks a person to confirm something is still part of an end-to-end system. Someone approving a payout, signing off a clean, or checking a regulatory filing before it goes — none of that breaks the claim. The point is not that humans are removed from the loop. The point is that the step exists in one place, with its context attached, instead of being reconstructed from memory every time.
Plenty of operational decisions should have a human in them. What should not happen is a human being the only record that the decision was made.
Why the distinction matters
Because it changes what you build.
If you read end-to-end as autonomy, you build automation and measure success by how few people touch the system. If you read it as coverage, you build a complete model of the work and measure success by how little of the operation happens outside it.
The second one is harder to demo and much more useful at two in the morning when a guest is locked out and the cleaner has not confirmed the turnover.