If you run several locations, you do not have a sales process. You have one per location, and every manager believes theirs is the right one.
They are all partly right. That is why mandates from head office get quietly abandoned.
Split the process in two
Identical everywhere:
- Stage definitions, and what has to be true to leave each stage
- Field meanings, so the same word means the same thing in every location
- Timing rules: how fast a first contact happens, when a second touch fires, when a lead is considered cold
- What must be written on a record before it moves
These are the things reporting depends on. When they differ, your company number is the sum of several different definitions and describes none of them.
Local, by configuration:
- The calling window, in local hours
- The owner and the transfer destination
- The local offer and any pricing that varies
- Language
These are the things a manager knows better than head office. Standardising them is what makes a rollout feel wrong to the people who have to live with it.
The test before you scale
Write down what changes between location one and location two.
If everything on the list is a value, you can standardise: one process, one configuration per location. If anything on it is logic, fix that first, because you are about to build thirty systems that drift apart and a fix applied once will silently not apply everywhere.
What a location configuration should contain
One record per location, holding: the calling window, the owner, the transfer destination, the local offer variables, the number or inbox, and the status of anything that gates launch such as compliance registration.
Adding a location becomes filling in that record. That single change is the difference between a rollout that reaches thirty and one that stalls at four.
Reporting is half the adoption problem
A company wide average is a number nobody owns. A branch manager cannot act on a figure that includes twenty seven other branches, so they ignore it and keep running their own version.
Give each location their own numbers, next to what was expected for that location. The conversation changes from head office explaining the process to a manager asking why their neighbour converts better, which is a question with an answer.
Handling the location that is genuinely different
Make the difference a configuration value. When a location needs different logic rather than different settings, you have found one of two things: something that belongs in the shared process because others will need it too, or something that should not exist.
Both are useful discoveries. Neither justifies a separate build.
Where to start
Do not begin with all of them. Take two locations that differ from each other, run the shared process with two configurations, and see what breaks. Two is the smallest number that proves the model. One proves nothing about standardisation at all.