Green Time Slots - Class and Price

This article will explain in more detail the functionalities of Green Time slots and how they are chosen and configured.

Up to now, we offered time slots based on various constraints as seen below:  

But now the new Green Time slots (GTS) allows us to associate a class and price with them:

The class represents the efficiency of the time slot and the Price represents the cost.

Time slots that are the most efficient will also be marked by the hint text: "Most efficient time slot"

How to configure GTS for a platform

In order to have the GTS configured on your platform, you need to contact your CSM to set up the GTS together and decide on the details of classes and prices. 

What does the number of time slot classes mean?

If GTS is enabled, the offered time slots for a platform will be categorized under various classes - 2 to 10 time slot classes can be configured which means that if 2 classes are configured, each time slot will have a class between A and B; if 3 classes are configured, each time slot will have a class among A, B, and C, and so on.

Classes tell us which time slot is better, for instance, a time slot marked as class A will be better in terms of efficiency than the one marked as B or lower. 

Notes:

• It is possible that among the time slots that were offered, none of them had class A or B or some other specific class, i.e. the classes associated with the offered time slots can be any class in the set of classes.
• If the first class available for the offered time slot is "C", that becomes our "first best option" and is hinted with "Most efficient time slot" in the UI.
• Classes offered can be discontinuous, i.e. it is possible that the first class present in the time slot offered is "C" and the second class present is "E" (given the number of time slot classes defined for the platform >= 5). In that case:
  • C = first best option (Most efficient time slot)
  • E = second best option

What is the pricing model

The pricing model tells us how to calculate prices for a time slot. Pricing models are defined for one or more hubs, and are unique to them, i.e. two pricing models can not be defined for the same hub. Pricing models are identified by their name and they consist of pricing segments.

A pricing segment is identified by its name as well. It defines a baseline price, to be applied to a time slot when conditions are met. A pricing segment can be applied for all orders or can be conditioned based upon metadata of the platform. A pricing segment can have multiple Pricing rules.

A pricing rule is identified by the criteria it applies and it does not have a name. It contains criteria based on which we know if the rule will be applied or not to the pricing segment, and it defines how to modify the baseline price, in case it were to be applied, by defining operation and amount.

Let's take an example of the following pricing model:

This pricing model is identified by the name "Test model" and is applied for hub "IKEA 2", and contains only one Pricing segment, which is identified by the name "Test segment".

Test segment contains only one rule which is identified by the criteria it applies, i.e. "Atest: equal to B2B"

Taking a closer look at the pricing segment "Test segment" we see the following:

This means it is a pricing segment which is going to be applied on all orders, and will set a baseline price of 100.

Note: Prices are set in the platform currency.

This means if we were to fetch time slots for hub "IKEA 2" we should see all time slots having prices as 100, which is the case:

Taking a closer look at the rule defined for the "Test segment" we see the following:

This means if we have metadata "Atest" set to be "B2B", this rule will add 20 to the baseline price, making it 120. So if we set metadata "Atest" to "B2B" in our task addition UI:

The prices should go up to 120, which is the case:

You can also define the rule based on the class options:

This way the prices will be modified based on the class associated with the time slot instead of the metadata of the platform.

Reordering

Note that you can change the order of pricing segments under a pricing model or order of pricing rules under a Pricing segment. This is represented by two horizontal lines in the UI:

The order in which you define your pricing rules or segments is important because they are applied from top to bottom. So, for example, let's say you have 2 rules defined:

1. Add 20 to the baseline price
2. Divide baseline price by 5

If your baseline price is 100, it will do (100+20) / 5 = 24.

Whereas if the order of the above rules was reversed, the final price would be: (100/5)+20 = 40

API Changes

If a platform has GTS configured, not only their task addition, edition, and replan UI will reflect the changes and show time slots with classes and prices, but they will also receive this information when querying the time slots via API (get time slots):

Example response for GET time slots API call:

Along with class and price, we have also added a new information baselinePrice which helps understand that some rules were applied that resulted in the modification of the final price.