Describe the Hotels You Sell Instead of Listing Them
A list that grows by itself depends on conditions written clearly.
Sellers now build a smart catalogue from condition rows of field, operator and value, and choose whether hotels must match all conditions or any of them; when editing an existing catalogue, they see how many hotels match. Catalogue scope and exclusions always apply on top, and an unknown match mode is rejected instead of quietly run as “all.”
There are two ways to build a list of hotels to sell. You can pick them one by one, or you can write conditions such as “five-star hotels in Dubai” and let matching hotels join automatically. The second is a smart catalogue: new hotels enter on their own, with nobody adding them every week. Its conditions have to express real merchandising intent without leaving anyone to guess how the system reads them.
The old smart conditions were eight side-by-side fields joined only by “and,” so “one of these brands, or five stars” could not be expressed. For a while the interface greyed out the “any” option because the backend did not support it yet. A disabled control was better than a switch that did nothing.
Conditions are written row by row. Each row reads field, operator and value, and more rows can be added; at the top you choose whether hotels must match all conditions or any of them. The choice applies only between conditions. The catalogue’s own scope and its manual exclusion list always apply on top, so choosing “any” never widens them. An unknown match mode is rejected outright, never silently run as “all.”
When you edit an existing catalogue, the card shows how many hotels match, computed the same way as the catalogue’s membership, so a condition that is too broad or too narrow is visible before you save. Once a catalogue has a match mode, queries follow it, and a different mode sent with a request does not override it.