I 44 Booking synchronization management

I-44: Booking Synchronization Management

Description

The objective is to provide an interface that allows the Distributors and Allocators to keep the bookings and compensation claims in their systems up to date when changes occur on the Carrier or Allocator side. Possible changes include re-accommodation of a passenger by the Carriers because of a disruption. In case the passenger bought a through ticket, the Distributors can trigger a re-accommodation of the remain part of the journey. The interface can also be used by the ticket vendor to update the booking after a schedule is confirmed or when changes occurs in a group booking for instance. Distributors and Allocators need to be updated on decisions for compensation claims made by the Allocators and Carriers.

Owner

• Koffi Frédéric Konan (ETT / Amadeus)

Business Value

For a customer

who has booked at ticket and faces a disruption

the synchronization API

is a means of booking synchronization between carriers and distributors

that allows the distributor to inform the customer

unlike the current situation

our solution permits to support the customer in case of disruptions.

Business Outcomes

This solution improves the customer satisfaction by reducing the risk of having stranded passengers. If the passenger is reaccommodated, the railways undertaking reduces its financial loss as it may not need to give a financial compensation to the traveller. The solution can be used to keep the booking in the Distributor system up to date when changes occur to the booking in the Carriers system via channel that is different from that of the Distributor.

Leading Indicators

The early measures that will help predict the business outcome hypothesis. For more on this topic, see the Innovation Accounting advanced topic article.

To do

Nonfunctional Requirements

Nonfunctional requirements (NFRs) associated with the epic.

To do

Context

The request is in the context of the European passenger right regulation which provide the legal framework on handling passengers in case of disruption. We also considered scenario in which it was critical to keep the booking in Distributor System up to date.

Required for: I-39 paperless complaint management

Solution Design

• Event driven, push messages

• Flow: Inform authorized listener of the fact that changes has occurred. Then the listener has to call the carrier about the what has changed.

• Event types and their semantics:

  • Trip

    • TRIP_CONFIRMED - (use case: group booking)
    • TRIP_CHANGED - booking is still valid, but trip has changed, e.g. re-routing due to construction etc., even a simple delay
    • TRIP_CANCELLED - (use case: disruption, strike,..): trip no longer rideable, no alternative available

  • Booking

    • BOOKING_CANCELED - DELETE /bookings/{id}: pre-booking has either been cancelled by distributor or pre-booking has timed out

    • BOOKING_CONFIRMED - POST /bookings/{id}/fulfillments: booking has been confirmed

    • FULFILLMENT_REFUNDED - PATCH /bookings/{id}/refunds: either refunded by original distributor or (depending on agreements) other party

    • FULFILLMENT_EXCHANGED - PATCH /bookings/{id}/exchangeOperations: either exchanged by original distributor or (depending on agreements) other party

    • FULFILLMENT_FULIFILLED - PATCH /bookings/{id}/fulfillments: fulfillment has been fulfilled. Happens (for most providers) when BOOKING_CONFIRMED

    • FULFIILLMENT_CONTROLLED - only to be used when subsequent booking (e.g. train as "feeder flight") depends on use of the booking. Not to be used for "no refund after travel", as this decision stays with the provider/allocator

    • REFUND_INITIATED - refund initiated at provider level, e.g. at the station office. Needs to happen before travel. This implies releasing potentially booked places or ancillaries (e.g. meal).

    • BOOKER_CHANGED - PATCH /bookings/{id}/booker: name or contact data changed

    • PASSENGER_CHANGED - PATCH /bookings/{id}/passenger: name or contact data changed

  • Complaints

    • DECIDED - PATCH /complaints/{complaintId}: A decision on the complaint has been made
    • SETTLED - PATCH /complaints/{complaintId}: The complaint has been settled, i.e. a voucher has been issued or a bank transfer has been made
    • INFORMATION_MISSING - PATCH /complaints/{complaintId}: To make a decision additional information is needed.

• To verify whether a booking has changed on the distributor's side, a revision number (or timestamp) on the booking is required.

• Subscribing to event. A receiver has to provide

  • The events it is interested in. E.g. BOOKING, TRIP
  • The end point the events need to be sent to. E.g. https://trainline.com/api/webhooks/db
  • Sign message to guarantee that the sender is in fact who it claims to be. E.g. HMAC
  • IP whitelist

• The solution shall not be complex. :-)

Specification Effort: MIDDLE