Journey Pricing Use cases


Parameters to test:

  • Price (One way tickets)
  • Roundtrip adjustment
  • SAME DAY Roundtrip adjustment
  • Open return price
  • Fare classes
  • Seat classes
  • Days of the Week (DOWS)
  • Amenity groups
  • Brands
  • Operating companies
  • Selling from Selling to
  • Trip from Trip to
  • Advance purchase

Trip prices

This case is to test the different combinations of prices on MP fare tables with or without modifiers and JP rules to a route, to see which has greater weight, and how they impact the sale process.

One way tickets

If you have prices in the MP fare table for a specific route, with or without MP modifiers, and a JP rule for it; the price taken for sales will be the one from the JP schema.

If you have prices in the MP fare table for a specific route, with or without MP modifiers, and no JP rule for it; the price taken for sales will be the one from MP fare table with ro without its modifiers.

Roundtrips tickets

MP vs JP

  • The first trip price was taken from the JP schema, both price and roundtrip adjustment, but the return trip price was taken from the MP - fare table (if there was a modifier, it would also be applied to the final price)

MP vs JP

  • The first trip price was taken from the MP fare table (if there was a modifier, it would also be applied to the final price), but the return trip price was taken from the JP schema, both price and roundtrip adjustment.
  • If there is no “Roundtrip adjustments” configured, it will just take the price from the “Price” column of JP.
  • If both trips have JP and no MP, JP prices will be reflected on the sales flow.

Same behavior for Same day return trips and open returns.

Seat classes

This case is to test which parameter between MP and JP have greater weight when setting prices, and how they can be impacted by seat classes configuration.

Important to consider!

Seatmaps has to be set up correctly

Schedules also has to consider seatmaps

In this scenario, we have Market Pricing product that works with modifiers and fare tables according to seat class

MP Fare table with two seat classes: "VIP" and "Normal" (Example route: Lima to Trujillo)

Fare tables

Modifier to add complexity.

(Example: adding 2 for a One way)

MP Modifier

Example 1:

Trip: Lima - Trujillo

Seat class: Normal

Price: $50

MP Modifier: +2 for a one way ticket

Normal price

Result on sales:

We have a ticket that costs $52, validating all the configuration

Sale

What would happen if there is a JP rule that impacts a route/schedule that works for MP?

Example 2:

We configured a JP rule for the same route with a price of $45.

Also, we add Product Properties that considers:

-Any product (market pricing and journey pricing)

-Seat class: Normal

Product properties

Proceed to save the changes, or add some more properties, and try to buy a ticket.

JP

Go and try to buy the same ticket.

JP vs MP

Now it is only considering the JP rule that was configured, invalidating the rules configured for MP.

In case you are using Seat Classes for one rule, you should create rules for all the Seat Classes available or select the "Any" option on the configuration:

Example 3:

  • In the Seat Class configuration we have two classes, "Single" and "Double"

Seat classes

  • Created a JP rule with only one seat class in the configuration:

Wrong configuration

When creating a JP rule with only one of the seat classes that are in the configuration, you will have results on the "Select trip", but you will not be able to choose a ticket:

Seat error

You will always need to consider all the seat classes previously configured to be in the JP rules that are going to be created, so you will get the prices and results in the sales flow.

Days of the week (DOWs)

This case is to test how using DOWs configuration is impacted between MP and JP configuration to see which has greater weight when setting prices.

Example:

We have set to a specific route, a DOWs parameter to only be available 3 days of the week (Friday, Saturday and Sunday).

DOWs

  • MP fare table price: $44

MP fare table

  • JP rule: $25

JP rule

Go and look for a trip on day out of the configuration selected.

  • Example "Tuesday"

MP fare table

We can see that the price pulling is from the MP fare table

If the search date is change to a weekend day, "Saturday", the price pulled is from the JP rule

JP

Same behavior for Amenity groups, Brands and Operating companies as a parameter to work only in those selected cases

Advanced Purchase

ADVANCE PURCHASE FROM and ADVANCE PURCHASE TO define a time interval (in hours). This Journey Pricing Rule will only target purchases made at least ADVANCE PURCHASE FROM hours and at most ADVANCE PURCHASE TO hours before the trip departure date. For example, if ADVANCE PURCHASE FROM = 0 and ADVANCE PURCHASE TO = 0, this Journey Pricing Rule will only target purchases from 0 - 0.99 hours before the trip departure date. If ADVANCE PURCHASE FROM = 0 and ADVANCE PURCHASE TO = 1, this Journey Pricing rule will only target purchases from 0 - 1.99 hours before the trip departure date. (a value of ‘0’ means ‘within 1 hour of the trip departure date’). Leave ADVANCE PURCHASE FROM and ADVANCE PURCHASE TO empty to target all advance purchase periods.

For negative cutoff times, where you can sell tickets past the departure time, the price applied will be the same as ADVANCE PURCHASE FROM = 0.

Date Ranges Configuration:

JP pricing:

JP

  • Advance Purchase changed from 3 to 4 hours

Date window

The ticket price during only those previous hours set in JP configuration will cause the ticket price to change to $25.

JP results

If looking for a ticket out of the hours configured for the JP rule, it will pulled the MP table fare prices, $44

MP results

Selling from (mm/dd/yyyy) and Selling to (mm/dd/yyyy)

Change Date ranges Selling from (mm/dd/yyyy) and Selling to (mm/dd/yyyy) you have to set the hours too, otherwise by default it takes 12:00 am

Selling

Important to consider:

If this window is used, the time fields must be set to the GMT time of the account. If CSV file uploading is used, the time fields should be set to GMT 0 time.

Always JP will weight more over MP configurations as they are part of the same type of configuration family.