The problem with a stack of tools
Most multi-site operators did not choose a disconnected software stack on purpose. It grew. A booking tool came first, then a separate payroll system, then an accounting package, then a maintenance spreadsheet, then a folder of signed PDFs. Each one solved a real problem on the day it was bought. Together they created a new one: the data lives in different places, in different shapes, owned by different teams.
The cost shows up at the joins. A casual entry sold at the front desk is an operational event, a line in the accounts and, indirectly, a reason a shift needed staffing. In a stack of separate tools, those three views are three different records that someone has to reconcile by hand. The finance team exports a report, reformats it, and keys it into the ledger. HR keeps its own list of who works where. Maintenance tracks assets in a spreadsheet that the accounts never see. Nobody is wrong, but nobody has the whole picture either.
What an integrated operating platform changes
An integrated operating platform takes a different starting point. Instead of connecting separate systems after the fact, it runs the whole operation on one identity and one shared data layer. A member, a staff member, an asset or a transaction is recorded once. Every product that needs that record reads the same copy.
This is the difference between integrated apps and an integrated platform. Integrated apps talk to each other through connectors and scheduled exports that you have to build, monitor and fix. An integrated platform shares the data structurally, so the join is always live. When the front desk takes a payment, finance already has it. When HR onboards a new instructor, the rostering system already knows.
For an operator running several venues or brands, that structural join is the whole point. The questions that matter at head office, such as how a program is performing across all sites or what the network actually earned this week, have direct answers rather than a reconciliation project behind them.
How Cohiva puts the model into practice
Cohiva is built as one platform with purpose-built products on top of it. Each product is strong on its own and stronger connected, because they share one identity and one data layer.
- Complex runs aquatic and leisure facilities: classes, memberships, point of sale, bookings and access control. It is the commercial anchor, the place where most of the day-to-day activity is recorded.
- Crunch is the finance product, an ERP with real-time profit and loss, multi-entity consolidation and a 13-week cash forecast. Transaction data flows natively from Complex into Crunch, so the books reflect what happened at the desk today.
- Culture is the HRIS for shift-based operators: onboarding, rostering, leave, timesheets and payroll export. Staff records flow from Culture into Complex, so the people on the timetable are the people HR has scheduled.
- Control is the maintenance system. It manages assets, work orders and preventive maintenance, and it posts fixed-asset depreciation straight to the ledger, so the maintenance and finance views of an asset stay joined up.
Signing, governance, marketing and training round out the suite through Sign, Quorum, Campaign and Campus. The point is not the count of products. It is that they sit on the same foundation, so adding one does not mean adding another integration to maintain.
One identity, one bill
The shared data layer comes with two practical benefits that operators feel quickly.
One identity means a person signs in once and is the same person everywhere. A staff member onboarded in Culture, rostered against Complex and named on a Quorum resolution is one identity, not three accounts to provision and deprovision. That is simpler to administer and easier to keep secure.
One bill means the platform is bought as a platform. Rather than a tangle of separate contracts, renewal dates and per-tool pricing, the operation runs on a single relationship that grows with you. You can start with the product you need most and add others as the data flow earns its place.
What the model is not
It helps to be clear about what an integrated operating platform does not mean, because the phrase invites a few wrong assumptions.
It does not mean one giant product that tries to do everything and does each thing poorly. Cohiva is a set of purpose-built products, each strong in its own category, that happen to sit on a shared foundation. You get the depth of a specialist tool with the join of a platform.
It does not mean a rigid all-or-nothing rollout. You adopt products one at a time, in the order that suits your operation, and each new product joins the data layer that is already there. The platform grows with the business rather than demanding a single switch-over.
It does not mean locking your data away. A shared data layer is about removing duplication inside your operation, not about hiding your records from you. The point of one source of truth is that you can finally trust the figures, because there is only one set of them.
Where to start
You do not adopt the whole platform on day one. The sensible path is to start with the part of the operation that hurts most. For a leisure operator that is often facility management, so Complex goes in first and immediately gives finance a live feed into Crunch. For a finance-led organisation it might be the other way around.
If you run aquatic centres, see how the bundle fits in solutions for aquatic centres. If your structure is a franchise or multi-brand network, solutions for franchises walks through consolidation, disclosure and brand-compliant marketing on one platform. For the trade-offs against buying separate tools, read integrated suite vs point solutions, and for a worked example of the model in a leisure business, read running a multi-site leisure operator on one platform.
The thesis is simple to state and harder to live without once you have it: run the operation once, in one place, on one set of records, and let every team see the part that is theirs from the same source of truth.