Five Levels of Multi-Site Operations Maturity: From Phone Calls to a Shared Operating System

The short answer

The maturity of a distributed asset network is not a technology budget. In practice it unfolds in five states: reactive call-when-it-breaks work, formalised work orders, standardised processes running on one shared system, data-driven and predictive operations, and finally a shared operating system that proposes actions within set guardrails while a person keeps the final say. Most networks sit between levels 1 and 3. Diagnose where you are today, then climb one level at a time — starting with documented standards and trustworthy data rather than artificial intelligence.

Key takeaways

Maturity is a sequence of five states — reactive phone calls, formal work orders, standardised processes on one shared system, data-driven and predictive operations, and a shared operating system — not a count of the tools you own.
Most networks sit between levels 1 and 3; the hardest jump is from level 2 to level 3 because it is an organisational change, not a technical one.
Fix documentation, asset registers and data quality before buying analytics or AI; forecasting models fail on inconsistent and incomplete history.
Distinguish preventive (calendar-based), condition-based (threshold), predictive (forecast) and prescriptive (recommend or automate) maintenance; predictive pays off mainly on critical, costly assets.
Standardise the non-negotiables — safety, compliance, brand and core processes — and let genuinely local choices such as vendors, schedules and local rules flex.
Move one level at a time: pilot on a single site or tier, budget for change management, and govern the network with a few shared KPIs.

Why measure multi-site operations maturity

A single building can be run on the discipline of its site leader. As an organisation grows to dozens or hundreds of sites — retail chains, bank branches, telecom nodes, warehouses, malls — every new location brings its own habits, contractors, staff and scattered data. Consistency erodes, headquarters flies blind, and problems compound faster than the management headcount grows. The predictable result is uneven service, compliance risk and lost leverage with suppliers.

A maturity model gives a common scale so operations, procurement, IT and finance can agree on where the network stands and what to do next. Borrowing the classic first-to-fifth-level logic used for process and maintenance maturity, the model measures not which software you own but how consistently processes, data, roles and suppliers behave across sites. The practical payoff is that you stop buying tools to fix symptoms and instead close capability gaps in the right order.

The same process is executed differently at each site.
Reports arrive late because they are assembled by hand.
There is no single asset register or history of work per site.
Field staff improvise their own ways of working.

Levels 1 and 2: from phone calls to a structured work-order flow

Level 1 is reactive ad hoc work. A request reaches the team by phone, e-mail or word of mouth; there is no asset register and no request log. The engineer on site improvises, and nothing is recorded, so there is no history to compare sites, prove compliance or negotiate with contractors. Each location runs its own way and the central operations function exists mostly on paper.

Level 2 is formal but still reactive. A helpdesk or dispatcher logs requests in a single register, spreadsheet or ticketing tool, and roles are defined. But work is still triggered mainly by breakdowns. Data is collected yet not systematically analysed, monthly reports are assembled by hand, and site-level tools are not integrated. The move from level 1 to level 2 is inexpensive: register assets and requests, define who does what, and establish a basic escalation path. The value here is discipline, not technology.

Level 3: standardisation and a single system of record

Level 3 means documented standard operating procedures and service levels, preventive maintenance schedules, digital checklists and walkthroughs, structured contractor management and a shared system of record (a CAFM- or IWMS-class platform) used across the whole network. A new engineer at any site can follow the procedures to handle most situations without escalation. Apply the principle of standardising where you can and customising where you must: safety, compliance, brand and core processes should be identical everywhere, while truly local choices such as vendors, scheduling and local rules can flex.

This is the biggest organisational jump. It requires executive sponsorship, change management and patience with staff resistance, because you are asking people to abandon habits that may have taken years to form. A visible pattern from networks that complete this stage is replacing per-site legacy tools with one integrated platform that connects requests, planned walks, materials and analytics, often through a mobile app with QR-coded checkpoints and photo evidence of defects. In one reported Russian shopping-centre project spanning several federal regions, request handling shortened from days to hours and reporting became uniform once sites shared a single system. Treat such figures as indicative rather than guaranteed: outcomes depend on the starting state and the quality of change management.

Procedures, service levels and checklists live in one system.
Assets, requests, planned work and contractors are managed in a single record.
Site leaders have defined authority thresholds and escalation paths.
Common KPIs and management dashboards start to appear.

Level 4: portfolio data and prediction

At level 4, data becomes the basis for decisions rather than material for monthly reports. Leadership watches real-time dashboards and compares sites against the same indicators instead of waiting for spreadsheets. Under-performing sites, contractors and asset types become visible early, so you can act before a problem spreads across the network. Work is triggered not only by a calendar but by asset condition or a predicted failure: a sensor threshold, a usage trend or accumulated runtime signals the problem before breakdown.

The trade-off is that sensors, integrations and analytics cost money and depend on trustworthy data. Distinguish preventive maintenance (fixed interval), condition-based maintenance (threshold signal) and predictive maintenance (forecast from data). Predictive approaches earn their keep on critical, expensive assets where downtime is costly, not on cheap low-risk equipment. Resources freed up by fewer emergencies can then be redirected into capital planning and smarter supplier negotiations, which is where maintenance data proves its strategic value.

Level 5: a shared operating system

Level 5 is not a collection of better tools; it is a single governed operating system for the whole network. One system of record, role-based workflows, unified supplier management and one data model across all sites. Analytics no longer only show what happened — they propose or prepare actions within defined guardrails in a prescriptive, learning loop. Crucially, the final decision stays with a person: automation works inside clear boundaries rather than replacing human judgement.

Reaching level 5 requires data governance and specialised talent, and it should not be an all-at-once goal. For most networks a more realistic ambition is stable, well-run levels 3 and 4 across the portfolio rather than a nominal level 5 on paper. Full level 5 makes sense for organisations that want to industrialise operations into a repeatable capability and already have clean history, a single system of record and a culture willing to delegate bounded decisions to algorithms.

Sequencing the move up the ladder

The progression follows a logic you cannot safely skip. Start with a current-state map of systems, shadow spreadsheets and the path a request takes from report to completion. Then build the asset register, the request log and documented procedures; next introduce a shared system of record; only then clean up data quality and add analytics and automation. Buying a platform before processes are defined, or adding artificial intelligence on top of fragmented and incomplete history, produces predictable disappointment.

Move one level at a time and validate on a pilot — a single site or a tier of similar sites — before rolling out network-wide. Budget seriously for change management: training, communication and visible quick wins, because resistance on site can quietly kill adoption. Measure progress with a few shared indicators across the portfolio: response time, completion rate of planned work, share of reactive versus planned requests, cost per site and user or tenant satisfaction.

Choose the target level by network size and heterogeneity. A small network of ten sites can run well on level 2 discipline with elements of level 3. A network of hundreds of sites across regions becomes very hard to manage without level 3, and regulatory requirements, franchise agreements or outside tenants push towards levels 3 and 4. Full level 5 is justified only for companies that want operations to become a proprietary, replicable competence rather than an ongoing cost centre.

Put it into practice

Multi-site operations maturity self-assessment

Score the twelve statements below against your network. Give one point for each statement that is true for a majority of your sites. Your current level is the highest level where every statement in that band holds; partial matches mean you are mid-transition.

A request reaches the team only by phone, e-mail or word of mouth, with no central register. — Level 1
Each site keeps its own spreadsheet or log; headquarters cannot consolidate data automatically. — Level 1
Work is performed only after something fails; there is no preventive or condition-based programme. — Level 1
Requests are logged in one register or helpdesk tool, but most work is still reactive. — Level 2
Data is collected but not systematically analysed; monthly reports are assembled by hand. — Level 2
Documented procedures and service levels exist, and a new site engineer handles most scenarios without escalation. — Level 3
A shared system of record covers assets, requests, planned work and contractors across all sites. — Level 3
Planned walkthroughs and digital checklists (including QR checkpoints and photo evidence) run in the same system. — Level 3
Leadership reviews real-time dashboards and compares sites on the same KPIs. — Level 4
Work is triggered by asset condition or predicted failure, not only by the calendar. — Level 4
Asset data feeds capital planning and supplier decisions across the portfolio. — Level 4
The network runs as one governed operating system; the platform proposes or prepares actions within set guardrails and a person keeps the final decision. — Level 5

Questions people ask

Which maturity level should my network actually target?

The target depends on size, heterogeneity and risk, not on the number of sites alone. A small network of ten sites can run well on level 2 discipline with elements of level 3. A network of hundreds of sites across regions is very hard to manage without level 3 standardisation, because each site brings its own habits and contractors. Regulatory requirements, franchise agreements, outside tenants and external audits push towards levels 3 and 4. Full level 5 is justified only for organisations that want to turn operations into a proprietary, replicable competence. Set the goal one level above your current state rather than aiming for the maximum.

How do I move from level 1 to level 3 without a large budget?

There is no universal figure, but the cheapest path is to respect the sequence. First map your current processes and build an asset register and request log; then document procedures and service levels; only after that introduce a shared system of record. A significant share of budget should go to change management — training and working with resistance — or the platform will go unused. Validate on a pilot at one site or tier of sites before rolling out network-wide. According to analyses of digital maturity programmes, standardisation stalls most often not from technology cost but from a lack of executive sponsorship.

What should I standardise first across dozens of sites?

Start with the most frequent and highest-risk processes: emergency response, safety and compliance walkthroughs, preventive maintenance, contractor onboarding and inspection, and handling of user or tenant complaints. Separate the non-negotiables — safety, compliance, brand and core processes that must be identical everywhere — from genuinely local choices such as vendor selection, scheduling and local rules. For each chosen process define the steps, the owner, the deadline and a way to prove completion (signature, timestamp or photo). This procedure-plus-proof pair gives you control without excess bureaucracy.

When does predictive maintenance pay off versus preventive?

Preventive maintenance runs on a fixed calendar or runtime interval regardless of actual condition. Condition-based maintenance starts when an indicator such as temperature or vibration crosses a set threshold. Predictive maintenance uses sensor data and history to forecast failure and schedule intervention just in time. Prescriptive maintenance goes further and recommends or automates the optimal action, often with AI. Predictive models and sensors cost money, so they earn their keep on critical, expensive assets where downtime is costly — not on cheap, low-risk equipment. Predictive analytics also requires clean, complete work history; without it, there is nothing to train the model on.

Do all sites need the same software, or are shared standards enough?

Shared standards are the foundation, but without a single system of record they do not produce visibility or comparability. If each site runs its own spreadsheet or tool, headquarters cannot consolidate data automatically, compare sites or control contractors consistently. Still, do not introduce a platform before processes are defined and data is in order. A small network may be fine with a lightweight register and request log; a network of dozens or hundreds of sites needs a common system of record for assets, requests, planned work and contractors. The standard and the system reinforce each other: the procedure defines how to work, and the shared record makes the result visible and verifiable.

How long does a typical level-to-level migration take?

There is no fixed timetable, but plan in quarters rather than weeks. Moving from level 1 to level 2 — registers, request logging and defined roles — can be done in weeks because it is mostly discipline. The jump from level 2 to level 3 is the slowest because it changes how people work across every site; allow at least a few quarters including a pilot, rollout and change management. Level 4 depends on accumulating clean history, so it rarely arrives before you have several months or more of trustworthy data. Level 5 is a multi-year, governance-heavy journey that few networks genuinely need.

Sources and further reading

Sources were checked when this page was generated. Confirm changing dates, rules and prices with the original publisher.