This screen contains various parameters related to how the RECO price is calculated. It has 2 sections:
1. RECO Settings
Reference Occupancy – Controls which occupancy (1 or 2 PAX) is the main occupancy, meaning it is the occupancy for which the RECO is calculated for the reference offer. All other occupancies for the reference offer (as well as all other offers) should be price-dependent based on this occupancy.
RECO Cap – Controls if the RECO is to be capped or not. “Cap” means the RECO amount will be automatically changed to “stay” within the defined interval (raised to be equal to the start value of the interval if the RECO is smaller than the start value or reduced to be equal to the end value of the interval if the RECO is bigger).
There are three option to define the start and the end values for the capping interval:
- “vs MyRate” – the algorithm will cap around the IRP if it’s calculated (there is PMS data and rate bounds); if not, it will cap around the price value of the reference rate or the shopped rate (whichever exists).
The start value is calculated as the percentage of the rate
The end value is calculated as a markup in percentage on top of the rate. - “vs Bounds” – the algorithm will cap the RECO based on the Low and High Bounds of the season/event type of each arrival date. Using values of 0% means the RECO does not go “beyond” the respective bounds.
The start value is calculated as the Lower Bound minus the offset (difference) in percentage
The end value is calculated as the High Bound plus the offset in percentage - “vs Static” – the algorithm will cap the RECO using the exact start and end values given.
Channel For RECO – If the subscriber hotel has the rates monitored on multiple channels, this parameter defines which is the channel from which the rates are used for the RECO.
Remember: The RECO is calculated the same (using the compset rates from the selected channel) for all channels. There is no option to calculate channel-dependent RECO.
Any business rules for distributing rate amounts differently per channel will have to be defined in the Channel Manager the hotel uses.
Fine Tuning Offset – Controls if the fine-tuning of the RECO rate is to be done against the actual prices of the competitors (No Offset) or against adjusted values of the competitor prices based on the comfort zone settings. Selecting the “Comfort Zone” option ensures that if the hotel whishes to maintain a higher-than-compset or lower-than-compset pricing strategy (as “suggested” by the comfort zone definition), the RECO will abide by that “rule” (rather than always “assume” that the comparison must be made against equality of rates). This is good when the compset is by selection more expensive (or less expensive).
Best Practice: it is recommended to have this parameter on the “Comfort zone” option, as in this way the RECO will also follow along what the hotel considers as “correct” pricing comparison against the competitors.
Rounding – Round the RECO to the nearest integer which is a multiple of the selected value (0 means no rounding) or the closest value from a list of given amounts if “LVL” is selected:
Closing Threshold – The system can be used to “recommend” a closing restriction on hotel level when the total occupancy goes above the given amount here.
MinLOS Threshold – The system also does a basic MinLOS restriction recommendation. It starts with this parameter: when the total occupancy on a given arrival date is above the value here, a “minLOS RECO” check is performed for the respective arrival date (see the parameter below).
Shoulder date Difference – The “minLOS restriction” recommendation is currently only recommending a higher than 1 minLOS restriction based on checking for occupancy “spikes”. The system checks if the OCC difference between the arrival date and its “shoulder dates” is higher than this value. If so for at least one shoulder date, the system will recommend a minLOS of 2 nights.
2. Data Freshness
This area controls if the RECO should be calculated only if the data is “fresh” enough, to avoid the situations when a new RECO is calculated based on obsolete data.
For any future arrival date, if the data is not fresh, there will be no RECO calculation. You will still be able to see the previously calculated RECO in the app (having the 
icon in front), but any active auto-pilot workers will do nothing.
Multiple freshness values can be defined, for different timeframes.
Freshness can also be defined separately for the PMS data and for the Market data.
Tip: For arrival dates far in the future, you can allow more days for “freshness” as the “dynamics” in pricing and occupancy are not big. Also, if the hotel is manually uploading data in the RMS, there should be a “threshold” of 2-3 days in terms of freshness.