The flight moved, and your plan already knows.
Arrival-to-Ground turns the air manifest into a ground operation: clustered transfer runs you approve, drivers dispatched on magic links, and re-optimization the moment a flight slips. The single most stressful moment in incentive ops, orchestrated.
From manifest to acknowledged pickup.
Ingest & enrich
The manifest you already uploaded for Flight Tracking is enriched with live status, estimated arrival, terminal, delays, by webhook push with a polling fallback.
Cluster
Passengers group into runs by airport, arrival window and hotel, respecting vehicle capacity. The clustering is explainable: you can see why every guest is on every run.
Approve & dispatch
You approve each run. The driver, a vendor in your network, receives it on a magic link with names, meet point and timing, and acknowledges receipt.
Watch & re-optimize
A delay, gate change or cancellation flags the affected run and proposes the fix. On approval, the new pickup reaches the driver and the change posts to chat.
A point tool holds one slice; this holds the whole program.
A flight tracker doesn't know your vendors. A transfer supplier adjusts pickups only for their own fleet, one booking at a time. A transfer list in a DMS is a static document. Orchestrating a whole group manifest across your own chosen vendor network, and re-optimizing the shared plan when one flight moves requires flights, vendors, costs and guests in one system. That is the point of DMC Pilot.
- Airport pickup and drop-off runs, with buffers for immigration and baggage
- VIP flags and driver instructions carried on every run
- “Time TBC” and “Meeting point TBC” are honest states, not blanks
- Re-run clustering any time the manifest changes
- Arrival progress feeds the home board and the Client Cockpit
- Included on Growth and Enterprise
Arrival-to-Ground questions
How are transfer runs created from the manifest?
Arriving passengers are clustered by airport, arrival-time window and destination hotel, within the vehicle capacities of your own vendor fleet. The result is a set of proposed runs, each with its passengers, pickup time and vehicle, that you review and approve before anything is dispatched.
What exactly happens when a flight is delayed?
The webhook (or the polling fallback) updates the flight, and the affected run is flagged: “A flight changed. Review this transfer.” Re-optimization proposes the fix. Shift the pickup, re-sequence, split or merge, and on approval the driver receives the updated time on the same magic link and acknowledges it. The change also posts to program chat.
Will it ever reshuffle a VIP's car on its own?
No. Re-optimization follows the trust ladder: proposals first, approval always for guest-affecting moves, and VIP-flagged guests are never auto-moved. An orchestration layer that silently rearranges the chairman's sedan would be worse than a spreadsheet, so it is designed not to.
What do drivers see?
A magic-link page with the run: passenger names, meet point, vehicle and timing. They confirm receipt. Dispatched becomes Acknowledged on your board, and pickup changes reach the same link. No app store, no account, no training.
See it on your own programs.
A 30-minute walkthrough with the team, on data that looks like yours. Sales-led onboarding: we load your catalog, your vendors and your first programs with you.