Access hardware driven by live business status
Several sites, more than one hardware vendor, and entry lists that were uploaded by hand.
The challenge
- Access lists were exported and re-uploaded manually, so entry rights lagged behind reality.
- Each site ran different hardware with its own tooling, and none of it was integrated.
- Entry events could not be matched to customers, so attendance was not reportable.
- When a reader or turnstile failed, the first indication was a queue at the door.
Capabilities
- Access control
- Device integration
- Real-time APIs
- Monitoring
What made it complex
Named rather than counted. These are the moving parts the operation already had, and the ones the system had to hold together.
Credential types issued from the member record
- Card
- QR
- Mobile
- Terminal
Hardware behind one interface
- Readers
- Turnstiles
- Terminals
- More than one vendor, across several sites
Checked at the moment of presentation
- Current status
- Plan
- Rules
Control points
- Per-device authentication with rotating credentials
- Signed, short-lived tokens cached at the door
- Connectivity and error monitoring per device
ConnectsAccess hardware from more than one vendor across several sites, the member record, and attendance reporting.
The solution
What we designed and built, part by part.
- 01
Live entitlement checks
Every access decision resolved against current status, plan and rules at the moment of presentation.
- 02
One interface, many vendors
A common internal interface with per-vendor adapters, so adding or replacing hardware leaves the business logic alone.
- 03
Central credentials
Cards, QR, mobile and terminal credentials issued and revoked from the member record.
- 04
Entry data
Entries, exits and refusals recorded against the customer and made available to attendance reporting.
- 05
Device monitoring
Connectivity and error monitoring per device, alerting the operations team before members are affected.
Architecture
The shape of the system, named component by named component. Deliberately abstract: no hostnames, endpoints, credentials or infrastructure layout.
Access integration
Decision
- Entitlement API at the doorShared
- One interface, per-vendor adapters
- Card, QR, mobile and terminal credentials
Sites
- Readers and turnstiles, several vendorsConnected
- Device monitoring and alerts
- Entry events into reporting
Connected: an existing or third-party system we integrated withShared: where the two systems meetOne decision path, many vendors behind it.
Technical detail
Described at the level that shows the work without exposing anything belonging to the client.
- Entitlement API with a strict response budget at the door
- Signed, short-lived tokens cached locally so a network interruption degrades safely
- Per-device authentication with rotating credentials over encrypted transport
- Event ingestion sized for peak entry periods
How it was governed
A delivery standard, not a record of this project. Every engagement is held to these, so nothing below is evidence about this system specifically. The project detail above is.See the method.
Scope agreed before work started
A written scope and a system design, kept current through build and integration. No part of any of these projects began on a verbal scope.
Releases that could be undone
Environments, deployment and a rehearsed way back were part of the build, not added afterwards, so a bad release was recoverable rather than an incident.
Decisions that can be audited
Administrative actions and consequential decisions are logged and reviewable, with roles and row-level rules enforced on the server rather than in the interface.
Integrated without replacement
Where a system was doing its job it was connected rather than rebuilt. Replacement had to earn a business case in every one of these engagements.
Handed over, not held hostage
The data, the integrations and the deployment belong to the client, with export and deletion paths built in advance.
Still our responsibility after launch
Monitoring, support, integration upkeep and a continuing improvement backlog, because launch is a step in the route rather than the end of it.
The outcome
Described qualitatively. Commercial results belong to the client and are shared only with their permission.
- Entry rights reflect commercial status in real time, with no manual list maintenance
- Attendance and utilisation became reportable business data
- Hardware faults are detected and dispatched before they become a customer problem
- New sites are brought online without bespoke re-engineering each time
What we owned
The entitlement API, the vendor adapters, credential issue and revocation, device authentication and monitoring.
Running after launch
Connectivity and error monitoring per device, alerting the operations team before members are affected.
What this demonstrates
Identity and access, physical systems driven by business data, vendor-neutral integration and device security.
Other projects
Multi-system operator · finance and operations
Systems that finally agree, and numbers leadership can use
ReadFlagship vertical: fitness & wellness · multi-site operator
A single platform for members, payments and access
ReadCustomer services · multi-channel demand
Every enquiry answered on the channel the customer chose
Read
Tell us what your business is trying to do.
The first conversation is about your operation, not our services. If we are not the right fit, we will say so.