How to Close Your Track for Maintenance Without Losing Bookings in the Chaos

Every track needs to close sometimes. Resurfacing work, a club championship that takes over the whole facility for a day, a genuinely miserable forecast that makes training unsafe - all perfectly normal reasons to shut the gates for a few hours or a full day. The problem isn't the closure itself. It's making sure nobody books a slot that isn't actually going to exist.

What happens when a closure isn't reflected anywhere

If a track is closed for maintenance but the booking system doesn't know that, someone can still book a 6pm slot on a track that's had its surface half stripped that afternoon. Nobody did anything wrong - the booking page simply didn't know the track wouldn't be usable. The result is a customer turning up to a locked gate, a refund that has to be processed after the fact, and an apology that shouldn't have been necessary in the first place.

This is exactly the kind of problem that only shows up on the day, usually to whoever's least equipped to deal with it on the spot.

Why this needs to sit inside the booking system, not next to it

A closure noted on a whiteboard in the office, or mentioned to whoever happens to be around, doesn't reach the person booking online three days beforehand. The only version that actually works is one where the closure removes the affected time directly from what customers can see and book - so the option to book that slot simply isn't there anymore, rather than being there and then cancelled after the fact.

That distinction matters more than it sounds. Cancelling a booking after someone's made it is a fix. Making sure the booking was never possible in the first place is prevention, and prevention doesn't need an apology afterwards.

Not every closure is the same shape

Some closures are obvious and total - the track's shut for the whole day, full stop. Others are much narrower: a single lane out for resurfacing while the rest of the track carries on as normal, or a two-hour window blocked out for a schools event while the rest of the day runs as usual. A useful exclusion tool needs to handle both, rather than forcing every closure into an all-or-nothing choice that doesn't match what's actually happening on the ground.

Getting ahead of the obvious ones

Bad weather is the trickiest case, because it's rarely known more than a day or two in advance. But plenty of closures are known well ahead of time - resurfacing works, club championships, facility hire for a schools event - and those can be blocked out the moment the date's confirmed, rather than three days before when someone's already tried to book it.

Getting into the habit of logging closures as soon as they're known, rather than closer to the date, is really the whole trick here. It's a small administrative habit that prevents a much more awkward situation later: an apologetic phone call, a refund, and a customer who's now had a poor first experience with a track that otherwise runs perfectly well.

Telling people who already booked, not just blocking new bookings

Removing a slot from what's bookable solves half the problem. The other half is what happens to anyone who'd already booked that slot before the closure was added. A proper process needs to catch existing bookings too - flagging them for a refund or a reschedule automatically, rather than relying on someone remembering to check who was affected after the fact.

This is where a lot of otherwise-good intentions fall down. A track manager blocks out a maintenance day with plenty of notice, feels like the job's done, and then a customer turns up anyway because their existing booking was never actually touched by the closure - it just stopped new bookings being made, without doing anything about the one that already existed. Closing the gap between nobody being able to book it anymore and everyone who already had booked it having been dealt with is what actually prevents the awkward gate-side conversation.

It's also worth remembering that closures affect regular club members differently to one-off public bookers. A club that trains at the same time every week will notice a closure immediately and probably doesn't need much explanation. Someone who booked a single session weeks in advance, and has no other contact with the track, needs to actually be told - which is exactly why the closure needs to be reflected in the booking system itself, not just mentioned to whoever happens to be around that week.

Planning around the closures you can see coming

Some closures follow a predictable seasonal pattern, which makes them easier to plan for than they might first appear. Resurfacing work tends to happen in the closed season when a track sees less use. Severe weather closures cluster in the winter months. Recognising that pattern means a lot of the year's likely closures can be pencilled in well before they're strictly necessary, rather than treated as a surprise each time they come round. A track that reviews its typical closure calendar once a year, rather than reacting to each one individually, tends to handle them with far less last-minute scrambling.

The bigger picture

None of this is about the closures themselves - tracks close for maintenance all the time, and nobody minds that. What people mind is turning up to a locked gate having paid for a slot that was never actually available. Handling exclusions properly isn't about avoiding closures. It's about making sure the booking system always tells the truth about what's actually bookable, on any given day, without anyone having to remember to mention it separately.

Manage Closures on TrackSlot