Moving from a manual and time-consuming market rate shop to an automatic one generates a big oxygen breath. All-time spent by your business analyst to canvas all rates from so many websites (.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 stations, all duration, all sites that were put aside before.

‍
It is important to select rental locations (yours and your competitors’ ones) with caution. First, because all stations are not equals in term of price positioning and volume of transactions they handle. To identify which are the ones 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 focusing 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 airport 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 adapting 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 knowing precisely the date and time of opening for every single station. If the query is configured to retrieve a booking estimate at 09:00 am on a Saturday for a 3-day weekend rental but the station shopped is closed at that time, the query will retrieve an error.
‍

In Rateshaker, the new parameter (number of the 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 retrieve the prices on 5 stations (1 at the 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 10 am and at 4 pm for a weekend rate), you will have to configure multiply the number of queries.