Court mapping is the operational glue that makes booking-platform integrations actually work. Every external booking platform represents a court as a "resource" with its own identifier; every internal management system has its own court records. Mapping the two is what lets a sync pipeline assign incoming bookings to the right physical court.
Why it's not automatic
Booking platforms identify courts by an opaque ID (typically a UUID); management systems identify courts by a friendly name and number. Nothing in either system reliably indicates which UUID corresponds to which "Court 3, Outdoor". The mapping has to be done explicitly, usually once per club at onboarding.
What goes wrong without it
- Bookings sync but can't be assigned to a court — they show up in reports as "unmapped".
- Utilisation per court is wrong because bookings are mis-assigned.
- Maintenance reports don't line up because the system doesn't know which physical court was played on.
Doing it well
The best onboarding flows surface unmapped resources clearly, with the human-readable name from the booking platform shown alongside the UUID, so the operator can map them in seconds rather than hunting through booking exports.