Multi-site maintenance: running ten sites without losing your mind
The moment you go from one site to two, shared context fractures. Here is why stretched single-site tools break across locations — and what an isolated-sites architecture fixes.
The moment a maintenance operation moves from one site to two, something structural changes. On a single site, coordination happens through proximity. The team is in the same place. The manager can walk the floor. Everyone knows which pump, which flat, which production bay, because they have all been there.
Add a second site and that shared context fractures. The manager is not always on site two. The team there is not always the same team. By site four or five, the operation has usually outgrown whatever was holding it together: the spreadsheet has a tab per location, the WhatsApp groups have multiplied, and the team spends real time each week just establishing which site a job belongs to and who is responsible. Multi-site maintenance software exists to solve this. Most of it does not solve it well.
What breaks when single-site tools are stretched across locations
The typical progression is to take a tool that worked for one site and apply it to several. The immediate problem is data separation: in a single list, jobs from different sites compete for the same view, and filtering by a location text field only helps if that field was populated consistently across teams entering data independently. The second is notification architecture: a team member who works only on sites one and two should not get alerts about sites four through six, but most stretched tools cannot enforce that, producing notification fatigue. The third is team access: with one shared user list, a site manager can see a client's other properties and a contractor sees operations they have no involvement in.
The fourth problem compounds the rest: there is no way to see across sites without losing the ability to see within them. A manager who needs the high-level picture and also needs to drop into any single site's detail ends up switching views, toggling filters, and holding context in their head rather than reading it from the system.
How Map My Maintenance is built for multi-site from the ground up
The architecture treats each site as a fully independent workspace — not a folder within a shared list, but a complete environment with its own floor plan, team assignments, notification configuration, Work List, Project List, and Special Purchases, and its own data fully isolated from every other site. An account can manage up to ten sites, each created with a name, a set of team members drawn from the account's users, and its own notification preferences — frequency (12-hourly, daily, weekly, or none) and categories. A member assigned to sites one and two is notified only for those; a contractor given Guest access to site three sees only site three.
Switching between sites takes a single tap from the dropdown at the top of the app, and each site loads its own complete data set. Each site has its own Area Setup — the residential block plan, the vessel GA, the factory layout — mapped independently, so a job on site four is pinned to site four's plan with no relationship to any other site's structure. For the cross-site picture, the Dashboard and Timeline and Follow-Up view are available per site: the workflow is to check each site in sequence, which takes seconds once the habit is established. For professionals who manage maintenance across organisations, the multi-tenant architecture extends the isolation to the account level — a single login, fully independent workspaces, no data visible across tenants.
Cross-contamination is a liability
In a client-facing operation, data from site four appearing in the view for site two is not an inconvenience. Each site is fully isolated — its own plan, team, notifications, and records — and switching between them takes one tap.
What a ten-site operation looks like in practice
A property management company runs eight residential blocks, a commercial unit, and a holiday-let portfolio across nine active sites, with a tenth held for a new development. Each site has its own plan, its own team assignment (the in-house team across all nine, two external contractors only on the sites they service), and its own notification frequency — 12-hourly digests for the high-turnover holiday let, a weekly summary for the commercial unit.
Monday morning, the operations manager checks each site's Dashboard in sequence: site one has two Urgent items flagged with Reminders due today; site three has a Special Purchase showing a part delivered and ready to install; site six has nothing new. The check across all nine sites takes under ten minutes with no messages sent. Bringing on a new electrical contractor for three sites takes the Admin under five minutes — a Guest User assigned to those three sites only, invited by a branded Join Workspace email. When a site owner asks for a quarterly report, the manager filters that site's Work List and Project List and generates a Full Report as PDF, sent directly from the app, with no manual compilation.
The principle multi-site operations get wrong
The goal of a multi-site system is not total visibility of everything at once. It is to see any single site clearly, on demand, without carrying context from the others.
Total visibility sounds right, but in practice it produces the noise problem: a manager who sees 200 open items across ten sites simultaneously is more overwhelmed, more likely to miss what matters, and more likely to act on the loudest signal rather than the most important one. The right architecture is not a shared view with better filters. It is isolated sites with a fast, frictionless way to move between them. Each site should feel like the only site when you are in it, the switch should take one tap, and the data from site four should never appear in the view for site two.