A North West class-based business was running payments across three separate systems: a booking platform, a spreadsheet, and a bank account nobody had time to reconcile properly. Nobody could say, on any given day, who had actually paid and who hadn't. We built a payment-visibility dashboard that pulled all three into one place. The result: roughly £12,000 in recovered revenue and about 42 admin hours a week saved.
The problem: payments invisible across systems
Class-based businesses (gyms, studios, coaching programmes, anything running recurring bookings) tend to accumulate payment tools rather than choosing one. A booking platform handles the class schedule. A separate payment processor takes the money. Somebody keeps a spreadsheet to track who's paid for what block, because neither of the other two systems gives a clean answer on its own. That was the situation here. The business had genuine demand: classes were full, members were engaged, the coaching was working. But the admin side hadn't kept pace. Staff were spending hours each week manually cross-referencing the booking platform against bank statements, trying to work out which members had lapsed payments, which had cancelled without cancelling their booking, and which were owed refunds for classes that didn't run. The real cost wasn't just the hours. It was the money that fell through the gap between systems. A member whose card payment failed silently would keep attending classes for weeks before anyone noticed. A member who'd genuinely cancelled would keep getting charged until someone caught it manually. Neither direction was deliberate. It was simply that no single system showed the whole picture, so nobody could act on it in time.
The build: a payment-visibility dashboard
We didn't replace the booking platform or the payment processor. Ripping out systems a business already depends on is expensive and risky, and it wasn't the actual problem. The actual problem was that nobody could see across them. So we built a dashboard that sits on top of the existing tools and pulls the data into one view: who's booked in, who's paid, who's overdue, and what the gap between those three numbers is on any given day. The dashboard flags failed payments the day they happen, not weeks later when someone happens to check a bank statement. It matches bookings against payment records automatically, so a mismatch (someone attending without a current payment, or someone paying without an active booking) surfaces immediately instead of getting buried in a spreadsheet nobody has time to update. Staff get a single screen that answers the question they used to spend hours chasing manually: is this member square with us, right now? None of this required the business to change how members book or pay. The systems members already used stayed exactly the same. What changed was that the business could finally see what those systems were actually doing, in one place, without a weekly reconciliation session.
The numbers
Two figures came out of this build, and we're only citing these two because they're the ones we can stand behind. The dashboard surfaced roughly £12,000 in payments that had failed, lapsed, or gone untracked, revenue the business was owed but had no way of identifying without someone manually cross-checking three systems. And it cut out about 42 admin hours a week that had previously gone into that manual reconciliation, hours that went straight back into running classes and looking after members instead of chasing spreadsheets. We're not going to pretend those numbers generalise precisely to every class business. They're specific to this one business's situation: how many members it had, how tangled its systems were before, how much slippage had built up. What generalises is the shape of the problem, and that's worth paying attention to if any of the description above sounds familiar.
What generalises to other class and gym businesses
If you're running a gym, studio, or any class-based business on more than one payment or booking system, the odds are reasonable that you have a version of this same gap. The signs are usually the same: someone spends real time each week manually checking who's paid, payment failures get caught late rather than immediately, and nobody can answer "how much are we actually owed right now" without opening three different tools and doing the maths by hand. The fix doesn't have to mean switching platforms. In this case it meant building visibility across the tools that were already in place, which is often the faster and cheaper route than migrating an entire member base to new software. The dashboard approach works because it meets the business where it already is, rather than asking it to change its workflow to suit new software. This is the kind of build that sits under what we mean by AI automation for small businesses: not flashy chatbots, but systems that close the specific gaps costing a business real time and real money. If you run a class, gym, or membership business and recognise this problem, it's worth a look at what a similar dashboard could surface for you. We've written more generally about the software we build, and if your business runs on a class or booking model specifically, our page on web design for gyms and studios covers the wider picture of what we build for that sector.
Frequently Asked Questions
Did this replace the business's existing booking software?
No. The dashboard sits alongside the booking platform and payment processor the business already used. Members booked and paid exactly as before. The dashboard's job was to make the existing systems visible in one place, not to replace them.
How long did it take to see results?
The admin time savings were visible almost immediately, because the manual reconciliation work simply stopped being necessary. The recovered revenue built up over the following weeks as lapsed and failed payments were identified and followed up.
Is this only useful for gyms and fitness studios?
No. Any business running recurring bookings and payments across more than one system (clinics, salons, coaching programmes, membership clubs) tends to have the same visibility gap. The pattern is common wherever a booking tool and a payment tool don't talk to each other properly.
Do you name the client in case studies?
Not without permission. This case study describes a real, verified build for a North West class-based business, but we keep client details anonymous unless a business asks us to name them.
If this sounds familiar
The most useful question to ask yourself is a simple one: could you say, right now, exactly how much your business is owed in unpaid or failed payments? If the honest answer involves opening a spreadsheet and a bank statement and doing some maths, there's likely a version of this build that would pay for itself quickly. Get in touch and we can talk through what your own systems are actually showing you, and what they're not.
