User Guide Airnguru - 8 Jun 2019 Backup

User Guide
Airnguru Price Awareness and Execution Suite
Jun 7th, 2019
“ Speed is the essence of war. Take advantage of the enemy’s

unpreparedness; travel by unexpected routes and strike him
where he has taken no precautions. “
- Sun Tzu , The Art of War
© Airnguru confidential material

1
Table of Contents
GENERAL CONCEPTS
COMMON FEATURES, CONCEPTS AND ASSUMPTIONS
FARE VISUALIZER MODULE

Objective of Fare Visualizer Module
Usage
Execute a Query
Reading the results
User Interface Functionalities and Links
List of fields
MONITORING MODULE
Objectives of monitoring Module
Usage:
Filters
Tag changes
Business Rules
COMPETITIVE ANALYTICS MODULE: Segmentation Heatmap

Objectives of Segmentation Heatmap
Segmentation Heatmap usage
How to read the Segmentation Heatmap matrix
Segmentation Heatmap Matrix components
Price list
Filters
Self Compare functionality
COMPETITIVE ANALYTICS MODULE: Schedule Heatmap

Objectives of Competitive Analytics: Schedule Heatmap
Schedule Heatmap usage
How to read the Schedule Heatmap matrix
Schedule Heatmap Matrix components
Price list
Filters
PRICING WORKFLOW
Pricing Workflow objectives
Fare Builder
Generating a new request in Fare Builder
Adding fare changes with Fare Generator
Import fare changes from Fare Visualizer into a request in Fare Builder
Import fare changes from Monitoring into a request in Fare Builder (Fare Mapping)
Fare Builder Validations (pre-publication checks)
Other Fare Builder functionalities
Fare Simulator
Filters
Footnote designator
Publishing Manager

2
Write a comment in a request
Edit a Request
Publication to ATPCO
Notifications
Notification emails
Red bubble (push notifications)
Pricing Compass
Delegates
TRENDS MODULE
Objectives of Trends Module
Filters
Charts
Overview panel
PRICING COMPASS
Objectives of Pricing Compass
Pricing Compass usage

3
GENERAL CONCEPTS
Airnguru Price Awareness and Execution Suite is a cloud based pricing

intelligence platform, composed of eight integrated user modules: Trends,
Competitive Analytics, Fare Visualizer, Monitoring, Pricing Workflow,
Performance Analysis, Commercial Metrics and Pricing Compass. Plus, the
Airnguru Pricing Engine (back-end price computation module) which feed with
fare information the suite’s modules and data feeds for the Airline’s data
warehouse and RM systems.
The main inputs for the system are
- Hourly ATPCO filing data stream.

- Exchange rate feed from https://openexchangerates.org/
- Monthly (or weekly) Itinerary feed from Innovata
- Monthly Tax information from IATA (TTBS feed)
- Web-scraping data feed (e.g Infare) (optional)
- Commercial metrics provided by the Airline (optional) (i.e Revenue, Pax,
Avg Fare, QSI, Market Share, etc…)
Airnguru processes the ATPCO data stream on an hourly basis, interpreting all
the relevant ATPCO fare rules and categories that affect the final published fares
of the airline and its competitors (optionally, incumbent’s private fares can be
included in some of the modules) for every origin-destination of the airline’s
markets. After performing the corresponding computations, it feeds all modules
with the relevant information.
Airnguru’s philosophy is to analyze the price data at the demand segment level.
Airnguru transcribes and interprets fare rules and builds and computes the lowest
applicable “all in” (*) prices of the incumbents (an airline group may be constituted
by more than one incumbent) and its competitors for every non-stop and one-stop
(max 200% circuitry) round trip demand segment in every origin-destination of the
incumbents’ markets, regardless of itinerary or inventory availability constraints.
These prices are computed from OWD, RT and OW ATPCO published fares
calculating P2P and in some cases Constructed fares and Fare by rules.
Airnguru also stores the past processed ATPCO data streams (“timestamps”), so
the user can analyze historical data.
COMMON FEATURES, CONCEPTS AND ASSUMPTIONS

4
Incumbent: By default, it is defined as the user’s airline or group of airlines. In the case of
Competitive Analytics, the user may select in the filter section any of the displayed airlines as
incumbent, in order to see the competitive position of any carrier in relation to the market.
Demand segment: It is defined as a specific combination of advanced reservation date and

traveling period.
Timestamp: A timestamp corresponds to an hourly ATPCO update, which is processed by the

Airnguru pricing intelligence engine immediately upon arrival to its servers. Airnguru keeps a
certain number of historic processed timestamps so that they can be accessed by the user to
analyze historical data. The Timestamp is specified with a date and time. The time corresponds
to US Eastern, Washington DC time. The ATPCO hourly updates are produced within the
specific time ranges corresponding to the day of the week and special dates, as defined by
ATPCO (http://atpco.net/products/data-distribution/schedule-electronic-transmissions):
Point of Sale (“POS”) assumption: The assumption POS = POC (Point of

Commencement) is made for the calculation of all the valid prices
Published or Public fares: ATPCO fares made available to every airline that contracts
ATPCO subscriptions
OW, RT and OWD: OW = one-way fares (ATPCO TAG3); RT = round trip fares (ATPCO
TAG2); OWD = one-way duplicable fares (ATPCO TAG1)
Filter: In most of the modules, a query will be required for the user to fill certain
parameters, and then press the “GET” button shown in the image below.

5
Treatment of exchange rates: All modules require the use of historic and current
exchange rates in order to compare prices on an equal basis. Airnguru uses an hourly
exchange rate service for calculations performed after January 1st, 2015 (and daily
exchange rates before that date). In Competitive Analytics, by default, all prices are
expressed in the “mode” currency among the currencies of all fares applicable in the
corresponding segmentation matrix. In Trends, by default, all currencies are converted into
USD.

6
FARE VISUALIZER MODULE
Objective of Fare Visualizer Module
Fare Visualizer allows the user to explore the full market fare structures through a
powerful window into the Airnguru’s fare database, including the rules/categories. A
certain number of historic timestamps are also available. Fare Visualizer also allows the
user to visualize the transcription of each of the fare components, in an isolated fashion
(for example, look at the interpretation of Min Stay by itself), with a tax transcription and
on a simplified segmentation matrix, for a better understanding of their impact on the
applicability of the fares across the segmentation matrix.
Usage
Execute a Query
The Fare Visualizer module contains two sections: Filter and Fares.
Filter Result Table
To execute a basic query, the user must complete fields Origin and Destination and
Carrier on the Filter section. The user is free to write one or multiple inputs in each field.
The timestamp used to query the results will be the last sub updated in the system
(system information is updated every one hour with the last sub received from ATPCO)
If the user wants to execute a more specific query, it can be done with the following filters:
Filters:

7
Timestamp: it is the only required filter.
Select an ATPCO timestamp (see definition
in Transversal functionality…)
Origin (Destination): select the level of
aggregation (City/Airport or Country) and
use three letter nomenclature to specify
cities or specific airports, separated by
commas. Use two letter nomenclature to
specify countries, separated by commas.
Predefined markets: select the desired
Predefined market (a group of OD’s and
carriers previously created in settings) to be
used for the query. In case the user selects
a Predefined market, the option to select
Origin and Destination will disappear.
Empty filters: The user can leave any filter
empty, except for Timestamp. Leaving a
filter empty is equivalent to not applying the
filter.
Tariff number: The user can filter one or
more specific ATPCO tariff numbers
Travel type: The user may select one or
more among OW, RT or OWD to filter one
way fares.
RBD: it’s used to specify one or more RBDs
(separated by commas) in order to filter the
corresponding fares
Fareclass: is used to filter fares by
specifying full fareclass names (separated
by commas), or wildcards. For example:
- ABCDEF: just shows the fares with
fareclass named “ABCDEF”
- W%: Selects all fares with fareclasses
that begin with character “W”
- %W%: Selects all fares with fareclasses
that contain character “W”
- %W: Selects all fares with fareclasses
that end with character “W”
- __WN% Selects all fares in which the
third character is equal to W and the
fourth character is equal to N

8
OW/RT: OW, RT, OWD selector
RBD: RBD selector (it supports multiple
inputs)
Tariff number: Tariff number filter, it
supports multiple tariff numbers.
Tariff code: Tariff code filter, it supports
multiple tariff numbers
Currencies: Currency filter, it supports
multiple currencies
Has Footnote?: Flag that if selected
“Yes” will bring only fares with footnote, if
selected “No”, it will bring only fares
without footnote
Footnote: the user may filter fares by
specifying the footnote code(s) to look
for corresponding sales/flight dates
Rule Number: Rule Number filter, it
supports multiple Rule Numbers
Cabin: Cabin selector

9
Filter expired fares: Flag that indicates
if expired fares will be filtered out.
Include Constructed Fares: Flag that
indicates if constructed fares will be
included in the results
Calculate Fare by Rule Fares: Flag that
indicates if Fare by Rule will be included
in the results. If “Yes” is selected, the
user must specify an origin, destination,
carrier and Account code
Account Code: This field will only
appear is the user has selected “Yes” on
“Calculate Fare by Rule Fares”. It’s
mandatory and it refers to the Account
Code of the Fare by Rule that will be
calculated.
All fields market with * are mandatory
Reading the results
The module will show results in a tabular fashion, it will also show visual information using
segmentation matrices (see “common features, concepts, and assumptions”). Following
are the main functionalities and format used in the module:
Fare fields: look at the transcribed values of the fare fields. When they contain “-, it means
there is no rule applying for that category and a “+” means the field may contain additional
info in ATPCO. In the future, additional text will be optionally supported for complex fields
(airline must contract the ATPCO Text Rules File).
Graphical rule display: by clicking a row in the Fares section and then a specific field
“show” tag, the user may visualize the interpretation of each of the fare components that
affect the price across the segmentation matrix, in an isolated fashion (for example, look at
just the interpretation of Min Stay), on a simplified version of the segmentation matrix. This
helps the user to get a better understanding of the impact of each rule on the applicability
and value of the fares across the segmentation matrix

10
Dates format: Date fields are displayed according to the following format (YY/MM/DD). If
the year is not specified, it is displayed as “YY/01/10”
Point of Sale format: Shows the included POS and with “- ” the excluded POS. For
example, tickets may be sold in A1, A2, A3, but not in (AO, IR, NG, SD, VE).
Blackout and seasonality tooltip: hover over the “👁” icon or press “details” to see more
information. In the Seasonality tooltip date ranges are classified as “FC” or “PU” (FC
means “Fare Component” and PU means “Pricing unit”).
ATPCO Sub Datetime: Corresponds to the publishing date and hour of the record in
ATPCO.

11
User Interface Functionalities and Links
Pagination of fares: each page supports 200 fares, in order to see more fares click the
page number or right arrow at the bottom of the Fares section:
Export to excel: Download up to 30.000 lines of fare data by clicking the “download”
symbol on the top-right of the screen.
Export to Fare Builder: (See Fare Builder)
List of fields
PF: Private Fare indicator

CF: Constructed Fare indicator
Fareclass: Fareclas (Farebasis code)
Origin ATPCO: Origin of the fare as in ATPCO country/city iata code
Dest. ATPCO: Destination of the fare as in ATPCO country/city iata code
Carrier: Carrier Owner of the Fare
RBD: Reservation Booking Designator of the Fare
Cabin: Cabin code
OW/RT: One Way, Roundtrip or OW Double indicator
CUR: Fare Currency
Base Price: Base Price of the Fare
Q. Surcharge: Q surcharge (Category 12)
YQ/YR: YQ/YR carrier-imposed fee
YQ & Q ITIN: Itinerary used to estimate YQ/YR and Q surcharge, this is the shortest itinerary possible.
RTG+FL: Routing and Flight used to estimate YQ/YR and Q surcharge
Total Price: RT price of Base Price + Surcharges
Total Price per Direction: Total Price/2
Air Taxes: Tax estimation of the fare applied on the shortest itinerary possible.
FN: Footnote
Routing or Miles: Routing number of the Fare
Rule Number: Rule Number of the Fare
Effective Date: Effective date of the Fare
Discontinue Date: Discontinue Date of the Fare
Seasonality Type: Seasonality Type (e.g: L,J,H)
Fare Type: Fare Type of the Fare
Day of Week Type: Day of Week type (eg: X)
POS: Point of Sales where the fare can be offered

12
First Sale: First Sale date permitted for the Fare (taking into account Footnote and Rule restrictions)
Last Sale: Last Sale date permitted for the Fare (taking into account Footnote and Rule restrictions)
First Travel: First Travel date permitted for the Fare (taking into account Footnote and Rule restrictions)
Last Travel: Last Travel date permitted for the Fare (taking into account Footnote and Rule restrictions)
Travel Complete: Travel Complete date permitted for the Fare (taking into account Footnote and Rule restrictions)
ADV. Res. : Advance Purchase restriction (CAT 5)
Min Stay: Minimum Stay Restriction (CAT 6)
Max Stay: Maximum Stay Restriction (CAT 7)
DOW Outbound: Day of Week Outbound restriction (CAT 2)
DOW Inbound: Day of Week Inbound restriction (CAT 2)
Blackout Outbound: Blackout Outbound restriction (CAT 11)
Blackout Inbound: Blackout Outbound restriction (CAT 11)
Season Outbound: Seasonality Outbound restriction (CAT 3)
Season Inbound: Seasonality Outbound restriction (CAT 3)
Tariff Number: Tariff Number where the Fare belongs
Tariff Code: Tariff Code where the Fare belongs
GFS Fan: GFS Filing Advice Number
GFS Date: GFS Date
Origin City: Origin City of the Fare
Dest. City: Destination City of the Fare
Origin Ctry: Origin Country of the Fare
Dest Ctry: Destination Country of the Fare
Link Number: Link Number of the Fare
Sequence Number: Sequence Number of the Fare
Orig Add-On Gateway: Origin Add-on Gateway (only for constructed fares)
Orig Add-On Cur: Origin Add-on Currency (only for constructed fares)
Orig Add-On Amount: Origin Add-on Amount (only for constructed fares)
Orig Add-On Fareclass: Origin Add-on Fareclass (only for constructed fares)
Orig Add-On RTG: Origin Add-on Routing (only for constructed fares)
Dest Add-On FN: Destination Add-on Footnote (only for constructed fares)
Dest Add-On Gateway: Destination Add-on Gateway (only for constructed fares)
Dest Add-On Cur: Destination Add-on Currency (only for constructed fares)
Dest Add-On Amount: Destination Add-on Amount (only for constructed fares)
Dest Add-On Fareclass: Destination Add-on Fareclass (only for constructed fares)
Dest Add-On RTG: Destination Add-on Routing (only for constructed fares)
Dest Add-On FN: Destination Add-on Footnote (only for constructed fares)
FBR Base Fareclas: Fare by Rule Base Fareclass (only for Fare by Rule fares)
FBR Base Price: Fare by Rule Base Price (only for Fare by Rule fares)
FBR Base Price: Fare by Rule Base Price (only for Fare by Rule fares)
FBR Discount: Fare by Rule discount % respect to original fare (only for Fare by Rule fares)
FBR Base Price: Fare by Rule Account Code (only for Fare by Rule fares)
ATPCO sub: ATPCO sub timestamp
MONITORING MODULE
Objectives of monitoring Module
Allows to review fare, footnote and rule changes occurred in a period of time
Monitoring allows the user to identify changes in fare records, rules, and footnote
definitions.
The type of changes shown are indicated in the field “C. TYPE” (Change type):

13
F: Fare records change
R: Rule(Category) change
FN: Footnote change
On field “CHANGES” the specific type of change is shown with a code, some examples
are:
N: NEW
C: Cancel
I: Increased
R: Reduced
RIS: Reissue
RIN: Reinstatement
FN: Footnote
Cxx: Change in category xx (e.g C12 is a change in category 12, which is Surcharge)
Fxx: Change in footnote category xx (e.g F14 is a change in Travel Restriction
if the change is other than “NEW”, a plus (+) sign will appear on the left side of the row, if
the user clicks the + sign, a second row will be opened, showing the previous state of the
fare before the change.
All change types are selected by default, but if the user, for example, wants to only query
rule (category) changes, for example, she can deselect Fare and Footnote change type
on the filter.
The user has the option to select a specific group of origins and destination or using a
pre-defined market to execute a query.

14
Usage:
Te module has two sections: Filter and Change list:
Filters Changes List
Excel
file Ta Fare
donwl g Mapping
Real time oad Apply
and link to
alerts Filter
Fare
notificatio
Clear Builder
n
Filter Current
Real fare
time state
alerts
flag Previou
s fare
state
Pag
es
In order to generate a basic query, the user must:
Step 1: Specify on the filters a Pre-defined market or a group of origins, a group of

destination, and a group of Carriers. (Monitoring allows the user to execute open queries,
so if the user leaves everything blank, the system will bring all changes of markets in
which the airline has fares published.
Step 2: Click on GET
If the user wants to execute a more advanced query, for example, only query a Cabin Y
and fares that have 2nd and 3th characters FF:
Step 1: Specify on the filters a Pre-defined market or a group of origins, a group of

destination, and a group of Carriers.
Step 2: On filter “Fareclass” type _FF%
Step 3: Click on GET
Filters

15
Filters on monitoring are very similar to the ones in Fare Visualizer, here is a description
of each of them:
Timestamp range: Will determine the time

window for which the system will show the
changes. By default, it will search from the
last loaded timestamp in the system to 24
hours in the past.
Effective date: Filters fares with effective
dates within the indicated timestamp. by
default it’s open
Predefined markets: select the desired
Predefined market (a group of OD’s and
carriers previously created in settings) to be
used for the query. In case the user selects
a Predefined market, the option to select
Origin and Destination will disappear.
Origin (Destination): select the level of
aggregation (City/Airport or Country) and
use three letter nomenclature to specify
cities or specific airports, separated by
commas. Use two letter nomenclature to
specify countries, separated by commas.
Carrier: Carrier for which changes will be
queried (if empty the query will look for all
carriers)
Fareclass: is used to filter fares by
specifying full fareclass names (separated
by commas), or wildcards (see Fare
Visualizer)

16
OW/RT: OW, RT, OWD selector
Base price thresholds: Determines a
threshold for which we search for Increased
and/or Decreased amounts or percentage
changes
Change type: Fare record, Footnote or Rule
change selector
Changes: Specific change type selector
Footnote: Footnote code(s) selector
Tariff number: The user can filter one or
more specific ATPCO tariff numbers

17
Tag changes
Monitoring module also allows the user to tag changes to identify if those changes have
been “worked”, “dismissed” or if they are “pending”. In this way, the user will be able to
resume her work from a previous session and see which changes she has already
worked on.
To apply a tag, the user must select the change by clicking on the box and then click
, and then select any of the tags available.
These tags will remain with their corresponding changes and will be shown on the
“status” field
Business Rules
The user also can configure business rules to trigger real-time alerts that will send an e-
mail to the user as soon as the system detects a change falling within such rules. To
create a new business rules go to Setting-> Business Rules -> New

18
New
Busine
Busine
ss
ss
Rules
Rules
Settin
gs
A window to set the business rule will open with the different options that can be
configured:
Name: Name of the business rule

Description: Description of the business rule
Predefined markets: PRedefined market to which the business rule will apply
Origin: If a Predefined market is not selected, this field is mandatory and it will indicate
the group of origins (Airports/cities or Country may be selected) to which the business
rule will apply
Destination: If a Predefined market is not selected, this field is mandatory and it will
indicate the group of destination (Airports/cities or Country may be selected) to which the
business rule will apply

19
Carrier: The group of carriers (Carrier 2 letter Iata Code) to which the business rule will
apply
Travel type: Type of travel to which the business rule will apply, this refers to the travel
type specified in the fare record.
Cabin: Cabin to which the business rule will apply
Fareclass: Fareclass to which the business rule will apply.
In the Fareclass field, wildcard characters can be used:

"_" : The underscore character represents any character for that position in the fareclass
text and can be put in any position of the text.
"%": The percentage character can be at the beginning or at the end of the text and
represents that the fare class can end with any text string before or after the percentage
character's position.
Example: AB_____K : This is a fareclass that begins with "AB", ends with "K" and is 8
characters long.
Example: BB___T% : This is a fareclass that begins with "BB", has the 6th character
equal to T and can contain anything after character T.
Example: __BB% : This is a fareclass in which the second and third characters are "BB"
and has
any length.
RBD: RBD to which the business rule will apply
Type of Change: Type of changes the business rule will detect
If “Increased” or “Decreased” options are selected, the system will offer the option to
apply thresholds to facilitate the user to only trigger movements above or below a desired
delta amount or percentage.

20
Base Price/ Base Price+Q/YQ estimated: Selects if the threshold will be activated by
Base Price or Base Price + Q/YQ
Amount: Currency selector to be applied to the amount threshold.
Increase: More Than: The user has the option to select a percentage change or amount
change threshold on the increased movements
Decrease: More Than: The user has the option to select a percentage change or amount
change threshold on the decreased movements
Include Competitive Threshold Flag: To be included in a future version
Priority: This will help the user to prioritize in other modules of the tool the changes that
are more important to her (Priority = 1 is the highest)

21
Notifications: The option “Send email and show alarm count on screen” must be
activated in order to start receiving the real-time alerts, if this is not selected, the user will
only see these alerts flagged on the modules but it will not be alerted.
The real-time alerts will be sent an email such as this one:
The email contains relevant information

about the alerts that have been triggered.
Enough for the user to understand is she
has to react or take any other
measurement. The email shows:
- Overview of alerts triggered by priority

- Overview of alerts triggered by change
type
- Alerted markets, and how many alerts
by each market in parenthesis
- Detail of first 20 alerts triggered
Beside the email alert, the user will be

alerted via two other channels within the
tool, the first one is with a red bubble on
the left menu, this alerts will be updated
every 2 minutes.

22
If the user clicks on top of the red bubble, the system will automatically query only the
changes that have been triggered as alerted.
The second way in which the user will be alerted is via the Pricing Compass view (which
is an overview of all the system’s metrics including changes). On the top left side of the
panel, an overview of the current alerted changes will be displayed.

23
COMPETITIVE ANALYTICS MODULE: Segmentation
Heatmap
Objectives of Segmentation Heatmap
The objectives of Segmentation Heatmap include helping the airline explore and
understand its competitive positioning by demand segment and visually discover
opportunities to reduce market share losses (when the incumbent is too expensive) and

24
dilution (when the incumbent is too cheap) arising from fare gaps at the demand segment
level.
A secondary objective of Segmentation Heatmap is to provide a “self compare” matrix

view, where the user can read, in any demand segment, for a specific carrier, the ratio of
the lowest price applicable to that demand segment to the lowest price applicable over all
the demand segments of the chosen origin-destination.
By “demand segment” we mean a combination of advanced reservation (days) and

traveling period (days).
Segmentation Heatmap interprets ATPCO fare rules and builds and computes the lowest
applicable “all in” (as of December 2015 does not include airport taxes) prices of the
incumbents (an airline group may be constituted by more than one incumbent) and its
competitors for every possible non-stop round trip and one-stop round trip (200%
maximum circuitry) demand segment in every origin-destination of the incumbents’
markets. These lowest prices are computed from RT, OW and OWD ATPCO published
fares and all their valid combinations to produce non-stop round trips. Specific itinerary
information is not taken into account, neither is availability information.
Competitive Analytics also stores past processed ATPCO data streams (“timestamps”),
by which the user can check how things looked like with the fares that were active in
previous timestamps.
Segmentation Heatmap usage
To execute a basic query in segmentation heatmap follow the next steps:

25
Step 1: Go to Competitive Analytics by
clicking on it on the main menu:
Step 2: Select the label “Segmentation
Heatmap”
Step 3: Select an Origin and Destination

(First Origin, Then Destination)

26
Step 4: Select an Incumbent and a
Competitor
Step 5: Click on Get
As a result, the user should see a loading percentage, and after a few seconds
(Depending on how many fares the selected market and carriers have) a similar result to
the following will appear on the screen:

27
How to read the Segmentation Heatmap matrix
Segmentation Heatmap contains four sections: Filters, Matrix 30x30, Matrix 360x360 and
Price List
Filter Matrix 30x30 Price List
Matrix
360x360

28
Once the user fills the information on the filter and press get, two colored matrices, one of
30x30 cells (on the center of the screen) and another one of 360x360 (on the bottom right
side of the screen), will appear.
Both of these matrices have the same x-axis and y-axis (Advance Reservation x
Travelling Period) and the 30x30 matrix is a zoom in of the 360x360 matrix shown on the
bottom right of the screen.
Each cell represents a specific behavior of a potential customer expressed in days in

advance to buy the ticket (x-axis) and length of stay at destination (y-axis).
Because of these dimensions, it’s easy to identify the different demand behaviors visually.
For example, the corporate passenger will have short traveling periods and short advance
reservation time, so it will be represented by cells closer to 0,0 on the matrix. On the other
hand, the leisure segments will have longer traveling periods and advance reservation so
it will be represented by cells further from the 0,0 coordinate.
Because each cell also represents a departure and return date of a passenger’s trip,
each restriction that affects prices will have an effect on the results on the matrix. This
results a heatmap showing in red the demand segment in which the Incumbent is under-
competitive and in blue the demand segments in which the Incumbent is over-
competitive.
The Segmentation Heatmap has a drill down approach in which first, the user can
analyze the heatmap 360x360 to review the airline’s competitive position in the whole
spectrum, and then zoom in to the zone that it’s of interest. Then when the analyst can
see the detail on the matrix 30x30 she can click on one of the cells and access to the
specific fare and itinerary information on the “Price List” section.
Segmentation Heatmap Matrix components

Segmentation heatmap has different components that will show the analyst all the relevant
information necessary to understand the applicability of the fares and where to adjust the

29
fare structure (whether be price or restrictions) if an undesired competitive position is
presented.
In this section, we will present some important definitions and components of the
Segmentation Heatmap
Matrix cell or Demand Segment: is a specific combination of advanced reservation

(days, in the vertical axis) and traveling period (days, in the horizontal axis). Each cell in
the matrix represents a Demand Segment and has a Price Ratio associated. The first row
of the matrix represents the departure date equal to the date of the timestamp (or
purchase date).
Advanced Reservation: represents the number of days before departure at which the
price of the round trip is being calculated
Travelling Period: represents the number of nights at destination
Tool tip: The tool tip at the matrix cell level displays relevant information related to the
hovered cell (demand segment in Segment View or travel date combination in Calendar
View): the Price Ratio, the lowest price of the incumbent, the lowest price among
selected competitors and the specific dates related to the demand segment.
Price Ratio: Represents the % ratio between the lowest incumbent and lowest
competitor prices built with applicable published fares, for a specific demand segment of
a given origin-destination.
Prices: they are calculated at the demand segment level incorporating all the ATPCO
rules and categories and components that affect the final price level, taking into account
RT fares, OW fares, and OWD fares and the possible combinations among them.

30
Currencies: by default, the mode among the currencies of all the published fares of the
selected origin-destination is selected as the common currency (the default currency) to
convert all the fares into. When the user hover-over a cell of the matrix, the
corresponding tooltip shows the price amounts in the default currency and, below them,
the price amounts in the “original currency of the corresponding fares” (this is, the
currencies in which the fares were published in ATPCO) , in case they are different. In case
of combined fares, the two original fares may be defined in different currencies in ATPCO, in
which case the final price of the combined fares is expressed in the currency of the first
segment, which is then considered the “original currency of the corresponding fare”.
Cell color: The cell colors are associated to a spectrum mapped to the Price Ratios in a
scale between 0% and 200%.
Price list
When the user clicks a cell of the matrix, a list of prices will be displayed on the right side
of the screen. These prices represent:
- All prices for a round trip built from RT and duplicated OWD fares applicable in the
clicked cell’s date combinations
- The cheapest price for a round trip resulting from combinations of RT and/or OWD
fares applicable in the clicked cell’s date combinations
- The cheapest price for a round trip resulting from a combination of OW fares,
applicable in the clicked cell’s date combinations
Note that in the case of combined fares, only the cheapest combinations are displayed.
Each of the groups of prices that contain more than one price can be expanded to show
all the prices within the group, by clicking on the number of prices indicated in the group.
The time length of each itinerary in which the price has been quoted is displayed, and if
the user hover over it, the details of the itinerary will appear on a tooltip.

31
The smaller matrix at the bottom right can be used to zoom in on a further zone from
point 0,0 in the matrix. This is useful to analyze competitive differences caused by
Blackouts, Seasonalities or long Advanced Purchase restriction differences.
Dynamic Link to Fare Visualizer: By selecting one or more prices listed in the Price List
section, the user can go into Fare Visualizer and see the details of the fares affecting the
price on a particular cell, this is done by clicking the upper right arrow.
Filters
Origin, Destination: When a user selects an origin or destination, Competitive Analytics

first thinks of cities. For example, if the user selects “BUE”, Competitive Analytics looks at all
the fares associated to BUE and to specific airports (EZE, AEP) that belong to BUE. In the

32
case that the user selects an airport instead of a city code, for example, “EZE”, then
Competitive Analytics will only consider fares published under EZE in ATPCO.
Select incumbents: Required field. All carriers with published fares in the selected OD
are displayed. The user should choose her airline, her group of airlines or any one or
more of the airlines displayed in the list, which will then be used as a basis for price
comparison. This selection “symmetry” allows the user to analyze the competitive position of
any carrier in relation to the market.
Competitors: All operating carriers in the OD selected are displayed. It is not a required
field. Selected competitors must be different from incumbent carriers.
RT and RR: include prices for round trips built from RT and OWD fares (and their
allowed combinations)
OO: include prices for round trips built from allowed combinations of OW fares (this is
equivalent to quoting two one way tickets).

33
Self Compare functionality
When a user selects only an incumbent carrier and not a competitor, the matrix shows in
each cell the ratios of the incumbent’s lowest price for that cell, over the lowest
incumbent price across all the cells.
COMPETITIVE ANALYTICS MODULE: Schedule Heatmap
Objectives of Competitive Analytics: Schedule Heatmap
The objectives of Schedule Heatmap are similar to the ones in Segmentation Heatmap
with the difference that this module was designed to analyze markets with multiple
frequencies per day. This module will help the analyst to understand opportunities by
Time of the Day by showing all itineraries of the incumbent carriers with their prices,
compared to a competitor’s multiple itineraries and prices, on a time window of 60 days
of departure dates in the future.

34
As opposed to Segmentation Heatmap, In Schedule Heatmap the dimensions that define
a “segment” are Days in Advance, and Time of the Day (every 30 minutes), colors
represent the price amount instead of the price ratio (see segmentation heatmap), and
each colored matrix is shown one next to the other to show the comparison between
carriers
The same as in Segmentation Heatmap, in Schedule Heatmap the user can visualize
past Timestamps.
Schedule Heatmap usage
To execute a basic query in segmentation heatmap follow the next steps:
Step 1: Go to Competitive Analytics by

clicking on it on the main menu:
Step 2: Select label “Schedule Heatmap”
Step 3: Select an Origin and Destination

(First Origin, Then Destination)

35
Step 7: Select an Incumbent and a
Competitor (for the moment only one
competitor can be selected. In the future,
the user will be able to select multiple
competitors)
Step 4: Select a day of week (by default

all are included)
Step 5: use OW flag to determine if the
analyst will be done only on OW fares, or
in all fares
Step 6: If OW flag is off, a length of stay
has to be specified in the Length of Stay
field
Step 8: If OW flag is off, the fare

combination types must be specified, our
recommendation is to select all possible
types of combinations
Step 9: Click on Get
As a result, the user will see a loading percentage, and after a few seconds (Depending
on how many fares the selected market and carriers have) a similar result to the following
will appear on the screen:

36
How to read the Schedule Heatmap matrix
Schedule Heatmap contains four sections: Filters, Incumbent Schedule matrix,

Competitor Schedule matrix, and Price List
Filter Price List
Incumbent’s Competitor’s
matrix matrix

37
After executing a query, two matrices with Days from Departure in axis-x and Departure
Time in axis-y will be displayed. Each cell will be painted with a color in case an itinerary is
departing at that time and day, if no itinerary is found, the cell it’s painted black.
The color of each cell is determined by the price level of that itinerary. The way the color is
determined is by finding the lowest and highest prices among all incumbent‘s and
competitor’s prices, and then the color scale is adjusted to those values
This view will help the analyst to determine the airline's competitive position on the
different time of the day bands across several departure days. Always remember that the
information will be calculated based on itineraries with a fixed length of stay that was given
on the query filter.
If the user hover-over on any of the cells, detailed information of the itinerary calculated for
that cell will be shown:
Also, the same as in Segmentation Heatmap, if the user clicks on a cell, the detail of the
fares been evaluated for that particular itinerary will be shown on the Price List section:
If the user selects a cell in which the incumbent has a valid itinerary but the competitor
doesn’t, Price List will show a “NO VALID ITINERARY FOUND” but it will show the fares that
would apply to an itinerary of there was one available.

38
Schedule Heatmap Matrix components
Schedule Heatmap , the same as Segmentation Heatmap, has different components that
will show the analyst all the relevant information necessary to understand the applicability
of the fares and where to adjust the fare structure (whether be price or fare restrictions) if
an undesired competitive position is presented. In this section, we will present some
important definitions and components of Schedule Heatmap
Matrix cell or Demand Segment by itinerary: is a specific combination of advanced

reservation (days, in the horizontal axis) and Departure Time (Schedule every 30
minutes, in the vertical axis). Each cell in the matrix represents an Itinerary and its
associated price.
Advanced Reservation: it represents the number of days before departure at which the
price of the round trip is being calculated (from today). It can also be read as the number
of days from now that that particular itinerary is departing.
Time of Departure: It represents the Departure time of the itinerary been evaluated the
cell. This is shown on time windows of 30 minutes. If two itineraries are departing within
the same 30 minutes time window, the system will take into account the cheapest one.
Tooltip: The tooltip at the cell level displays relevant information related to the hovered
cell: Departure and return time, Departure and return date, the lowest itinerary price, the
itinerary information, and the inbound and outbound fares.

39
Prices: they are calculated at the demand segment level incorporating all the ATPCO
rules and categories and components that affect the final price level, taking into account
RT fares, OW fares and OWD fares and the possible combinations among them.
Currencies: by default, the mode among the currencies of all the published fares of the
selected origin-destination is selected as the common currency (the default currency) to
convert all the fares into. When a user clicks a cell of the matrix the corresponding tooltip
shows the price amounts in the default currency and, below them, the price amounts in
the “original currency of the corresponding fares” (this is, the currencies in which the
fares were published in ATPCO), in case they are different. In case of combined fares, the
two original fares may be defined in different currencies in ATPCO, in which case the final
price of the combined fares is expressed in the currency of the first segment, which is then
considered the “original currency of the corresponding fare”.
Cell color: The cell colors scale is adjusted to the maximum and minimum price amount
found on the results.
Price list
When the user clicks a cell of the matrix, a list of prices will be displayed on the right side
of the screen. These prices represent:
- All prices for a round trip built from RT and duplicated OWD fares applicable in the
clicked cell’s date combinations
- The cheapest price for a round trip resulting from combinations of RT and/or OWD
fares applicable in the clicked cell’s date combinations
- The cheapest price for a round trip resulting from a combination of OW fares,
applicable in the clicked cell’s date combinations
Note that in the case of combined fares, only the cheapest combinations are displayed.

40
Each of the groups of prices that contain more than one price can be expanded to show
all the prices within the group, by clicking on the number of prices indicated in the group.
The time length of each itinerary in which the price has been quoted is displayed, and if
the user hover-over it, the details of the itinerary will appear on a tooltip.
Dynamic Link to Fare Visualizer: By selecting one or more prices listed in the Price List
section, the user can go into Fare Visualizer and see the details of the fares affecting the
price on a particular cell, this is done by clicking the upper right arrow.

41
Filters
Origin, Destination: When a user selects an origin or destination Competitive Analytics first
thinks of cities. For example, if the user selects “BUE” then competitive looks at all the fares
associated to BUE and to specific airports (EZE, AEP) that belong to BUE. In the case that
the user selects an airport instead of a city code, for example, “EZE”, then Competitive
Analytics will only consider fares published under EZE in ATPCO.
Select incumbents: Required field. All carriers with published fares in the selected OD
are displayed. The user should choose her airline, her group of airlines or any one or
more of the airlines displayed in the list, which will then be used as a basis for price
comparison. This selection “symmetry” allows the user to analyze the competitive position of
any carrier in relation to the market.
Competitors: All operating carriers in the OD selected are displayed. It is not a required
field. Selected competitors must be different from incumbent carriers.
Day of week: This will filter the results by Days of week

42
OW flag: If active, the analysis will be done only on OW itineraries and OW fares. If it’s
not active, the system will require that the user specifies a Length of Stay to evaluate the
itineraries
RT and RR: include prices for round trips built from RT and OWD fares (and their
allowed combinations)
OO: include prices for round trips built from allowed combinations of OW fares (this is
equivalent to quoting two one way tickets).
PRICING WORKFLOW
Pricing Workflow objectives
Pricing Workflow is a platform for managing requests for the publication of fares, in which
different roles of a pricing team interact. The objective of this tool is to drastically reduce
fare filing errors through pre and post-publication check, and also streamline and facilitate
the flow of pricing publishing, through the replacement of in-house developments, excel
files and informal communication via mail and other means. Pricing Workflow consists
mainly of two modules, Fare Builder and Publishing Manager

43
Fare Builder
Fare builder allows you to create a table with records (request), to publish Fare record
changes, ie: N, I, R, C, FN, Curr, RTG. In the future, other publishing possibilities will be
enabled (Rules, massive changes, etc.). There are three ways to create a new request:
Directly in the Fare Builder table, with the Fare Generator (massive requests), import from
other modules (Fare Visualizer or Monitoring).
Generating a new request in Fare Builder

The Fare Builder table contemplates all necessary fields to load changes from Fare records
in ATPCO

44
Single or multiple rows can be added by clicking . This method is used to generate low
volume changes
By clicking the user can add multiple lines on the request table
The rows are previously validated, indicating the obligatory fields. Some will complete
themselves after filling in the necessary information. Up to 150 rows can be viewed per
page, in descending order (newest shown above)

45
Adding fare changes with Fare Generator
Fare Generator is mainly used to generate large quantities of fare records, from previously
defined groupings. To access Fare Generator the user must click on the upper arrow located
on the top left of the table.
Far
e
Ge
ner
ato
r
The first thing that the user will see after clicking on the link is a new type of table, to add
new records to this table the user must click on .
The data entered in the modal is reflected in a table, which indicates a summary of what we
are going to generate in the "output" table (a row will be created for each data entry made on
46
the modal).
It is possible to edit the information entered in each row, using the "edit" button (the modal
will be reopened and will allow modifications).
It is also possible to create the table by loading an excel file. The file format is available for
download and the information must be uploaded in the same format.
This is how the excel upload file format looks like:

47
Once the desired input has been written on Fare Generator, by clicking on ,
all the specified combinations and OD groups will be crossed and unpacked and will
overwrite the Fare Builder table with the new inputs. The limit of rows to be generated in
Fare Builder is 30.000
The user can always go back and edit the Fare Generator to produce the output for the Fare
Builder table again.
Import fare changes from Fare Visualizer into a request in Fare Builder
Fare Visualizer allows the user to make massive consultations of tariffs, select them and
export them to Fare Builder. The user may do a full page tariff selection: only tariffs on the
current page (maximum 200), select fares one by one, or a full query selection (everything
included in a query with up to 30,000 fares)

48
When exporting the data, a modal will open to make modifications to the selected tariffs,
such as: Increase or Reduce the Base Price, modify the Fareclass, change the FN, CURR or
RTG and, finally, Cancel tariffs.

49
Associated request: The user can
choose to export the fares to a new
Request or an existing one. In the latter
case, the user must enter the number of
the desired Request.
- If you choose to export the fares to a
new Request, after pressing "SEND" the
number of the new Request created will
be displayed, allowing you to access it
through the "Go To Request" button.
After making "SEND" the modal will
always remain open, facilitating a new
action on the previously selected tariffs. If
you no longer wish to modify these tariffs,
press "Cancel".
When reopening the modal, the Request
number will be empty (the default option is
"New").
Export type: Is “All” is selected, the full
query will be export to Fare Builder, If not,
only selected fares will be exported
The export modal has different types of changes that can be applied to the selected fares,
below there is a description of each of them:
Increase / Reduce: allows you to increase or reduce the base price of the selected tariffs, in
an amount or percentage, for both OW and RT tariffs. The "Change type" field in Fare
Builder will be I / R
New: Allows you to enter an amount into the Base Price, which will apply to all selected
tariffs. The "Fareclass Change" feature is used to change certain specific characters in the
fareclass. The "search" filter is used to search for the characters you want to change and in
the "Replace" box you must enter the new characters to replace those specified in "Search".
It is possible to use the same wildcards used in PV ("_" to define the exact position of a
character and "%" for an unspecified number of characters). In this option it is also possible
to change the FN, RTG, and CURR of the selected tariffs, in order to generate a new tariff.
The Footnote will be filled in the "Footnote" column in Fare Builder. The "Change type" field
in Fare Builder will be N.
Cancel: does not allow modifications to the selected tariffs.
Other: In this case, the "Change type" field in Fare Builder will be empty. It is mainly used to
change the FN, RTG or CURR of the selected tariffs.
Footnote: The "Search" filter allows you to search for fares with a specific Footnote.
The value entered in "Change" will be located in the "Change Footnote" column in
Fare Builder (only for fares whose FN matches the one specified in "Search").

50
Routing Change: The "Search" filter allows you to search for fares with a specific
Routing and then replace this value with the value entered in "Replace". In other
words, in the RTG column of Fare Builder, the value searched for will be replaced by
the new value chosen.
Currency Change: The "Search" filter allows you to select a specific Currency and
then replace this value with the value entered in "Replace". In other words, in the
CURR column of the Fare Builder, the value searched for will be replaced by the new
value chosen.
It is possible to leave the "Change" and/or "Replace" fields blank. If so, the new field will be
blank.
Import fare changes from Monitoring into a request in Fare Builder (Fare Mapping)
The system can also help the user in Monitoring by recommending fares in the Incumbent
airline to do a match to a competitor airlines. For the purpose, a Fare Mapping algorithm is
used to evaluate both fare structure (Incumbent vs Competitor) to determine which Fare is
best suited to do a match.
To execute a Fare Mapping the user must run a query in Monitoring, select some fare
changes and click . The system will then start calculating matching fares
for those changes
Then the user must select a Work Team, Indicate if this is going to an existing Request or a
New Request and click on . The system will generate the Request (or send the new
changes to the existing request) and then will generate a link to the Request so the user can
access it easily by clicking

51
The user will be taken to Fare Builder, and all suggested Fares will be already pre-filled on
Fare Builder ready to complete the publication.
Fare Builder Validations (pre-publication checks)

Once the user has entered the tariff changes in the Fare Builder table, she must save the
Request by clicking on . This will open a modal in which the user must enter the
Request Name, Work Team, Priority, Motive (Depending on the airline’s workflow
specifications).

52
After the user has saved the request, the validation process will begin automatically. These
validations will vary depending on the airline’s specifications, but include among other things:
- Comparison of fare price versus the lowest price in the current fare structure
- Duplicates
- Fare Inversion
- Duplicate fare in other markets or carriers
- Fares with no Surcharge
- etc..
These validations can be set for specific group of markets, or to be applied to all fares.
There are two types of validation triggers: Warning and Error.

"Error": does not allow to send to publish rates.
"Warning": does allow it, but it is an indication that there is something inconsistent with the
system validations (even if it is not critical).
Also, there are different types of validations depending on how these validations are
calculated:
Error in a field: format or non-existence. Example: Incorrect date format
Fare Record error: inconsistency between fields. Example: Enter FN and specify dates
Error at Request level: inconsistencies or validation made across different rows Example:
duplicate records

53
The error and warning messages will be displayed if the user hover-over the icons on
the top left of the table. The user will also be able to see an overview of the validation on the
entire request:
Another important validation, as mentioned before, is the validation made on fare reductions.
In order to do these validations, the system executes a simulated quote of the fares changes
that will be published and compares the resulting price to the minimum fare price currently
published. The difference between these two prices is reflected in the DISC. MIN column.
DISC. MIN: is the % discount being applied to a specific fare on the minimum market fare,
including fuel: (New Fare Base Price+Surcharges)/(Current Minimum Dare+Surcharges) -1
Depending on the level of DISC MIN, the airline may decide to require an approval process
for discounts that surpass a certain threshold (e.g Any new fare that will result in reducing
the minimum price of a certain market by more than 30% has to be approved by the
Manager). These type of changes that require approval will be indicated in Fare Builder with
a symbol.
If a fare needs to be approved by a role of equal or lesser hierarchy, it will be approved

automatically. If this is not the case, the request will be sent to Publishing Manager to go
through the workflow that the airline has defined.
If the request does not present any errors, the button will be clickable and the user
will be able to submit this new request to send to the approval workflow and then its
publication. If changes are made to the table, the button will be deactivated and you must
click "SAVE" again. After making SUBMIT, the Request will be closed. The button
(settings) can be used to modify the request configuration.
When clicking on , the following modal will open requesting for additional information
associated with the new request. The user here can specify he she wants the fare changes
54
to be published immediately or if they should be published on a future date and time. Also,
the user may add a description to the request that will be read by the rest of the publication
team through the publication workflow.
When clicking on , the request will be sent to the Pricing Workflow.
Other Fare Builder functionalities
Fare Simulator
When doing SAVE, a simulated quote of the fare will be calculated and displayed, showing
how the fare would look like after it is published, so that users can corroborate that they are
publishing what they want, and also retrieving data to execute validations.
The fields to be calculated are as follows: RBD, OW/RT, Q Surcharge, YQ/YR, TAX, Total
Price, Total Price Per Direction, Adv. Reservation, Min. Stay, DOW Outbound, Blackout
Outbound, Blackout Inbound, Seasonality Outbound, Seasonality Inbound, Tariff Number
Filters
After having saved/validated, it is possible to filter the fare records by:

- Requires approval (from supervisor, manager or director)
- Errors

55
- Warnings
Footnote designator
Footnote designator allows the user to enter Footnotes ("Footnote" or "Change Footnote"
fields) to groups of fare records that have the same associated ranges of Sales and Travel
dates. the objective of this functionality is to speed up the process to assign Footnote to a
large number of new fare records.
To access Footnote Designator, the user must click on the second arrow on the top left side
of the Fare Builder table.
Publishing Manager
Publishing Manager allows managing the requests through the publication workflow process

56
Once a request goes through the publication workflow, each user that needs to execute an
action on a request will be notified via email, and then the user will be able to access to
Publishing Manager to execute such action. The action will depend on the workflow
designed for the airline, but some of them are
- Send a Request to publish

- Approve a Request for its publication
- Reject a Request
- Send messages to other users about a request
- Notify about publication errors
The main publishing manager functionalities are:
- Search Requests by "modification date" (default is last 30 days)

- Search by Request number
- Filter by status
- Entering Comments
- Changing Request status
- Requests Edition
- CSV file download (only fare records in “Ready to Publish” state)
- Download CSV files for analysis purposes
- Publish directly to ATPCO (only fare records in “Ready to Publish” state)
Publishing Manager works with a tailor-made configuration of the airline based on Roles and
Workflow steps. Depending on this configuration, Publishing Manager will show the state of
the different request and also will be used to change those states (or status) depending on
the Role and the motive of the fare change on each state.
Some examples of possible roles and states are:
States (Statuses):

57
- Draft = D
- Waiting for Manager = WM
- Waiting for Supervisor = WS
- Waiting for Director = WfD
- Rejected by Manager = RfM
- Rejected by Supervisor = RfS
- Rejected by Director = RfD
- Rejected by Publisher = RbP
- Ready to Publish = RP
- Waiting for Distribution = WD
- Published = P
- Publishing Error = PE
- Upload Error = UE
Roles:
- Pricing Analyst
- Supervisor
- Manager
- Director
- Publisher
In Publishing Manager the user will observe the detail of each Request and change the
status at the level of Fare Changes or groups of Fare Changes that share the same status.
Each Role will only be able to change and/or see certain statuses depending on the
workflow configuration given by the airline.
There are 3 ways to change statuses:

1.Marks all Fare records of the Request (of the selected status)
2.Mark all Fare records of a single page (of the selected status)
3.Mark a single row
Each time a Request changes the status of any of its records, a notification email will be sent
to the specific Role that needs to execute an action in the corresponding working team:

58
This is an example of a workflow that can be configured in Publishing Manager:
Write a comment in a request

To write comments in a request the user must click on , and a modal with all previous
comments associated with the request will open.
To write a new comment, the user must simply wrote the comment on the dialog screen and
click .

59
In each request, automatic comments will be created each time a status change occurs,
informing the user who made the change.
- The yellow comments are those of the user herself.
- The white comments are those generated by other users (from actions performed by
them or comments they wrote)
- The gray comments are those generated by the system.
If a user writes a comment, the other users associated with the same work team will see the
comments icon marked in green. The color will disappear once they open the modal and
close it again.
The notification emails associated with the request will include the last comment written on
the Comments log.
Edit a Request
Some users (depending on the configurations set by the airline) will be able to edit a request.
In order to do so, the user must change the status of the fare changes she wishes to edit to
“draft”, and then click on .
This will take the user back to Fare Builder and the user will be able to edit all fare changes
that have status “draft”. Other statuses will be visible but not editable.

60
Publication to ATPCO
The system supports automatic, and manual publication to ATPCO. In case a manual
publication is required for Footnote assignment or special rule condition requirements, the
system will provide a .csv file to the publisher that allows a manual publication with the
minimum human intervention possible.
Once the publication has been done, the system will receive feedback from ATPCO to
update the request status after the batch has been sent. This will allow the user to do a
follow-up of the complete publication process and be alerted if anything unusual happens in
between.
Notifications
Publishing manager will notify the users of pending tasks via three different methods
- Notification emails
- Red bubble (push notifications through the interface)
- Pricing Compass panel
We will describe these three methods below.
Notification emails
The notification emails will have relevant information about the request that needs attention
as shown in the image below

61
Status: Status of the request
Name: Name of the request
Team: Work Team associated with the Request
Priority: Priority of the Request
Request Type: Type of request
Motive: Motive of the Request (Will depend on the airline’s configuration)
Description: Description of the Request
Last Comment: Last comment written by a user on the comments dialog.
Fare records: First 50 fare changes included on the Request and their statuses
Red bubble (push notifications)
The system will alert the user of her pending tasks through a red bubble on the left menu.
This red bubble will indicate the number of Requests that need attention from the user and
will be updated every 5 minutes
If the user clicks on the red bubble the system will take her directly to Publishing Manager,
filtering just the request that needs her attention.

62
Pricing Compass
Another way in which the system notifies the user of pending tasks in Publishing Manager is
through the Pricing Compass dashboard. In this dashboard the user will have a bar with an
overview of the pending tasks in publishing manager
Delegates
The system allows the user to designate “Delegates” to take over her tasks while she is
absent. This feature is located under "Settings" and is used to delegate responsibilities to
other user(s). The only one who can delegate functions to another is the user himself.
Delegations can be activated/deactivated at any time and the "delegate" user must be
associated with one or more Teams of the "Delegator" user.
The user’s functions and tasks are fully delegated, for as long as the delegation remains
active. During such time the "Delegee":
- Will be copied in the PW notification emails (associated with the selected Teams).
- Will have all the permissions and faculties that the user "Delegator" has (only for the
Teams selected).
It is possible to delegate to a user who has a different role to the Delegator.
The Delegee user will receive all Delegator notifications when someone delegates
responsibilities to him.

63
For each Delegation, at least one user and one Team must be specified. All specified users
will assume the same role(s) of the "Delegator" user for that Team
Each delegation can be easily activated/deactivated. The "Edit" button allows you to modify
a previously created Delegation
If there is any active Delegation, when entering the platform, the Delegator user will see a
warning banner. This banner is not visible by "Delegees".

64
TRENDS MODULE
Objectives of Trends Module
The objectives of Trends Module include helping the airline identify carriers and markets
with the most intense price dynamics, understand the composition of those price
movements and get an idea of the market price trends.
This module contains three sections: Filters, Graphs, and Overview
Filters
Chart unit of time: select a time unit for the horizontal access, in order to get the
information by hour or by day (week pending).
Last Timestamp: select the latest timestamp to consider in the calculations and graphs.
Airnguru will plot from that timestamp backward in time a fixed number of historic points
that depends on the Chart Unit of Time selected.

65
Origin (Destination): select the level of aggregation at which to filter the origin
(destination).
● Filter origin (Filter destination): specify Origin (Destination) to filter. Use three
letter nomenclature to specify cities or airports, separated by commas. When a user
selects an origin or destination, Trends first thinks of cities. For example, if the user selects
BUE then Trends looks at all the fares associated to BUE and to specific airports (EZE, AEP)
that belong to the city BUE. If the user selects an ATPCO Origin/Destination code that refers
to an airport instead of a city code, for example EZE, then Trends will only consider fares
published under EZE in ATPCO. If the user types ‘BUE’ (using simple quotation marks)
Trends will consider only the fares under BUE in ATPCO (exact match with Origin/Destination
ATPCO field). Use two-letter nomenclature to specify countries, separated by commas.
● Carriers: filter carriers to be included in the graphs and calculations by typing IATA
carrier codes (2 characters long each, separated by “,”). By leaving the filter empty all
carriers will be displayed.

66
● Group Origin / Destination by: aggregate the Overview outputs at different levels
of aggregation at the origin and at the destination.

67
Charts
“PRICE” subsection
● Y-axis: Average fare, Minimum fare

● X-axis: Time (in hours or days, depending on “Chart unit of time” selected)
● Average Price (or Av. Fare): Linear average of all prices applicable in each of the
cells of the segmentation matrix of the corresponding OD. (Considers only the matrix
cells/date combinations that have been calculated). By default, Average Prices are
expressed in USD.
● Minimum Price (or Min. Fare): Minimum applicable prices over all the matrix cells
over all the selected OD’s. (Considers only the matrix cells/date combinations that have
been calculated). By default, Minimum Prices are expressed in USD.
“CHANGES” subsection
● Y-axis: Number of changes recorded in the ATPCO Fare Records

● X-axis: Time (idem Fares subsection)
● Number of changes: counts all the 18 types of changes specified in the ATPCO
Fare Record
● Types of Changes (or Filing Events): a Change is any of the possible actions
performed by an airline when filing in ATPCO and that gets recorded in a Fare Record.
Changes may or may not affect the Competitive Analytic matrix. Includes 18 types of
changes (with some unused types).:
1. New record - New Link Number

2. Increased fare amount
3. Reduced fare amount

68
4. Currently not being used
5. Footnote addition, deletion or change
6. Routing No./Map No. change
7. Reserved for future use
8. MPM change. The Maximum Permitted Mileage between two given points has
changed.
9. Reserved for future use
10. Effective date change - The effective date is the only item in the record that has
changed since the last file has been sent.
11. Reinstatement of previously canceled or discontinued fare has taken place by changing
the date to continue the life of the record.
12. Reissue - The life of a fare record previously canceled or discontinued has been
renewed with a later date causing a time gap in the life of the record.
13. The first record in a link is discontinued.
14. No change - The record has been processed but the record has not changed.
(Unpublished fares only.)
15. Canceled record
16. No component change - In a constructed record the fare change is due to a change in
the IATA Rate of Exchange. All components of the record are the same as the previous
record within the link number. (Unpublished fares only.)
17. Currency Code Change
18. Tag which indicates if a fare record is not subject to NUC conversion. (Published fares
only.)
Overview panel
Definition of Overview
Overview displays three pieces of information by carrier: (1) the variation of the average
fare (as defined in the PRICE subsection of Graphs) of applicable round trips, (2) the
variation of the minimum fare (as defined in PRICE subsection of Graphs) of applicable
round trips, and (3) the number of changes (as defined in CHANGES subsection of
Graphs), from the beginning to the end of the selected time window, in a single OD
market or a group of OD markets, opened downwards by OD market and ordered from
left to right and from top to bottom by volume of changes.
● Δ Av. Fare: Is the variation (final - initial) of the average fare (as defined in the
GRAPHS section) over the time span selected for Overview. The last timestamp of the
time span selection is taken into account for the “final” value and the first timestamp of the
time span selection is taken into account for the “initial” value.

69
● Δ Min. Fare: Is the variation (final - initial) of the minimum fare (as defined in the
GRAPHS section) over the time span selected for Overview. The last timestamp of the
time span selection is taken into account for the “final” value and the first timestamp of the
time span selection is taken into account for the “initial” value.
● Changes: Is the sum of all the number of changes (as defined in Subsection
CHANGES of section Graphs) within the time span selected for the overview.
● Total by Market: at the right extreme of the Overview section the user can read the
totals by market. In the cases of Av. Fare and Min Fare, these totals correspond to
simple averages over all the carriers that contain values for these indicators (ie, empty
values or “-” symbols are not considered in the totals). In the case of Changes, the totals
are the sums of Changes across airlines.
● Total by Carrier: at the bottom of the Overview section the user can read the totals
by carrier. In the cases of Av. Fare and Min Fare, these totals correspond to simple
averages over all the aggregated OD markets that contain values for these indicators (ie,
empty values or “-” symbols are not considered in the totals). In the case of Changes, the
totals are the sums of Changes across OD markets. Note that given this definition, Av
Fare and Min Fare totals depend on how the user selects the aggregations of origin and
destination.
● Grand Total: In the bottom right extreme of the Overview the user can read the
grand totals for the three variables of the overview. Av Fare (and Min Fare) correspond
to the linear averages over all the corresponding values of the Overview table (including
those beyond the 100 lines of the table), not including empty cells or “-” symbols.
Changes corresponds to the sum of all Changes across the Overview table (including
those beyond the 100 lines of the table).
● Data treatment:
○ A symbol “-” in the Overview table means that despite existing prices for that
particular Origin-Destination-carrier combination, the information has not yet been
calculated by the Airnguru pricing engine (e.g., for the calculation of Δ , initial and final
values are necessary).
○ An empty cell means that the particular Origin-Destination-carrier combination has
no applicable prices in the selected time span over the segmentation matrices.
○ Neither empty cells nor cells containing the “-” symbol are considered in the
calculations.
User interface functionality
● Some filters can be left empty (Origin, Destination and/or Carriers), in which case
all the data associated to those fields will be calculated and/or displayed
● Tooltip (Price graphs): shows the carrier and the value of the Av Fare or Min Fare,
depending on the selected graph. For the Min Fare curve, the fareclass (or fareclasses)
of the lowest price is shown in the tooltip (only when “Hour” is selected in the chart unit of
time).

70
Clicking on the corresponding dot of the Min Fare curve takes this fareclass into the Fare
Visualizer so the user can check its components.
● Dynamic Link to Fare Visualizer: Selecting one of the prices in the Min. Fare
curve, the user can jump from Trens into Fare Visualizer to look at the details of the
fareclass(es) involved (available only when “Hour” is selected in the Chart unit Of Time).
● Tooltip (Changes graph): shows the carrier corresponding to the bar section
selected, the total changes associated to that carrier and a detail of its components (see
definition of Types of Changes)
● Hide curves: Curves in the Price Graph and Changes Graph will disappear by
clicking the different Carriers on the upper right side of the graphic.
● Expand/Contract (Overview): Allows the user to visualize the top 100 markets in a
full screen view. For a longer list, it is necessary to use the Download button (coming
soon)
● Download (coming soon): Allows the user to download the information to an Excel
sheet.
● Subrange selection (Overview): Select a date subrange within the Trends time
filter selection, for the Overview

71
● Pagination of Overview: in order to see additional airlines with smaller volumes of
changes click on the right arrow, or click on the left arrow to get back.

72
PRICING COMPASS
Objectives of Pricing Compass
Pricing compass is a dashboard this will help the analyst to navigate through the entire suite,
and will highlight in which area the user should put special attention. This is done by showing
in different sections of the dashboard a prioritize overview of the most relevant modules
across the suite and also relevant commercial metrics of the user’s markets.
Pricing Compass usage

The dashboard will automatically deploy when you enter Airnguru. By default, all predefined
market associated with the user will be searched (with a limit of 30).

73
If the user wishes to drill down on a particular market (within her predefined markets), the
user may use the filters at the left of the dashboard.
If no pre-defined market is not selected, the user may choose a group of Origins and
Destination.

74
The header shows a summary of the user's main pending tasks in Publishing Manager. All
Requests that have a record in status are counted: Rejected, Publishing Error, Waiting for
Approval, Drafts. Only the Requests belonging to the user, which have had some activity in
the last 7 days, are considered. Filters do not apply in this section. There is a link that
leads to the Publishing Manager module
Reactive Alerts shows the 50 ODCs with the highest priority and number of alerted
changes occurred in the last 48hrs. Only alerts with "pending" status will be shown.
Proactive Alerts shows the 50 ODCs with the greatest absolute deviation (over 5%) of the
commercial metrics, with respect to the previous week.
In the Commercial Metrics section, you can see Revenue, Pax and Av. Fare for the last 3
months, the current month and the next 8 future months.
In this section, the user can also access Industry Metrics (Market Share and QSI) by
clicking . QSI vs MS allows detecting strategic opportunities for each OD. It takes
the simple average of the last 3 months. MS vs Industry shows the evolution with respect
to the previous year of these two metrics.

75
The Publishing KPI section provides statistics of the different Requests status in Pricing
Workflow, based on the last 30 days. This information is updated every night and it’is
shown only for the Ods (Pred. markets) selected in the filter. It allows to detect possible
"bottlenecks" in the publishing workflow and find opportunities for improvement.
If you find something missing or confusing in this document please let us know…
Thanks for your help improving our service!

76
The Airnguru Team.

77

User Guide Airnguru - 8 Jun 2019 Backup

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

User Guide Airnguru - 8 Jun 2019 Backup

Uploaded by

Copyright:

Available Formats

User Guide

Airnguru Price Awareness and Execution Suite

Jun 7th, 2019

“ Speed is the essence of war. Take advantage of the enemy’s

- Sun Tzu , The Art of War

© Airnguru confidential material

FARE VISUALIZER MODULE

COMPETITIVE ANALYTICS MODULE: Segmentation Heatmap

COMPETITIVE ANALYTICS MODULE: Schedule Heatmap

© Airnguru confidential material

© Airnguru confidential material

Airnguru Price Awareness and Execution Suite is a cloud based pricing

The main inputs for the system are

- Hourly ATPCO filing data stream.

COMMON FEATURES, CONCEPTS AND ASSUMPTIONS

© Airnguru confidential material

Demand segment: It is defined as a specific combination of advanced reservation date and

Timestamp: A timestamp corresponds to an hourly ATPCO update, which is processed by the

Point of Sale (“POS”) assumption: The assumption POS = POC (Point of

© Airnguru confidential material

© Airnguru confidential material

Objective of Fare Visualizer Module

Filter Result Table

© Airnguru confidential material

© Airnguru confidential material

© Airnguru confidential material

Reading the results

© Airnguru confidential material

© Airnguru confidential material

Export to Fare Builder: (See Fare Builder)

PF: Private Fare indicator

© Airnguru confidential material

Objectives of monitoring Module

© Airnguru confidential material

© Airnguru confidential material

Te module has two sections: Filter and Change list:

Filters Changes List

In order to generate a basic query, the user must:

Step 1: Specify on the filters a Pre-defined market or a group of origins, a group of

Step 2: Click on GET

Step 1: Specify on the filters a Pre-defined market or a group of origins, a group of

Step 2: On filter “Fareclass” type _FF%

Step 3: Click on GET

© Airnguru confidential material

Timestamp range: Will determine the time

© Airnguru confidential material

© Airnguru confidential material

© Airnguru confidential material

Name: Name of the business rule

© Airnguru confidential material

In the Fareclass field, wildcard characters can be used:

Type of Change: Type of changes the business rule will detect

© Airnguru confidential material

Include Competitive Threshold Flag: To be included in a future version

© Airnguru confidential material

The real-time alerts will be sent an email such as this one:

The email contains relevant information

- Overview of alerts triggered by priority

Beside the email alert, the user will be

© Airnguru confidential material

© Airnguru confidential material

Objectives of Segmentation Heatmap

© Airnguru confidential material