Core concepts
The booking lifecycle
The explicit state machine every booking follows, and why illegal transitions are impossible.
States, not statuses
A Renaro booking is always in exactly one state, and only defined transitions between states are legal. A trip cannot be completed before it was started; a cancellation records who cancelled and under which policy. Invalid transitions are rejected by the platform itself, not by dispatcher discipline.
- draft → requested → scored → offered → assigned
- assigned → en_route → arrived → on_board → completed
- requested/offered/assigned → cancelled (with actor and reason)
- completed → settled (ledger written, payouts scheduled)
Every transition is evidence
Each transition writes an event with the actor, timestamp, and before/after state. That event stream is what powers the trip timeline dispatchers see, the passenger's status notifications, and the audit answers owners need weeks later.
Time-based behavior
Scheduled bookings wake up at the right lead time and enter dispatch automatically. Delayed automations re-check current state before acting — a reminder job that fires after a cancellation simply does nothing, by design.
No-shows and disputes
No-show handling is part of the lifecycle: arrival evidence, wait timers, and contact attempts are recorded before a no-show fee is ever charged. When a passenger disputes, you respond with the timeline, not a memory.