Delivery

Status: proposed. Not released. This page describes intended behavior for review, not a live service.

Independently bookable luggage transport for travelers in the US. A delivery order does not require a storage booking. A customer may optionally link a delivery to their own storage booking when using both. A return trip is a second delivery order.

Related: Storage · Platform · Roadmap · Release decisions

The two delivery models

Exactly two models are proposed. Both are paid orders with custody proof and manually assigned couriers in the first release.

Model	How it works
Point handoff	Customer hands bags to an authorized location during the stated window. The location confirms acceptance. A courier collects the bags, transports them, and completes a verified handoff at the destination.
Driver collection	An assigned courier collects bags from the customer at an eligible address, records items and proof, transports them, and completes a verified handoff with the recipient at the destination.

A destination may be a partner location or an approved receiving address. Eligibility and opening hours are checked before an order becomes payable.

Customer flow (proposed)

1. Choose service area, origin, destination, bag count, and handoff window.
2. Review the server-provided quote and pay online.
3. Hand over bags under the chosen model.
4. Follow custody milestones and support information in the traveler app.
5. Complete handoff with the required receiving proof.

Tracking means auditable custody milestones and promised windows. Live GPS maps and predicted arrival times are not part of the first release and are not promised here.

Courier work (proposed)

• Couriers see only jobs assigned to them.
• Couriers accept an assigned job, travel to the collection point, verify items, and record required proof at each custody transfer.
• If collection or delivery is not possible — customer absent, venue closed — the job enters an explicit exception path. A delivery cannot be marked complete without the required receiving proof.
• Proof remains pending where connectivity is lost until the server confirms it. Notifications are status updates, not proof of custody.

No automated dispatch, multi-stop optimization, third-party carrier integrations, or shared cross-organization courier pools are in the first release.

Custody and proof (proposed)

Each transfer records who handed what to whom, when, where, bag count and tag, with private proof references. History is append-only: reassignment adds a new record rather than rewriting earlier custody.

Proof photos and contact details are visible only to the assigned courier while needed, the responsible organization operators, and the customer, under defined retention rules.

Money (proposed approach)

• Quotes are created by the server for a specific route, bag count, window, currency, and expiry.
• Payment completes before dispatch. The in-app wallet funded through Stripe is the planned primary rail; a shortfall is resolved with top-up in the same flow.
• Credits and refunds follow a written cancellation policy and a traceable ledger reference.
• Courier compensation and organization settlement are reconciled to the paid order. Automated courier payouts are outside the first release.

Do not treat wallet, payout, or insurance descriptions as live availability. Commercial and legal approval is required before public bookings — see Release decisions.

Pilot sequence

The first pilot runs one route in one service area with one organization and manual dispatch. The second model follows the same proof and exception gates. Both models must each reach a verified delivery, including a recovery path for an unavailable recipient or closed location, before public delivery launch. See Roadmap.