Trentham Padel: Remote Operations Technology Architecture

Prepared for: Ade Whetton
Author: Manus AI
Date: 7 August 2026
Status: Planning-level design; fire, security, insurance and site surveys still required
Currency: GBP, excluding VAT unless stated

Decision: Build a hybrid, locally resilient system. The booking platform may authorise access and scheduled controls, but safe escape, fire response and basic local operation must never depend on the internet, a cloud API or a remote operator.

1. What the system can—and cannot—do

The technology can remove most routine reception work. A paid booking can generate a unique time-limited credential; a local controller can activate the relevant lighting and ventilation schedule; CCTV, door, network, vending and environmental faults can create alerts; and a remote duty manager can diagnose many faults, talk to customers, resend access, reboot approved devices, isolate a failed machine, refund or relocate a booking and dispatch assistance.

It cannot remotely clear a physically jammed vend mechanism, replace a failed door closer, clean a spill, assess cracked court glass, provide first aid, supervise junior activity or safely serve alcohol. The operating model therefore needs a local responder, contracted engineer network and clear closure authority as well as software.

2. Architecture principles

3. Electronic access control

3.1 Main entrance

The main public entrance should use a commercial networked reader capable of booking-linked PIN, QR or mobile credential entry. Playtomic’s official hardware workflow supports compatible hardware-provider integrations through an API token, court binding, keypad tests and configurable access windows. It states that connected reservations receive unique four-digit codes and that a code refreshes ten minutes before the match.1

That confirms a supported integration route, but it does not prove that every provider supports the building entrance, offline caching or the venue’s fire strategy. These requirements must be written into the hardware contract and tested.

The preferred door arrangement is an electromechanical latch/strike or lock with single-action mechanical egress from inside. A magnetic lock is not automatically unlawful, but the NSI states that suitability depends on the doorset, escape strategy and user type; an arrangement requiring a separate emergency button and then a handle may create an unacceptable two-action escape.2 Where powered locking is relied upon, release on alarm, loss of power and appropriate override must follow the fire strategy and BS 7273-4 principles.2

3.2 Court gates

Six separate powered court locks are not recommended as the base design. Once a verified player is inside the secure building, court-level maglocks add cost, egress complexity and additional failure points without necessarily improving yield. Use clear court allocation, occupancy sensors/door contacts and CCTV. Add powered court gates only if later evidence shows persistent unauthorised use, theft or tournament zoning requirements.

3.3 Staff, plant and retail zones

Back-office, comms, stock, bar and plant rooms should use encrypted staff credentials and a role-based access matrix. Public credentials must never open those zones. Doors on an escape route require compatible certified hardware and must preserve the performance of any fire-rated doorset; cutting or modifying a certified door beyond the manufacturer’s approved design can invalidate its evidence of performance.2

4. Fire and emergency boundary

Approved Document B volume 2 is the relevant England guidance for buildings other than dwellings, but the final solution is site-specific and must be coordinated with the fire-risk assessment, fire engineer, building control and Responsible Person.4 The design must avoid the common mistake of treating a green emergency release box or remote unlock as a substitute for a coherent escape design.

The hardwired fire-alarm interface must bypass cloud software and booking logic. Each controlled door is assessed individually for whether it is an escape door, fire door, compartment boundary or ordinary secure door. Public panic routes may require BS EN 1125-type hardware; trained/staff routes may use BS EN 179-type arrangements; electrically controlled exit systems have a different standard path.2

The following events must be demonstrated at commissioning and at the maintenance interval set by the fire strategy:

5. Network and cyber design

The venue should have business-grade FTTP, automatic 4G/5G failover and a managed firewall. The internal network is divided into at least five logical zones: administration, payment/POS, access-and-IoT, CCTV and guest Wi-Fi. Guest devices are client-isolated and cannot discover or contact operational equipment. Payment terminals use vendor-approved connectivity and are never placed on the same unrestricted network as cameras or customer Wi-Fi.

The NCSC’s current small-organisation guidance stresses that cyber security cannot be left to one person and highlights backups, device/account protection and incident readiness.5 For this venue, that translates into multi-factor authentication for every cloud administrator, named—not shared—accounts, a password manager, removal of vendor defaults, approved update windows, current asset/configuration registers and tested restore copies.

6. CCTV, intercom and alarm monitoring

A six-court warehouse-scale venue is likely to need approximately 16–24 cameras, subject to a proper operational-requirement survey. Coverage should include entrances/exits, customer circulation, court overviews, café/bar till area, rental lockers/vending, external approach, waste/service yard and car-park routes. Camera placement should capture useful evidence rather than simply maximise count.

The ICO states that CCTV operators must document purpose, lawful basis, responsibility, security, sharing and retention; use visible signage; limit fields of view; secure footage; and support information-rights requests. Cameras should not normally operate in toilets or changing rooms. Continuous audio is especially intrusive and usually difficult to justify.6 A fixed 30-day retention period is not a legal default. The initial design should use 21-day rolling retention, subject to a CCTV data-protection impact assessment, insurer requirements and demonstrated incident need.

The recommended monitoring design is event-led rather than paying a guard to watch all cameras continuously. Door-forced/held, after-hours motion, alarm verification, camera loss and defined safety/help-point events go to an accredited alarm/video centre or duty function. A video intercom at the public entrance and strategically placed help points connect customers to a remote duty manager. Ambient court audio recording remains off; two-way audio is activated only for a call or defined security intervention.

7. Booking-linked automation

The booking platform should authorise the event, while a supported hardware integration and local edge controller execute it. The controller receives or caches the day’s bookings, maps court IDs, schedules lights/ventilation, records outcomes and exposes a manual override. Failed cloud communication must not cause doors to lock people in, leave all lighting permanently on or prevent local recording.

A single “turn everything on” integration is unacceptable. High-load equipment should start in staggered groups, commands require acknowledgement and every automation has rate limits, timeouts and a known safe state.

8. Remote support operating model

8.1 Four response layers

HSE guidance notes that lone workers need training, supervision, monitoring and support because the consequences of an incident can be greater when immediate help is absent.7 Remote video alone is not an adequate lone-worker arrangement. Cleaning, cash/alcohol close, hazardous maintenance and known aggression risks may require check-in/out, duress devices or two-person working.

8.2 Severity and service objectives

These are target service objectives for procurement, not promises until a supplier contract names coverage hours, exclusions, measurement method and credits.

9. Physical jam and failure playbook

A computer can detect and contain a mechanical jam; it cannot physically remove it.

Sections from this point were reconstructed from the underlying validated research notes after the original was truncated in transit.

The design therefore includes at least four manual backup rackets held in a separately releasable reserve, a documented physical-response route for every customer-facing asset, and a refund-first customer recovery rule so that no single mechanical failure strands a paying customer. Remote tooling contains the failure and keeps the customer whole; a person clears it.

10. Data-protection and regulatory actions

Before the first camera records or the first booking-linked credential is issued, the venue must complete a short regulatory checklist:

11. Cost structure and procurement discipline

The parallel cost scan produced broad, overlapping ranges rather than supplier quotations, and it mixed the fire-alarm and emergency-lighting fit-out with the digital-operations stack. No raw scan total should enter the financial model. The architecture budget must instead be built from written quotations and split into four non-overlapping buckets:

Double counting between bucket 1 and bucket 2 is the single most likely budgeting error, because access-control and fire suppliers both quote door hardware, interfaces and commissioning. Every quotation must state which doors, interfaces and certificates it includes.

12. Commissioning evidence pack and go-live gate

Unstaffed operation begins only when a named commissioning pack exists and every test in it has passed. The pack should contain, as a minimum:

1. door-by-door schedule recording escape classification, hardware standard, release behaviour and test result;
2. fire-alarm interface test records covering alarm activation, mains isolation, controller failure and LAN/WAN isolation (section 4);
3. network segmentation and failover test results (section 5);
4. CCTV operational-requirement document, DPIA, signage plan and retention setting (sections 6 and 10);
5. booking-to-access end-to-end tests, including cached-booking behaviour during a simulated WAN outage (section 7);
6. alert-routing tests proving every defined fault reaches the duty function within the target acknowledgement time (section 8);
7. the jam-and-failure playbook with named responders, contact routes and stock of physical backups (section 9); and
8. signed acceptance from the fire-risk assessor, the access-control installer and the insurer for the unstaffed operating mode.

Industry guidance on integrating access control with fire safety should be used as the compliance checklist frame for items 1 and 2.2 8

13. Decision summary

The unmanned model is achievable with current, officially supported integrations, but only as a whole system: booking platform, access hardware, local controller, monitoring, human response layers and commissioning evidence. Any one of those procured in isolation recreates the risk this architecture is designed to remove.

References