Reference · built on requestOperator by FibricHospitality & guests

Shuttle Timing

Reads the flight on each arriving reservation against FAA airport delays and proposes moving the shuttle or pickup before the guest lands.

Request accessPricing ↗

About

The shuttle leaves for the airport on the schedule, and the guest's flight is held on the ground by a ground stop at the origin. Shuttle Timing reads the flight number and arrival time on each reservation, the FAA airport status feed for ground stops, ground delay programs, and average delays at the arrival airport, and the pickup tasks already on your drivers' routes.

When the airport is delayed, it proposes a new pickup window for the affected task, a message to the guest, and a note to the driver. The transport desk approves each one. The original time, the delay, and the change are kept together.

This is a reference listing. It documents what Fibric would read from Shuttle Timing and what it could propose, based on the vendor's published interfaces. Fibric builds it under a managed deployment when you request it; selecting it here installs nothing.

Inputs

  • Flight number, arrival airport, and arrival time held on the reservation as custom fields, traces, or notes in the property management system
  • Ground Stop Programs, Ground Delay Programs with average and maximum delay, Airspace Flow Programs, and closures per airport from the FAA airport status feed
  • Pickup tasks with completeAfter and completeBefore windows in Onfleet, and their ETA and delay events
  • Vehicle location and route stop arrivals from Samsara, so the operator knows where the shuttle is now
  • Driver acknowledgements and delivery status on the messages it proposes through Twilio
  • Weather alerts for the airport's area from the National Weather Service, as context for the delay

Proposed actions

  • Target capability: propose a new completeAfter and completeBefore window on the Onfleet pickup task, sized to the airport's average delay, for the desk to approve
  • Target capability: propose an SMS to the guest through Twilio confirming the new pickup time and where to meet the driver
  • Target capability: propose a note to the driver with the flight, the delay reason, and the revised window
  • Target capability: propose holding a scheduled shuttle departure when every guest on it is arriving into a ground stop
  • Target capability: propose a reservation note recording the delay and the new pickup time

Proposed actions are target capabilities. Every action runs propose-first and needs a validated deployment and the appropriate permissions.

What you can build

  • Move the pickup before the guest boards

    The FAA feed shows a ground delay program at the arrival airport with an average delay. The operator proposes shifting the Onfleet pickup window by that amount and an SMS to the guest through Twilio.

    With Airport Delays, Onfleet, Twilio

  • Hold the shuttle for a ground stop

    Every guest on the evening shuttle is arriving into an airport under a ground stop. The operator proposes holding the departure and shows the Samsara location of the vehicle to the transport desk.

    With Airport Delays, Samsara, Oracle OPERA Cloud

  • Fix the flight numbers first

    Reservations in Cloudbeds with a flight number that matches no airport are listed each morning for the desk, so the evening's pickups can be watched.

    With Cloudbeds

  • Add the weather to the picture

    A severe weather alert at the airport from the National Weather Service is shown beside the delay and the Tookan pickup task, so the desk can decide whether to expect a longer wait.

    With Weather & Severe Alerts, Tookan

Requirements

  • A property management connector where flight numbers and arrival times are held on reservations: Oracle OPERA Cloud, Cloudbeds, Mews, or apaleo
  • A dispatch connector with pickup tasks and time windows, such as Onfleet or Tookan, or vehicle location from Samsara
  • A Twilio number for guest and driver messages
  • A rule for how much airport delay changes a pickup, and the earliest time a guest may be messaged, set by you
Authentication
Shuttle Timing uses no credentials of its own. The FAA feed is public and needs none. Reservations, tasks, vehicles, and messages are read and proposed through the connectors you have connected.

Limits

  • The FAA feed reports delays per airport, not per flight. A flight arriving on time into a delayed airport is still shown as at risk.
  • Airports outside the United States are not in the FAA feed. Those pickups are watched by their scheduled time only.
  • Flight numbers typed wrongly on a reservation cannot be matched. The operator lists them for the desk to fix.
  • It moves a task window only after approval. Drivers are not redirected mid-route by the operator.

Access and pricing

Reference listing. Fibric builds the operator under a managed deployment when you request it. Your quote covers the build, capabilities, usage, and support.

Request Shuttle Timing ↗

Questions and answers

What does the transport desk approve?
Each change to a pickup window, each message to a guest or driver, and each shuttle hold. The proposal shows the flight, the airport status with its reason, the current task window, and the proposed one. The desk can change the time before approving.
What record is kept for a delayed pickup?
A receipt: the flight and airport status at the time, the original and revised windows, who approved the change, the messages sent and their delivery status, and the driver's acknowledgement. The reservation note is proposed with the same facts.
Does it ever reroute a driver or message a guest itself?
No. Every change waits for the desk. A task window changes, a shuttle holds, or a message goes only after approval, and each once. It never assigns a driver, cancels a pickup, or reads anything about the guest beyond the reservation.
Ask about Shuttle Timing

Ask about the capabilities and requirements in this listing.

For project-specific requirements, contact Fibric.

This operator is developed, published, and supported by Fibric. Third-party names and logos identify the systems an integration connects to; they are the property of their respective owners, who are not affiliated with Fibric and do not sponsor or endorse this listing. Trademark policy