Both sites think they do it the standard way
Multi-site businesses almost always discover, during discovery, that the process differs between locations in ways nobody had documented. Different sequencing, different exceptions, different informal rules.
Some of those differences are real: a different customer mix, a different physical layout, a different regulatory position. Most are historical accident.
Separate constraint from habit
- List every difference between the sites, without judgement
- For each, ask what would break if it were done the other way
- Where nothing would break, it is habit — standardise it
- Where something would, it is a constraint — make it configurable
- Where nobody knows, run the other way for a fortnight and find out
The question that settles most of these: what would break if you did it the way the other site does? “Nothing, we have just always done it this way” is the most common answer.
Configurable per site, not branched code
Genuine differences go into per-site configuration: which steps apply, which thresholds, which routing. Never into conditional code, because that is how you end up maintaining two products.
The rule we apply: if it cannot be expressed as configuration, it needs a commercial justification, because the maintenance cost lands on every future change.
Roll out one site first
Pilot at the site with the most cooperative team, not the largest. Fix what they report, then take a working system to the second site with evidence rather than promises.
Second-site adoption is considerably easier when someone at the first site can be asked what it is actually like.
Watch for the site that quietly opts out
- Data entered in batches at the end of the day
- A shared login rather than individual accounts
- A parallel spreadsheet “just for our team”
Each is information rather than misbehaviour. Ask what the spreadsheet does that the system does not, and you usually get a short, fixable list.