The digital operations of a nationwide, multi-location network always pull in two directions. Headquarters wants a consistent brand, consistent content and predictable operations. Each location, on the other hand, has its own opening hours, its own capacity, its own local offers and its own people. A good system doesn't choose one over the other; it serves both.
For more than five years we've been working with a nationwide network of several dozen locations, from concept and design through development and operations to day-to-day support. Website, mobile app, booking system, careers site, campaigns, newsletter, digital displays in the stores. We won't list them all, because the number isn't the point. What matters is that these are interconnected systems, managed by a single team.
Central rules, local settings
The same pattern comes up in almost every system.
The digital displays in the stores show centrally managed content, but every location has its own settings and local banners. Prices and product data arrive live from the central business system, a promotion that has sold out disappears from the screens by itself, and multi-screen setups switch in sync. The displays have to keep working even when the connection drops, so they also run offline, and central monitoring flags it when something goes wrong somewhere.
The booking system gives customers a consistent, step-by-step interface, while capacity and time slots can be set per location. The locations approve bookings, message customers and track statistics in their own admin interface.
On the careers site, more than two hundred open positions can be searched at once, and store managers get their own subpages within a shared system. During development we coordinated directly with the locations, because they knew what they needed.
Location data, such as opening hours and service time slots, lives in the internal systems and on Google at the same time. Keeping it up to date isn't a glamorous task, but for visitors it's one of the most important pieces of information.
Connected, but isolated
When this many systems have to work together, it's tempting to connect everything to everything and build one giant monolith. Instead, we only share what really needs to be shared: the website and the mobile app work from a shared CMS and API, campaigns are built on the same modular platform, and internal interfaces are accessed with corporate sign-in. This means a consistent experience and less duplicated work.
At the same time, it's just as important that the systems are properly isolated from each other. That way each system can be developed, released and operated on its own, so introducing a new feature or updating a component has no effect on the other components. The systems connect through well-defined interfaces, and each one has access to exactly as much data as its job requires.
In the digital operations of a large organization, the focus is often not on one flagship system, but on making sure the various systems, services and workflows connect reliably.
This is also the basis of meeting the security requirements. The client's international IT requirements framework sets strict audit, infrastructure and documentation standards, and every system has to meet them. These include containerized infrastructure, automated test pipelines and deployment, automatic anonymization of data, consent-based cookie management, and accessible interfaces that can also be used with a keyboard.
Change is a natural part of a long partnership
Over a decade, we can't expect systems to stay the same. Whether it's a complete redevelopment or replacing a single software component, an application that has been in service for years has to be replaced in a way that migrates the existing user and transaction data without customers noticing any interruption. Transitions like these are part of long-term operations: the job is to identify the need in time, make the switch plannable, and not let an unexpected outage force it.
The same goes for smaller changes: new content or a new feature first goes to a staging environment, where it can be previewed, checked and approved, and only then goes live. That way no change reaches the locations or the customers unchecked.
And of course the goal is for everyday support to be continuous as well: support, availability, managing the locations' support accounts, and quickly launching a new campaign from the existing modules.
If you work with a similar system
With multiple locations, the question comes up quickly: what's worth managing centrally, and what should be left to the locations? In a well-built system this isn't a compromise but a deliberately designed way of working: shared things can be managed centrally, while local settings can be changed where they're actually needed.
If you're facing a similar challenge, we'll help you find and build the right architecture.