Price the zone once. Every hotel in it is covered.
A price scope that resolves hotel first, then city, then zone, then all-zones — so the one hotel that negotiated its own rate keeps it, and the other two hundred inherit the zone's.
One price, four levels of specificity
A zone is a real, tenant-owned grouping of cities with its own code, name and colour — not a free-text label typed into a price row. The wildcard scope resolves in a fixed order: a price set on the hotel wins; failing that the city; failing that the zone; failing that the all-zones default. Setting one zone price covers every hotel inside it.
Rate matrices arrive as spreadsheets. Upload an Excel or CSV file and Meridian OS parses it, proposes a column mapping and validates every row against your master data — then shows you the result as a preview. Nothing is written until you commit. The mapping is saved against the file's fingerprint, so next month's sheet from the same supplier maps itself.
Hotel, city, zone, all-zones
The resolution order is stated once and applied everywhere a price is read, so an exception hotel and a zone default cannot fight over the same booking.
Zones are entities, not strings
A zone has a code, a name and a set of cities. Codes are uppercased and fixed after creation, and retiring a zone archives it rather than deleting the history priced under it.
Preview before commit
Every import runs as a dry run first: parsed rows, the proposed mapping and per-row validation against master data, with the failures listed. Committing is a separate, deliberate step.
Remembered mappings
Column mapping is saved against the file's fingerprint, so a recurring supplier sheet maps itself on the next upload instead of being re-mapped by hand.
The rest of the operation
See it on your own operation.
No open signup — a short manual review, then a demo populated for your region.