Moving from a manual and time consuming market rate shop to an automatic one generate a big oxygen breath. All time spent by your business analyst to canvas all rates from so many web sites (.com, brokers and OTA’s) is now allocated to data analysis and pricing action. However, the mistake to avoid is to collect competitors’ prices on all rental station, all duration, all sites that were put aside before.
It is important to select rental locations (yours and your competitors’ one) with cautious. First, because all stations are not equals in term of price positionning and volume of transactions they handle. To identify which are the one to configure, you should apply the 20-80 rule : « which are the 20% of the rental stations generating 80% of the activity ? » This will avoid to focus on all competitors but more on the one that counts and impacts the market with pricing actions.
Second, the final choice should be made based on your rate engine features. If all your stations are optimized in one great rate zone, with just the tax that applied on a rental checking out from an aiport or railway station, it does not make any sense to collect the prices on all the stations of the area. However, your pricing rules may differ from your competitors’one and may require to adapt your rental station to be shopped in the light of this tactic.
Check also rental station opening/closing time
This might be obvious but except for airport or railway stations, configuring a rate shop requires to know precisely the date and time of opening for every single station. If the query is configured to retrieve a booking estimate at 09:00am on a Saturday for a 3-day week-end rental but the station shopped is closed at that time, the query will retrieve an error.
In Rateshaker, the new parameter (number of station to be shopped) is added up on top of the number of suppliers/sites to be shopped (see Rule #1). Over the previous 30 sites already selected, if you want to retreive the prices on 5 stations (1 at airport, 2 railway and 2 downtown stations), the new number of queries will be 30 x 5 = 150. For the station which may apply a different price depending on the departure time (like for Friday departure at 10am and at 4pm for a week-end rate), you will have to configure multiply the number of queries.