A single platform for members, payments and access
Member data, billing, attendance and door access lived in four systems that regularly disagreed with each other.
The challenge
- Membership status was authoritative in one system, billing in another and physical access in a third.
- Freezes, upgrades and cancellations were processed by hand, so they were processed inconsistently.
- Failed payments surfaced days late, after the member had already used the facility.
- Head office could not see active membership, attendance or churn without assembling exports.
Capabilities
- Membership
- Payments
- Operations
- Reporting
- Access control
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.
Operating functions in one platform
- Member record and lifecycle
- Billing and collections
- Entitlement
- Front-desk console
- Management reporting
Reading the same member record
- Payment provider
- Member apps and portals
- Front desk
- Management reporting
- Door hardware
Lifecycle changes that had been manual
- Freezes
- Upgrades
- Cancellations
- Failed payment retries
Control points
- Role-based permissions
- Append-only audit trail on every contract change
- Reconciliation against the payment provider
ConnectsThe payment provider, member apps and portals, the front desk, management reporting and the door hardware, all reading one member record.
The solution
What we designed and built, part by part.
- 01
One member record
A single member entity with an explicit lifecycle, owning status for every other system that needed it.
- 02
Billing and collections
Recurring plans, pro-rata changes and add-ons, with automatic retries and a reconciliation view against the payment provider.
- 03
Entitlement service
One real-time answer to whether a person may enter, book or use something, shared by portals, apps and door hardware.
- 04
Staff console
A fast screen for the front desk: find a member, fix a payment, freeze a plan, log a conversation.
- 05
Management reporting
Live active membership, joins, cancellations, attendance and collections by site, with drill-through to the records.
Architecture
The shape of the system, named component by named component. Deliberately abstract: no hostnames, endpoints, credentials or infrastructure layout.
People and surfaces
- Member apps and portals
- Front-desk staff console
- Management reporting
Platform
Core
- Member record and lifecycle
- Billing and collections
- Entitlement serviceShared
Integration
- Payment providerConnected
- Event-driven updates
- Audit trail and role permissions
Connected: an existing or third-party system we integrated withShared: where the two systems meetThe platform, and the surfaces that read from it.
Technical detail
Described at the level that shows the work without exposing anything belonging to the client.
- Managed relational database with a normalised member and contract schema
- Event-driven updates, so a status change reaches access, billing and reporting without batch delay
- Scheduled jobs written to run safely more than once
- Role-based permissions and an append-only audit trail on every contract change
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.
- Member status is consistent across billing, access and reporting at all times
- Lifecycle changes that were manual now run automatically, each one recorded
- Front-desk time moved from data entry to member service
- Leadership works from one live picture instead of assembled exports
What we owned
The data model, billing and collections logic, the entitlement service, the staff console and reporting, then keeping it running.
What this demonstrates
Operational platform engineering: one authoritative record, money, rules and real-time decisions, with an audit trail.
Related insightBuild, buy, or integrateFour systems became one platform here. This is how we decide when that is the right answer and when it is not.Other projects
Multi-system operator · finance and operations
Systems that finally agree, and numbers leadership can use
ReadCustomer services · multi-channel demand
Every enquiry answered on the channel the customer chose
ReadFlagship vertical: fitness & wellness · multi-site operator
Access hardware driven by live business status
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.