Air Bookability Workflow 2 Best Practices: Sell Price Ignore Book

The "Sell Price Ignore Book" Bookability Workflow basically performs:

1. Low Fare Shop
2. Opens a session.
3. Performs a sell and ignore.
4. Performs an Air Price and Air Create Reservation.

A basic bookability workflow diagram demonstrates these steps. A more detailed diagram with transactions and specific steps is below.

 

The following flowchart demonstrates the workflow for a successful booking, based on the associated transaction. Each step has up to four components that are discussed in detail. The Bookability Best Practices Workflow version 2 is also available in PDF format.

Search Flights

Transaction: Search for flights: LowFareSearchReq

End User: Searches for flights

UI/API: Sends search data entered by user

Recommendations:

• Use the same GDS:

  • The sell request always follows an Availability/Shopping request in the same GDS.

  • By shopping and booking in different GDSs the availability quality cannot be trusted.
• Use filters for search

  • If specific itineraries will not be booked by the traveler they should be filtered out via the SCC or at time of shopping request.

    • If the filtering is done at time of request then a more useful set of itineraries are returned.

    • SCC is a great tool to allow OTAs to implement basic search optimisation without involving developers at the OTA.

      Search Control Console

      

• Have consistent number of passengers:

  • The number of passengers should remain constant for all segments of the itinerary and all phases of the booking process.

  • Inconsistencies in the number in party will increase the possibility of sell failures.

• Use Valid IATA Codes:

  • Availability/shopping results may be degraded without a valid IATA code.

  • Some airlines return inferior availability to non-IATA agencies.

• Use a Trace ID:
  • A Trace ID is highly recommended in all requests.
  • A unique TraceID can be used to track all transactions within a workflow.

  • By using the TraceID, Universal API customers and Travelport teams are able to log, identify, and extract transactions for investigation purposes, which greatly improves speed of response to any support tickets.

  • Not having the TraceID implemented causes unnecessary delay, and potentially no resolution, for a reported problem.

• Use e-Pricing Metas over Metasearch sites:

  • Metasearch sites (price comparison sites) have very high look to books and low conversion rates due to searching through multiple providers.

    • Consider use of e-Pricing Meta.

    • Consider separate PCCs for Metasite traffic.

    • Consider use of SCC to eliminate non-converting airlines.

  • High polling volumes cost the airlines who are likely to deactivate the messages thus resulting in lower quality availability.

    • e-Pricing Meta targets lower cost itineraries and generally provides 30-40% reduction in polling (and 30-40% reduction in response time).

    • A separate PCC allows different configurations for metasearch traffic and protects the agency mainline of business.

    • Some metasearch sites have direct agreements with airlines. The booking will not occur through the OTA. Blocking these provide bookable options.
• Flex Shopping:

  • Ensure flex results are shopped from, not booked from.

    • The legacy flex product offers an insight into where the cheapest flight options may exist.

    • Since there is no polling from shopping the availability used will be of lower quality.

    • This does not apply to Flex Explore which is a live search.

• Polling Management:

  • It is not recommended to request polling reduction in order to improve response times.

    • A reduction in airline polling will likely create a reduction in availability quality and an increase in sell failures.

    • The majority of time taken in Search is in the algorithm to determine the lower cost alternates.
    • Reducing this matrix by use of e-Pricing Meta or SCC is likely to improve response times.
    • Travelport is working on an overall program to reduce response times without a reduction in Search quality.

Review Flight Solutions

Transaction: Get flight results: LowFareSearchRsp

End User: Views flight solutions

UI/API: Receives and displays search response data

Recommendation:

• Cache search results for a period of time to redisplay to end user if required.

  • No cache should be built for same day or next day departure

  • Cache data should have expiry feature, shelf life set to X minutes

  • Suggestion X is driven by rule of thumb volatility (X is smaller 2 days out than 90 days than 180 days), for example:

    • Shelf-life set to 15 minutes for travel < 90 days from departure

    • Shelf-life set to 25 minutes for travel < 120 days from departure

    • Shelf-life set to 120 minutes to be the maximum

  • Response data should be cached and reused only for the same point of sale

  • Data should not be sliced and then combined by flights or outbound/inbound

• Use the Availability Source Indicator

  • The availability source indicator is returned by shopping in the response from Travelport.

    • It indicates where the availability of the flight came from (AVS, Seamless, Cache, etc.). This should always be passed back to Travelport in the sell request.

    • If the agency is using availability data not received from Travelport (own cache, etc.) there are corresponding indicators to set up.

  • The indicator is used as a debugging tool by Travelport when Bookability problems occur. It helps to locate the source of availability after a Bookability problem and speeds up problem resolution.

• Point of Commencement

  • If possible shop and book the whole itinerary in one sell message.   If the outbound and inbound are booked separately sell failures may result.

  • If the shopping transaction includes part of the trip and the sell contains the complete itinerary, sell failures may result.

  • Several airlines return different availability based on the start point of the whole itinerary.

  Terminal Example

  

• Date of Origin

  • If the shop includes part of the trip and the sell contains the complete itinerary, sell failures may result.

  • Several airlines return different availability based on the start date of the whole itinerary

  Terminal Example

  

 

Choose Flight Solution

Transaction: Start a session: BookingStartReq/Rsp

End User: Selects a flight solution

UI/API: Receives and displays search response data

Recommendation:

• Ensure Availability

  • The sell request always follows an Availability/Shopping request.

  • Fares displays do not check seat availability.

  • Flight availability should always be checked before sell. This can be completed via shopping or availability calls.

  • ‘Blind sells’ will always get unreliable results and lead to unnecessary alerts of problems at Travelport (examples of blind sells: cancel rebook, end and copy).

• Use neutral availability

  • It is preferable to use neutral availability, rather than direct access availability for carriers with a seamless agreement

  • Seamless polling messages are far more efficient than Direct Access queries and overuse of Direct Access raises the airline and GDS processing cost.

  • Direct Access queries generally cost the airline 3 times as much to process than a seamless query from neutral availability.

• Origin and Destination (O&D)
  • Any connecting flights required should be requested as such in availability/shopping.

  • Flight availability may be different if the flight connects to another.

    Terminal Example

    

• Point-to-Point (P2P)
  • Any connecting flights that were shopped as point-to-point must be booked as point-to-point.

  • Flight availability may be different if the flight does not connect to another.

    Terminal Example

    

Confirm Segment Bookability

Transaction: Confirm segment bookability: BookingAirSegmentReq/Rsp

UI/API:

• Goes to Price held solution
• Goes to Seat Request
• Redisplay cached search results and remove unavailable solutions.
• Error: UI - Sorry your selection/price is no longer available.

Recommendations:

• Point of Sale (POS):

  • The sell must always be made from the same PCC where the availability/shopping request was made.

    • Many airlines return different availability based on where the agency is based.

    • Inconsistencies in availability/sell POS can result in Bookability issues.

      Terminal Example

      

• Outbound/Inbound as Connection:

  • Application of connection indicators are for all flight segments in an outbound or all flight segments in an inbound.

    • The outbound and inbound should not be linked by connection indicators.

    • Airlines look at the origin and destination of the trip based on flight connection indicators.
    • If the indicators are set wrong, incorrect availability may be returned
    Diagram Example

    

   

Price held solution

Transaction: Price held solution: BookingPricingReq/Rsp

End User: N/A

UI/API: N/A

Recommendations:

• You can price to get the cheapest available price on the itinerary and then check seat availability or vice versa

• Avoid Mixed Classes

  • An agency using fares/availability to book an itinerary in multiple classes may break airline mixed class rules and so the sell will fail.

    • It would be best to use shopping entries when booking mixed classes.

    • Shopping takes airline mixed class rules into account, but availability may not.

  Terminal Example

  

Seat Request (Optional)

Transaction: Seat Request: SeatMapReq/Rsp

End User: Selects seats

UI/API: N/A

Recommendations:

• You need to decide in your UI whether a price change or unavailable seat changes the user flow

• No Time Delay

  • Complete the sell as soon as possible after the availability/shopping request.

    • The airline inventory levels are constantly changing, so a seat available at one moment may not be available in the next. A time lag between shopping and booking increases the chance of the seat becoming unavailable.

    • Optimal web-site design helps reduce time delays causing sell failures.

Error

Solution no longer available.

Path: Redisplay cached search results and remove unavailable solution.

End User: Views flight solution

Recommendations:

• Notify customer of error codes

  • On a sell failure notify the customer that the requested seats are no longer available rather than ‘try again’ type message.

  • Encouraging the customer to repeat a failing sell request may cause duplicate sell failures.

    Error Graph - Message Change on Sell Failure Rate

    This graph shows the effect of error message change on the sell failure rate. This is a large multiple Point of Sale OTA

    

Error Solution Processing

The following flowchart shows a potential error processing workflow

Enter Personal Details and Payment Information

Transaction: End Session with "Ignore:" BookingEndReq/Rsp

End User: Enter personal details and payment information

UI/API: Request user personal details and print information

Recommendations:

• User interface has time out of 15 minutes or less because the session times out in 15 minutes
• Avoid Sell/Ignore/Sell:

  • Avoid selling the flight to ensure it is available and then releasing it.

    • Even a test sell followed by an ignore can be harmful to results.

    • If an agency sells the flight, the inventory may not be released immediately by the airline (up to an hour), so a further sell request may fail.

   

Submit Personal Details and Print Information

Transaction: N/A: Customer authorizes end user payment.

End User: Submits personal details and payment information

UI/API: Sends user personal details and print information

Recommendation:

 

Receives Success Message and Booking Confirmation

Transaction: Confirm booking: AirCreateReservationReq/Rsp.

End User: Receives success message and booking confirmation

UI/API: Displays booking confirmation

Note: There is a change that between stopping the session and booking the fare that there may no longer be availability and/or that the seat may not be available.

 

Receives email or successful ticket confirmation

Transaction: Ticket Reservation: AirTicketingReq/Rsp.

End User: Receives email and/or successful ticket confirmation

UI/API: Emails / displays ticketing confirmation

Note: There may be an error that the solution is no longer available. Manual intervention is required on the PNR.