Review a transport run before handing it to a driver

A transport handoff is a saved route and named passenger list. It records the departure and arrival instants, displayed timezone, pickup and destination, passenger and wheelchair capacities, driver contact and guest instructions. A driver's invitation gives access to that exact issued version.

Open Hospitality → Transport → Review dispatch & driver handoff. The coordinator can review current assignments, issue a manifest, invite a named driver and record the run's progress. Changes here send no email or text: copy a driver invitation yourself after creating it.

A worked example

Avery and Morgan have three passengers on a garden shuttle. Taylor needs a wheelchair place. The coordinator checks the pickup, times and names, then issues manifest 1. Alex receives a private invitation for their verified account email, claims it and acknowledges manifest 1. The coordinator opens boarding; Alex checks Taylor in and records when Taylor boards.

Jordan then moves to a second shuttle. The coordinator selects Jordan, the destination and the seat requirement, then confirms a reason. The transfer releases the original seat only if the destination can accept Jordan. The service also checks overlapping shuttle assignments. Both passenger lists now need fresh review. Manifest 1 remains in history, but its driver access cannot record boarding against the changed list. Issuing manifest 2 revokes the prior invitations; the new invitation needs a fresh acknowledgment.

Guests may still change an unboarded reservation before departure when Guest Hub reservations are enabled. Those edits make an issued list stale; the coordinator must review the resulting list before boarding continues.

The live check-in and boarding statuses do not change the passenger list revision. A change to the route, named roster or seat requirement does.

Save and review a run

Creating or editing a run requires an explicit reviewed action and a reason. The service preserves prior run metadata and the exact request identity. If the browser cannot confirm a response, use Check original request. That repeats the saved request rather than creating another run.

Changing the route or times makes the previous handoff stale. Move assigned passengers before reducing capacity below the number of occupied places. A run that has departed, arrived or been canceled retains its history and cannot be reopened through the ordinary edit form. Create a replacement run when needed.

Departure and arrival fields use the selected timezone. Ambiguous or nonexistent local times during a clock change are rejected; choose an unambiguous time. The final review shows the actual instants in that timezone.

Issue the manifest and grant access

Review the exact displayed passenger list and issue it. Each issue gets a new manifest number. Historical issued versions remain available, including their acknowledgment count. The current run, issued manifests, driver invitations and passenger operation history are separate views.

An owner or administrator in the owning wedding workspace may create driver invitations. The invitation identifies a recipient name, a verified account email, an expiry within 30 days and one of two permission sets:

• Read and acknowledge the manifest.
• Read, acknowledge and record boarding.

The driver must sign in and claim the invitation. Merely possessing its URL does not expose the passenger list. Another account cannot take over an already claimed invitation. Revoking the invitation, replacing the manifest, removing the issuing administrator's access or reaching the invitation expiry stops access. An expired or replaced link cannot be used to confirm an old action again.

A connected business with an explicit transport section grant may review or edit the allowed transport work. It cannot create outside-driver grants on behalf of the owning business. Transport permission does not expose private CRM notes, emergency support details, gifts or private dispatch notes to a driver.

Board, depart and arrive

The coordinator opens boarding after issuing a current manifest. A driver with boarding permission must acknowledge that exact manifest first. Both authorized coordinators and acknowledged drivers can record Reserved, Checked in and Boarded, with a reason. Each update checks the last passenger revision; a stale screen must refresh before changing a newer status.

Departure requires every currently assigned passenger to be boarded. For a no-show who was already checked in or boarded, first record a correction to Reserved through the reviewed handoff. Then explicitly cancel that passenger's assignment, review the changed list and issue a replacement before departing. Record arrival afterward. These are operational records, not live vehicle tracking or an automatic dispatch notification service.

The screen refreshes after a saved operation or when you choose Refresh current status. Printed copies do not update and cannot enforce later revocation. Keep them private and verify the latest version with the coordinator before use.

API and limits

The named-account API exposes the coordinator workflow under /api/v1/projects/{id}/transport and driver access under /api/v1/transport/{token}. Requests require a current Clerk account session; driver claims also require the invited verified email. Consult /api/v1/openapi for exact validated fields and supported operations. These named participant flows do not accept a generic scoped API key as a substitute for a person's identity.

Manifest history pages, invitation history pages and passenger activity pages are independently validated. Requests retain exact idempotency and revision checks. The driver view contains only its issued manifest and live boarding statuses; it does not include other runs, private host records or invitation management.

This workflow does not book a transport provider, charge a passenger, calculate driving directions, perform vehicle tracking or automatically notify passengers. Provider delivery setup remains separate from the copied-link handoff described here.