Notify agents of traveler disruptions with Agent Trip Alerts

As a Travel Management Company (TMC) or Online Travel Agency (OTA), you must be informed of potential disruptions to your travelers on their trips. Agent Trip Alerts inform your agents of interruptions so that they can provide solutions to the problem.

Agent Trip Alerts push alerts to agents that notify them about potential disruption for the traveler they’re responsible for. This lets the agents proactively anticipate and solve traveler problems.

Advantages of this solution include:

  • Build brand loyalty and customer satisfaction

  • Systematic mitigation cuts down on call center costs

  • Lets cruise line companies adjust departure times based on airline delays or cancelations

Audiences

  • Online Travel Agencies (OTA)

  • Travel Management Companies (TMC)

  • Cruise line industry

Platform

Trips and Waivers

Setting up Agent Trip Alerts

Use the following tasks to set up Agent Trip Alerts.

Get an account key

To get started with Agent Trip Alerts, you first need to get an account key. See Getting Started for more details.

Import the traveler’s trip

The Trip Import API is a Post request where the body of the request is a JSON structure that describes one or more trips and the delivery the options for that trip.

We recommend you use Trip Import API to import trips. However, there are other ways to import a trip into our trip monitoring system. We can read trips from GDS queues, back-office systems, or even via custom adapters. Importing trips via these systems are part of the onboarding process that can be included in your contract with Cirium. Contact us to learn more.

Here’s an example of a post:

Trip import

Multiple trips can be imported at once through the Trip Import API. The Trip Import Structure contains each individual trip and associated entities.

Pro tip

While the Cirium API can support up to 100 trips being imported in a single call, we don’t recommend doing this. Instead, we recommend importing a single trip with each request. This simplifies troubleshooting and increases overall timeliness of the system. In addition, if there is an issue with one or more trips, this can impact other trips within the payload being correctly imported and increases error-handling complexity.

Reference number

This is a unique string that identifies the trip. It’s most often set to the record locator from the PNR or a customer-provided system key. The reference number is also used to update trips when trips change (see below for more information). When receiving an alert, this reference number can be used by your systems to match the trip with internal systems.

Delivery options

The alerting structure tells us where to deliver messages when something significant happens that should generate an alert. You can provide multiple delivery points. However, the common use case is a single delivery option for directAPIDeliveries.

"alerting": {"directApiDeliveries": [{"url": "http://YOUR_ENDPOINT","alertSetting": "agent","pullOnly": false}],]

URL

A valid HTTPS URL that we can deliver the message to.

Alert setting

This is set to the agent.

Pull only

If you don’t want messages delivered and would rather request or pull them yourself, set this to true. Otherwise, we’ll make a call to the endpoint specified in the URL.

Flights

The trip must contain one or more flights. A flight is identified by an airline code and flight number from a departure at a specified time and arriving at another airport at a specified time. We’ll match the flights with real flights and might adjust information in the underlying trip data model that we’ll send as part of the delivery.

We’ll attempt to match the flight up until the point of departure. If the provided flights aren’t valid, you’ll receive messages such as Trip Reminder. However, there won’t be any status information associated with it.

Attributes

Using this information is optional.

Attributes is a map of name/value pairs. This is only used for API delivery by push or pull. It’s used to store additional keys that help identify the trip and/or travelers in their own internal systems in those cases where reference number is not enough.

Passengers and loyalty programs

Using this information is optional.

This is list of passengers and their frequent flyer numbers. We don’t recommend you provide this information as it includes personally identifiable information (PII).

Another reason to provide this information is if your company is using Cirium Trip Center and you want your employees to see the passengers on a particular trip using the UI.

Tickets

Using this information is optional.

Tickets isn’t used by Traveler Trip Alerts. We use this information in the Waiver solution as part of the matching logic. This information isn’t necessary if you aren’t using Waivers.

Updating a trip

The same trip can be imported again at a later point if any of the information has changed, assuming that the reference number is the same. The new trip information overrides anything you provided previously.

Once you import a trip, you can’t delete. If you want to tell us to not monitor a previous imported trip, you need to import the same trip again and set the Canceled boolean to true. The trip can be retrieved at a later point using the Trip Status API.

Receive alerts based on the delivery choices

For direct API deliveries via push, you need to ensure that the HTTPS endpoint that you specified is active. Use the Test Delivery API to send simulated alerts to your endpoint and make sure that the endpoint is properly coded to handle each case.

For direct API deliveries via pull, you’re responsible for routinely calling the Pull Alerts API to retrieve relevant alerts and process them. You can’t simulate alerts using this approach, so you should track the various types of alerts received during development to ensure that you have properly coded against each type. We recommended that you log any parsing errors that you encounter and regularly check your log files to find and fix problems.

Standard Agent Trip Alerts

These are the standard Agent Trip Alert settings that we’ve determined are the most useful for a majority of our customers. You may configure variables such as time and percentages for some of the settings,. 

Flight Cancelation

The Flight Cancelation alert informs if any flight on the trip is reported as canceled. Information in this alert includes Flight Index.

This setting starts immediately.

Flight Reinstated

The Flight Reinstated alert informs if any flight on a trip previously reported as canceled is reinstated.

This setting starts immediately.

Estimated Connection Croblem

The Estimated Connection Problem alert informs the recipient if the estimated connection time for any connection on the trip falls below 25% of the Minimum Connect Times (MCT) published by the airline. This means that if the MCT is 60, an alert is triggered if the connection time falls below 15 minutes.

The information in this alert includes Flight Index (referring to the departing flight of the connection), Connection Time (current), and MCT.

This setting starts 24 hours prior and at 25% of MCT.

Flight Diversion

The Flight Diversion alert notifies the recipient if any flight on the trip lands at an airport that it was not scheduled to arrive at. Information in this alert includes Flight Index.

This setting starts immediately.

Optional agent trip alerts

The following settings are optional.

Actual Connection Problem

The Actual Connection Problem alert is sent after the departing flight leaves the gate. It informs the recipient if the actual connection time for any connection on the trip falls below 0% of the Minimum Connect Times published by the airline.

Only one Actual Connection Problem alert is sent for any given at-risk connection.

Information in this alert includes:

  • Flight Index, which refers to the departing flight of the connection

  • Connection Time (current)

  • Minimum Connection Time (MCT)

This alert starts 24 hours before the flight and at 0% MCT.

Leg Departure Delay

The Leg Departure Delay alert is sent if the gate arrival of the last flight of a leg is estimated to be delayed more than a configured threshold. It then sends update alerts if the delay changes by more than a configured amount.

If the flight is delayed 60 minutes or more within six hours before the scheduled departure of the first flight of each leg, a status alert is triggered that informs the agents of a potential risk. If the departure delay changes by more than 30 minutes  after the first triggered alert, an additional status alert is triggered.

Leg Arrival Delay

The Leg Arrival Delay is sent if the gate arrival of the last flight of a leg is estimated to be delayed more than a configured threshold. It then sends update alerts if the delay changes by more than a configured amount.

If the flight is delayed 60 minutes or more within three hours before the scheduled arrival of the last flight of each leg, a status alert is triggered to inform your operations team or agents. An additional status alert is triggered if the arrival delay changes by more than 30 minutes.

Additional information

If you want more information than what’s provided by Traveler Trip Alerts, you may use the following solutions.

Waiver Alerts is an optional add-on solution that notifies the traveler when their trip applies to airline travel waiver.

Weather APIs provide information about the weather at the traveler’s destination.

Resources

Trips and Waivers monitors the trip on behalf of your company and then triggers alerts based on the current status of the flights within the trip.

Get Trips and Waivers Account is where you can set up an account.

Get started with Trips and Waivers shows you how to get started with Trips and Waivers.

Trip Import API provides access for developers to import Trips into the FlightStats Trip platform