Who they are

They run private-hire fitness studios across London: self-contained gym spaces people book by the hour, across a growing estate of around 20 sites. The business runs on bookings, availability and access, and all of it grows with every new site that opens.

Availability lives in two places at once. Bookings come in through a third-party booking marketplace and through their own booking system, and the two have to agree. Every bookable space, every hour, at every site, has to say the same thing in both. That reconciliation is the work, and it grows with the estate.

The work, as it actually happened

The customer-success team kept the two systems in sync by hand. Every morning, and again later in the day, someone worked across 23 bookable spaces on the marketplace, updating availability to match the live bookings in their own system, around an hour and a half each pass, with booking emails handled by hand on top. It added up to something like ninety hours a month.

Bookings and cancellations don't arrive on a schedule, though. They come in all day. Because the two systems were only brought back into line twice a day, they drifted in between, and the drift is where it hurt. A slot booked in one place stayed open in the other, so customers turned up to a space someone else had already taken, including the occasional 5:30am surprise booking. And when a cancellation came in late (around 271 a month did), nobody could reopen that slot fast enough to resell it, so it went empty. The manual process cost time, and it cost bookings at both ends.

Why it hadn't been fixed already

The fix was never a mystery: reconcile more often. The limit is how often you can afford to. To keep the two systems properly in step you'd have to reconcile every hour, which means paying someone for half an hour of every hour, all day, indefinitely. So it got done twice a day and everyone lived with the gaps, which is where the double-bookings and the lost rebookings happened.

The off-the-shelf fix was priced out of reach. The marketplace does offer an integration, but it's sold per site at around £250 a month each. Across an estate of twenty-odd sites that's roughly £5,000 a month to solve an internal ops problem, which was more than it was worth. The only other route was to build the bridge themselves, and that meant pulling their own product engineers off customer-facing work. So it stayed on the list and never got done.

What we did

We watched the real work. They recorded the reconciliation exactly as their team does it, morning and evening, rather than describing it to us in a workshop.

We rebuilt it before we sold it. From those recordings we mocked up both their own booking system and the marketplace, and on the demo call we ran the automation live against the mock-ups, so they watched the real thing working against copies of their own screens before they'd signed anything, rather than sitting through a slideshow.

We built what they needed, not what they asked for. They came to us with the solution already pictured: put a bot on the job and run the same twice-a-day sync more often, hourly instead. A faster, mechanised version of the manual task. We didn't build that. The need underneath the request wasn't the manual job done faster; it was simply for the two systems to stay in sync. And a booking is a single event, so there's no reason to re-check everything on a clock. Instead of a bot polling on a timer, we designed it to react the moment a booking changes and update just the one slot that moved. That's the step a client can't hand you on a spec, and not because they couldn't follow it: working out the best way to do something is a job in itself. It takes knowing what's currently possible and the time to weigh the options, and that time is what they don't have. Working it out is the part we take on.

We designed around the exceptions. Four that mattered. The site names don't match between the two systems, so we drove everything off a simple site-mapping sheet rather than assuming the names line up. And we handled the partial-hour trap: a booking running 6:30 to 7:30 was leaving the 6:00 slot wrongly open, the kind of edge case that reintroduces the double-bookings you're trying to remove. Marketplace bookings are capped at 24 hours ahead, deliberately, so that direct bookings keep the higher-value slots, and the sync respects that window rather than opening everything. Adding a guest to a booking stays with their team, because it needs a judgement the systems can't make. We also found their own systems reject simultaneous logins, so the runs are deliberately staggered.

A mix of techniques, chosen to fit each system. There's no single tool behind this. It's a mix of APIs, webhooks, a bit of code and some browser automation, picked to suit each platform rather than forced through one. Where a system offers a clean way in, we use it; where it doesn't, browser automation still does the reaching. It's what lets the sync act on the one slot that changed rather than grind through everything on a schedule.

We run it. This is a managed service. The daily run goes out across all 20 sites, and after each run a summary and a screenshot land in Slack so the team can verify at a glance, with full session replays kept so any run can be watched back. Their CS team still does a daily spot-check; they watch it the way you'd watch a capable new hire for the first few weeks.

The outcome

The number. Around ninety hours a month of manual reconciliation, now handled for them. Keeping the two systems in step meant a sync every morning and a second one later in the day, across every bookable space at every site. That work no longer needs doing. The team's own read on what it gives back is one to two hours a day.

The second-order effect: more bookings. This is the part that has ended up mattering most. Because the sync catches each booking and cancellation as it happens, a slot that frees up reopens instead of sitting empty, and they are already seeing cancelled slots get resold that used to be lost. The time saved was the reason they started; the revenue coming back through recovered cancellations is what they're most excited about now.

In their words, the morning it went live across every site: “1–2 hours saved per day thank the gods 😂” from their operations lead, and “🚀🚀🚀 1–2 hours more a day to sell!” from their exec sponsor.

Proof it's still running. The daily run has gone out across all 20 sites every morning since, holding steady week after week. New sites are folded in by adding a row to the site sheet: a new South Bank location was picked up this way, with no rebuild. The whole slot workflow was re-engineered underneath them mid-flight, cutting runtime four- to five-fold, without them having to do anything. The intraday sync now keeps availability correct through the day rather than only at the morning run, which is the event-driven piece that closes the twice-a-day gap.

What's next

The next step came off the back of this one. Having seen what the approach can do, they have asked us to point it at something completely different: reviewing their sites' CCTV to check the right people are using the right space at the right time. It's a new use case and a potentially valuable one, the sort of thing a client only thinks to ask for once they've watched the first hard problem get solved. We're starting on it together.