Passenger-commerce fulfilment needs a shared order state that joins route eligibility, ordering cutoffs, stock, vendor acceptance and payment confirmation. The workflow should advance only when a feasible handoff remains, and send conflicting states to an operator before promising delivery.
Composite reference architecture. A modelled architecture based on the existing BergLabs case taxonomy; no client deployment or outcome is asserted.
The operating problem
A passenger order looks simple until route eligibility, station timing, inventory, vendor acceptance and payment confirmation diverge. The operational risk is a paid order with no feasible fulfilment path.
How the workflow works
Start with the journey reference, travel date, station and order. Check the route window and reserve stock for a stated duration before asking the vendor to accept. Record payment confirmation independently of fulfilment acceptance. A paid order still needs a feasible station and vendor handoff; payment status cannot stand in for fulfilment readiness.
Where review and controls matter
Recheck time-sensitive conditions when the vendor accepts, because a valid order can become infeasible while it waits. Expired stock reservations, route changes and uncertain payment events enter an operator queue with the passenger promise visible. Use one fulfilment identifier through dispatch and verification-code redemption so duplicate notifications do not become duplicate handoffs. Refunds follow the operator's approved policy and authority.
Retry reference: Stripe idempotent requests. Destination support and reconciliation still need verification.
What to measure
Use a fixed cohort and measurement window. Count numerator events only within the denominator's eligible cohort; sampled measures use the same audit sample for both terms. Record the source, exclusions and owner, and keep missing data visible. These definitions are proposed measurement contracts, not observed results.
| Measure | Definition and unit |
|---|---|
| Eligible-order success | Fulfilled orders divided by orders accepted as eligible at intake; percent, with later failures retained in the cohort. |
| Vendor acceptance | Orders accepted by the vendor before expiry divided by orders offered to vendors; percent. |
| On-time handoff | Completed handoffs inside the promised window divided by handoffs due; percent. |
| Refund rate | Refunded orders divided by paid orders in the same cohort; percent, separated by reason. |
| Repeat purchase | Customers making another qualifying purchase within a fixed follow-up window divided by customers whose full window has elapsed; percent. |
A useful first pilot
Test one route and one vendor handoff window with order replays that include late acceptance, stale stock, payment timeout and route change. Confirm the final passenger-visible state for every replay.
Bring the workflow, its source records and the decision that needs an owner to a BergLabs pilot discussion.
