I 46 Change of seat after booking

I-46: Change of Seat after Booking

Description

The purpose of this change request is to add the support of seat change after booking is confirmed. Currently in OSDM, it is possible to specify seat preferences at provisional booking time. This change request will the extent the API to include the possible to request a change of seat after the booking is confirmed and fulfilled. As some providers will charge the customer for a seat change, the API will provide the possibility to request the price to be paid for a seat change. We can have the following scenario.

1. Specific seat and coach requested. Optionally, a seat map can be requested, so that the user knows which seat is available. The user can then select a specific coach and seat number.
2. Near to a given seat. The user provides in the request a seat number he wishes to be seated next to.
3. Seat preferences. The user provides seat arrangement such as window, aisle etc…

It was noted that some providers give the possibility to upsell to a better seat after booking. This is an adjacent but not equivalent case, as the change of seat should not affect allocation or update the inventory.

Owner

• Roland Klapwijk (Sqills)
• Koffi Frederic Konan (ETT/Amadeus)
• Stina Carlstedt (SJ)

Business Value

The provider can get additional revenue by taking a fee when the customer requests a seat change. The traveler gets more flexibility as he can change his/her seat to be next to a travelling companion or to have a better seating arrangement.

Business Outcomes

Increased revenue for the provider and increase customer satisfaction and retention.

Leading Indicators

N/A

Nonfunctional Requirements

Nonfunctional requirements (NFRs) associated with the epic.

N/A

Implementation ideas

Change the place selection of a reservation

A seat change impacts the allocation but does not impact the booked offer or underlying tariff. Therefore, is not regarded as an exchange operation where the original offers is replaced by a new offer.

The reservation contains a place selection, which the passenger is able to provisionally change. This can lead to a fee or unrefereed seat and must require a confirmation prior to the take the change into effect. Provisional changes must be able to be reverted, if the passenger is not willing to pursue the change.

Introducing a reservation resource in booking context enables methods to change the place selection (e.g. patch) or revert the provisional change (e.g. delete / specific endpoint to revert the provisional change).

Optional fee

The result of the provisional seat change fee must be exposed in either:

• in the response of the patch operation
• if the patch operation returns no json response, a get booking request must be made

The confirmation of the seat change implies an agreement of the fee.

Change confirmation

Confirmation of the seat change can result in new fulfillment(s) with new ticket control numbers (TCN). The OSDM consumer should retrieve the new fulfillment using the dedicated resource.

Seat map support

To support the seat change, a seat map function should be introduced that returns:

• coach(es) of the itinerary (based on e.g. tripId and legId)
• for each returned coach the seat(s) and its details including information to render on the floor map like
  • sequence number
  • dimensions in pixels
  • facing direction
  • attributes
  • etc
• status of each seat preventing passengers selecting a seat that is already occupied
• ability to render/display floor map

In extension of the seat map introduction, OSDM consumers can introduce functionality to upgrade (or downgrade) using the seat map by selecting a seat in a different inventory class, as currently supported by Turnit. E.g. a passenger having a second class ticket could select a seat in the first class coach. This requires client logic to perform a trip-offer-collection request in the background and display the offer, followed by an exchange operation. This exchange follows the conditions of the original product and is not inventory neutral as the seat change functionality itself is.

Solution proposal

We propose to see all changes as exchange, but use dedicated structure for non-trip-related changes

Pros:

• Uniform, easy for consumer as everything is an exchange flow
• financial impact guaranteed to be taken into account through the existing exchange structure
• Because we use another structure in the exchangeOffer request (a changeRequest instead of a tripofferRequest),we are not held by the constraints specific to an exchange, and for the OSDM provider, it is easy to see the intent of the consumer (= change something on the existing trip, not the trip itself)

Cons:

• In some cases the offer step may seem useless.

Changes needed to the specifications to make it work

• add a "changeRequest" next to tripOfferRequest, describing the change. Using this implicitly means you do not want to change trains, only seats (or potentially fares) or even just passenger details
• add an attribute in the exchangeTRipOffer to indicate whether it is an operation considered an exchange or a change to an existing booking
• add a passengers section in the exchangeOperation, to later hold potential provisional passanger data changes (which will be copied in teh booking itself once confirmed, as the exchange offers already are)

Other catches during the analysis

• PlaceSelection on the patch booking must be an array
• booking state model to be updated (exchange ongoing is not represented)