Air Bookability Workflow 1 Best Practices: Shop Price Seat Pay

The "Shop Price Seat Pay" bookability workflow essentially allows a payment claim before committing to a booking. The basic bookability workflow steps are:

1. Low Fare Shop
2. Air Price
3. Add Seats and mandatory PNR Data.
4. Takes payment from customer
   1. If payment is confirmed, end the booking.
   2. If payment doesn't go through, release the seats back to the airline (perform an ignore).

 

A basic overview of the workflow is:

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 1 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

  

 

View Price

Transaction: View Price: AirPriceRequest/Rsp

End User: Select the best price for the journey

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

    

 

Begin a Session

Transaction: Start a session: BookingStartReq/Rsp

End User:

UI/API: Session opens to hold customer booking data to secure flight.

Recommendation: Be mindful of you time, as the session ends after 15 minutes of inactivity.

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

End User: Enter personal details and payment information

UI/API: Request user personal details and print information

Recommendations:

• User interface times out at 15 minutes or less if no input received.
• 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 Payment Information

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

End User: Submits personal details and payment information, and authorizes payment.

UI/API: Sends user personal details and processes payment information

Recommendation:

Note: At this point, the transaction will end with either an Ignore because of payment errors, or a successful "End Transact."

Error

Solution no longer available. Manual Intervention required.

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

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

Customer payment did not go through and no other payment solution works.

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

Path: Notify customer of failed booking. Seats are returned to airline.

End User: Reviews options and determines solution.

Recommendations:

 

Error

Booking created but payment declined. Booking held. End session with "End" and work with customer to get the payment in a different way within a certain time limit.

Path: Notify customer to contact agency.

End User: Contacts agency and produces alternate form of payment

Recommendations:

• This solution is often employed by smaller travel agencies or often by agencies in Eastern Europe or the Middle East.
• It is up to the individual agency if they want to offer this as a solution

Receives Success Message and Booking Confirmation

Transaction: End Session with BookingEnd Request.

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.