Not necessarily. In practice, an excessively large mapping structure can slow down updates, increase the risk of errors and make your distribution considerably harder to manage.
That's why Clock applies a Fair Use Policy with two separate mapping allowances:
- Channel managers (D-Edge, RoomCloud, SiteMinder, etc.): 100 active outbound product mappings.
- Booking.com Direct: Another 100 active outbound product mappings.
This gives you up to 200 mappings as standard, with the option to extend each allowance by another 50 mappings for a fee of €50 / $60 / £ 50per extension — up to 300 mappings in total.
Let's explain why these limits exist and how you can maintain a sophisticated rate strategy without unnecessary mappings.
Why does the number of mappings matter?
Every product you synchronise with an OTA or channel manager represents a combination of room type and rate plan. Clock needs to communicate its prices, availability and restrictions for the relevant dates.
Normally, only changes are transmitted. However, occasional full refreshes covering the entire booking window are also necessary or recommended to keep systems synchronised.
Consider a hotel with 300 mapped products and a 365-day booking window.
A complete refresh could involve:
300 products × 365 days = 109,500 product-date updates.
Depending on the receiving system's response time, processing a single product update can take anywhere from a few milliseconds to several seconds.
Here's what the mathematics looks like if these updates are processed sequentially:
| Processing time per update | Total time |
|---|---|
| 5 milliseconds | 9 minutes |
| 100 milliseconds | 3 hours |
| 1 second | 30 hours |
| 5 seconds | 6.3 days |
| 20 seconds | 25.3 days |
These are illustrative calculations, not predictions of actual synchronisation times.
In reality, Clock uses intelligent optimisation to reduce communication overhead, and receiving systems may support batching and parallel processing. The situation is more sophisticated than a literal queue processing one update after another.
Nevertheless, the underlying workload remains. Large numbers of product-date changes still need to be transmitted and processed. Meanwhile, newer, possibly more urgent updates may have to wait until earlier updates have been processed.
Why could this affect other hotels?
Think of the connection between Clock and an OTA or channel manager as a shared communication pipeline.
This is a simplified illustration, but it captures an important reality: hotels using the same integration share communication infrastructure and are subject to the receiving system's capacity and processing limits.
An unusually large volume of updates from one hotel can therefore contribute to delays affecting others.
And some updates are time-critical. A delayed stop-sale or availability change could result in a booking being accepted for a room that is no longer available.
This isn't a challenge unique to Clock. Every PMS provider communicating with OTAs and channel managers faces similar technical constraints.
Receiving systems impose their own limits, too
There's another important consideration: OTAs and channel managers impose their own communication limits to protect their platforms from excessive traffic.
These may include restrictions on the number of requests, the frequency of updates or the volume of data they will process within a given period.
Such limits apply to PMS providers connecting to their systems, including Clock. We cannot override them, regardless of how quickly Clock can generate and send updates.
When these limits are reached, the receiving system may throttle or reject further requests, forcing updates to wait or be retried. This can create additional delays, particularly when large mapping structures generate substantial volumes of updates.
In other words, keeping the number of actively synchronised products reasonable isn't just Clock's preference. It also helps us operate reliably within the technical constraints established by the distribution platforms themselves.
These external communication limits are distinct from Clock's own Fair Use Policy. The 100-mapping allowances are set by Clock, taking into account the practical constraints of the receiving systems.
Why not simply allow unlimited mappings?
We actually did, in the past.
Initially, Clock imposed no such restriction. We expected exceptionally large configurations to be rare.
However, we encountered hotels with more than 1,000 active mappings.
Apart from the communication workload, these configurations presented another problem: they were extremely difficult to maintain.
Imagine trying to identify why one particular promotional rate, for one occupancy combination, within hundreds of mapped products, has the wrong restriction or price.
The more complex the structure, the easier it becomes to introduce mistakes — and the harder it becomes to find them.
Our experience led us to introduce reasonable limits that balance flexibility, maintainability and reliable distribution.
Which rates actually need their own mapping?
This is perhaps the most useful question to ask when designing your distribution.
A rate generally needs its own outbound mapping when at least one of two conditions applies:
1. You need to manage its restrictions independently.
For example, you want to stop sales for your non-refundable rate while keeping the flexible rate open, or apply a different minimum length of stay to a particular promotion.
2. You need to manage its pricing independently.
For example, the rate follows its own pricing strategy and cannot reasonably be calculated as a fixed amount or percentage adjustment from another rate.
If neither condition applies, consider using a derived rate within the OTA or channel manager instead.
Leading platforms such as Booking.com and modern channel managers support various forms of rate derivation, although the available options differ between systems.
You can often derive:
- Breakfast-inclusive prices from room-only prices.
- Single, double and additional-person prices from a base occupancy.
- Non-refundable prices as a percentage discount from flexible prices.
- Promotional prices using fixed or percentage adjustments.
These relationships are configured once in the receiving system. You don't need to manage every derived price separately in Clock each day.
And remember, Clock itself supports sophisticated rate derivations, including adjustments that vary by date, allowing you to build flexible pricing structures without unnecessarily multiplying independent rates.
What does this mean for a typical hotel?
Let's take a hotel with five room types.
It wants to manage the following eight rate levels separately:
- One flexible rate.
- One non-refundable rate.
- Six promotional rates.
That's:
5 room types × 8 rate levels = 40 outbound product mappings.
Now imagine that each rate also has:
- Room-only and breakfast-inclusive options.
- Single- and double-occupancy prices.
- Additional-person or child pricing variations.
If you mapped every combination separately, the number could grow very quickly.
But if these variations follow defined pricing relationships and don't require independent restrictions, they can be derived within the OTA or channel manager.
You still offer the same variety of products to your guests, but you manage only 40 essential outbound mappings for that distribution connection.
That leaves considerable room within the standard allowance for additional independently managed rates.
In our experience, most hotels can manage their distribution within these limits when their rate structures are organised around genuinely independent pricing and restriction requirements.
But what happens to my packages when bookings arrive?
This is an important distinction, especially if you offer breakfast packages, half-board, spa packages or other inclusions.
Suppose you send a room-only price to an OTA, which derives a breakfast-inclusive price by adding €20.
When a guest books the breakfast-inclusive offer, Clock still needs to recognise that particular rate and apply the correct package configuration, including its revenue allocation.
Clock has a solution for exactly this situation: incoming rate mappings are unlimited.
The Fair Use Policy applies only to products actively synchronised outbound to OTAs and channel managers.
You can separately map as many incoming rate codes as needed, each with its appropriate package setup.
This means you can keep your outbound synchronisation lean while still recognising the full variety of rates and packages when reservations arrive.
The two requirements — efficient distribution updates and accurate reservation processing — don't have to conflict.
What if I genuinely need more mappings?
Some hotels have more complex commercial strategies and genuinely require additional independently managed products.
That's why Clock provides two separate allowances, each of which can be extended:
| Distribution connection | Included mappings | Additional mappings | Maximum |
|---|---|---|---|
| Channel managers | 100 | Up to 50 (€50, $60, £50) | 150 |
| Booking.com Direct | 100 | Up to 50 (€50, $60, £50) | 150 |
| Total | 200 | Up to 100 | 300 |
Before increasing an allowance, we recommend reviewing whether some products could be handled through derivations instead. Often, a relatively small adjustment to the rate structure can eliminate dozens of unnecessary mappings.
The objective isn't to reduce your commercial options. It's to avoid unnecessary complexity and keep distribution manageable and reliable.
The bottom line
More mappings don't necessarily mean more flexibility.
What matters is having enough independently managed rates to support your pricing and distribution strategy — without creating an unnecessarily large volume of updates.
By combining a focused outbound mapping structure with derivations in your OTAs or channel managers, you can maintain a wide variety of offers while keeping synchronisation efficient.
And because incoming rate mappings are unlimited, your reservations can still be recognised with their correct packages and inclusions.
That's the reasoning behind Clock's Fair Use Policy: a practical balance between commercial flexibility, operational simplicity and reliable distribution.