From one branch to several: standardizing procedures without killing local flexibility
The previous lesson ended with a handover file that makes a role independent of any one person. The next test arrives when the business grows: a second branch, a second team, or a new manager for an existing department. A procedure that ran smoothly in one place suddenly forks into two versions, then three.
The drift is rarely deliberate. The new branch faces different conditions: different customers, different pressure, an employee who knows a faster route. A step is adjusted here and another there, and six months later a purchase request needs two approvals in one branch and one in the other — and the two branches' reports cannot be compared at all.
Why drift costs more than it looks
- Comparison collapses: when a step is defined differently, the two numbers cannot be compared.
- People stop being mobile: moving an employee between branches means retraining from scratch.
- The same fault recurs in new shapes: you fix a problem in one branch and it reappears differently in another.
- Automation stalls: any system you introduce needs one rule; five versions of a procedure mean five exceptions in the configuration.
The fixed-and-local rule
Total uniformity is not a goal in itself, and a branch forbidden from adapting anything loses its local advantage. Separate clearly what must be identical from what stays local, and write the reason beside each decision:
| Type of decision | Rule | Why |
|---|---|---|
| Approval limits and who releases money | Must be unified | Different limits across branches open a control gap |
| Regulatory duties: invoicing, document retention | Must be unified | The requirement applies to the whole entity, not to one branch |
| Data names, fields and the definition of each metric | Must be unified | Without one definition there is no valid comparison |
| Timing of execution and task allocation inside a branch | Left to the branch | Volume and peak hours differ from place to place |
| How the local customer is engaged | Local, within a written minimum | Market proximity is an advantage, but the promise to the customer stays one |
A concrete example: two branches and a misleading number
A maintenance business runs two branches. The dashboard says average response time is four hours in the first branch and nine in the second. The quick decision is to hold the second branch's manager to account. A review showed something else: the first branch starts the clock when the job is assigned to a technician, the second when the customer's call is received. The bigger difference was in the definition, not the performance.
Once the definition was unified on the moment the call is received, the numbers became seven and nine. A real gap remains, but a far smaller one, and now workable because both sides mean the same thing. Before you compare two branches, make sure they measure the same step from the same starting point.
How to roll out a unified procedure without resistance
- Start from reality, not from paper: take the best-performing branch's version as your draft — it is already tested and workable.
- Collect the differences and ask why: each is either a genuine local condition worth keeping, or a habit with no reason behind it.
- Write the reason beside every unified item: a rule whose purpose is understood gets followed; a rule imposed without explanation gets worked around.
- Open a declared route for exceptions: a written request from the branch, a specific approval, and an end date that triggers review. A managed exception prevents a secret one.
- Review after ninety days: what was not applied, and is the reason refusal or a rule that genuinely does not fit reality?
Catching drift early
Do not wait for the annual report. Pick one shared metric measured in every branch with the same definition, and put the numbers side by side each month. When two diverge sharply, examine the definition and the recording before blaming performance. A quarterly exchange visit between branch supervisors surfaces differences faster than any report.
Checklist
- Do you have a written list of what must be unified and what is left to the branch?
- Does every metric have one definition, including its start and end points?
- Do you know which branch runs a different version of a procedure touching money or authority?
- Do exceptions have a declared route with an end date, or do they happen quietly?
- Do you compare branch numbers monthly, or discover the gap late?
In short: branches drift step by step, without bad intent. Separate what must be unified — money, authority, regulatory duties and data definitions — from what stays local, and write the reason beside every unified item. Build the standard version from your best branch, not from paper, and give exceptions a declared route with an end date. Before comparing two branches, confirm the metric is defined the same way in both: many alarming gaps live in how things are counted, not in performance.