What the Leisure Industry Can Learn from Toyota — And How OpsPal Can Help
Part 2 of 3: Asking why, visibility and systems
A brand-new leisure centre is not safer than a fifty-year-old one. It’s just newer. The building doesn’t run itself — the system does. A shiny new site with no operating system behind it develops exactly the same problems as the tired old one down the road. It just gets noticed faster.
This is Part 2 of three, looking at what Toyota got right and how OpsPal can help you put the same thinking into practice. Part 1 covered fixing the system instead of blaming the team, catching problems early, and why annual audits are too late. This part covers three more: asking why properly, real leisure centre visibility instead of a stale monthly report, and what a brand-new building actually needs to run well.
Ask Why Properly — In the Room, Not Just in the Log
A problem gets logged, gets fixed, and gets closed. Job done — until the same thing happens again in six weeks. Toyota’s answer to that was simple: keep asking why until you hit the actual cause, not just the nearest excuse.
That’s not a box to tick on a form. It’s a conversation, done properly, in a review meeting — not something any piece of software does for you. What software can do is make sure that conversation has something real to work with. A problem log that shows what happened, when, who flagged it, and how it was closed gives a meeting something to interrogate. A verbal fix and a shrug doesn’t.
HSE’s own guidance on accident investigation makes the same point for a reason: finding the underlying cause, not just the immediate one, is the only way to stop it happening again.
Real Leisure Centre Visibility Beats a Stale Report
Toyota calls it genchi genbutsu — go and see for yourself. Don’t run a business from a report someone else wrote about it. That holds whether you run one site or fifty. Real leisure centre visibility means seeing what’s actually happening today, not what a report said three weeks ago.
Some OpsPal customers take that visibility further and put the live task dashboard on a screen in reception for every member walking in to see. It’s not there to catch staff out — it tells the person paying for membership that the business doesn’t run itself; someone’s actively managing it. Staff prefer the screen to be green when a member is in front of it, so tasks are done as needed — because no one wants to be the reason it shows red.
Run more than one site, and that same leisure centre visibility does something extra: it tells senior management which site actually needs walking. Genchi genbutsu was never about trusting a dashboard instead of your own eyes — it’s about knowing where to point them. A site showing red tells a director exactly where to go and see for themselves, rather than guessing from a report that’s already three weeks stale.
A New Building Isn’t a New System
Walls, plants, and a ribbon-cutting photo don’t give a site an operating system. Eighteen months after opening, a brand-new leisure centre can carry exactly the same organisational problems as the fifty-year-old one it replaced — just under fresh paint and with less excuse for it.
The fix isn’t the software. It’s building the operating system deliberately, based on what’s actually proven to work, rather than letting one grow by accident out of whoever happened to be in the room in month one. That’s best practice doing the job it’s meant to do — built in from day one, not bolted on once things start slipping.
How OpsPal Can Help
The problem log and audit trail exist so the “why” conversation has real data to work from, not guesswork. Live, visible status — on a manager’s screen or a reception TV — does the job whether you run one site or several. Run more than one, and it also tells you which site to go and stand in. And for a site with no operating system yet — new build or otherwise — OpsPal doesn’t force a template on it. It carries whatever properly designed system you build in the structure that system actually needs.
Your Monday Morning Action
Pick one problem that’s happened more than once this year. Don’t ask who caused it. Ask why the system let it happen a second time before anyone dug into it properly. Part 3 closes the series: refusing the trade-off between speed and compliance, planning a rollout properly instead of rushing it, and the kind of trust that has to be built years before you ever need it.
