regional.fit
Local demand management for distributed organisations
- 4
- Decision Roles
- 1
- Shared Dataset
- Demo
- Prototype in Development
regional.fit is our own product, a prototype in development: a system for local demand in organisations with many sites, such as fitness chains, retail networks, restaurant groups and hotels. A local manager submits a structured request, the system checks it against the brand strategy, a regional manager decides, and the board sees the trends across regions. One dataset underneath, a view per role on top. Fitness chains are the first vertical.
From request to decision in four steps
The problem
In a chain with dozens of sites, local requests arrive by email, chat and phone: a poster for an opening, a local campaign, a training material, an exception to the brand rules. Regional managers cannot tell what matters from noise, production gets requests without context, and nobody sees where anything stands. The cost lands in management time, late openings and a local brand that drifts. What is missing is one structured layer between the sites and the head office.
What we took responsibility for
Everything, because the product is ours: the problem framing, the roles and where each decision sits, the product design, the working prototype and the plan for the next stage.
Capabilities at work
- Strategy & Design
- Four roles drawn around real decision boundaries: the local manager asks, the regional manager decides, the administrator sets the rules, production delivers.
- Digital products
- A working prototype with a demo mode: pick a role and see the system from that level, on a desktop and on a phone.
- AI elevation
- Every request is checked against the brand strategy before a person sees it: a fit score, red flags and suggestions. The decision stays with the regional manager.
Decisions
The method came from club openings for Zdrofit, where the same request chaos returned at every launch. We treated it as a product problem rather than a consulting one, because every multi-site organisation has the same shape. Four roles, each owning one move in the flow, with no overlap. The production role is designed but left out of the current prototype: the decision layer comes first, execution second.
How we delivered
Each role sees only what it needs to decide. The local manager fills a short form with the site's context already loaded, not a blank email. The system returns a fit score with flags. The regional manager gets a queue sorted by urgency, with approve or return in one click. The administrator defines sites, hierarchies and rules. The board sees consistency and gaps across regions. The structure fits any multi-site organisation, not only fitness.
The work
One system, a view per role
A request with its context
Roles and access, and the same flow on a phone
"We stopped consulting around the demand problem and started building the product for it.
Outcome
A working prototype with a demo mode: three roles in scope today, the production role designed for the next stage, fitness chains as the first vertical. It runs on sample data only. Deployments, request volumes and time saved will be published once they have been measured on a real network, not before.
Reflection
When several clients describe the same chaos in the same words, you are no longer delivering a service, you are documenting a market. regional.fit exists because the gap between local need and central execution looked the same every time we met it.
Before we rolled out the system, most of my week went into answering 'where are we on the opening' emails. Now there's one screen every level sees - from my team to the director. We swapped five-person status meetings for a screen link. The time I got back goes into real decisions, not writing reports.
Joanna LachSenior Specialist, Marketing of New Openings · Zdrofit (pilot deployment)
