Nine branches give nine answers because nobody built the place the answer lives

A composite scene, told once

This is a composite. It is not one client, it is the shape of the same call we have heard described by operators in retail, automotive, clinics and service groups, and the details are interchangeable.

A customer wants to return something bought at one branch to another branch closer to home. She phones the nearest one first, because that is what people do.

• Branch one says yes, any branch, bring the receipt. The person answering has done it before and it was fine.
• Branch two says no, it has to go back to the branch that sold it, because that is how the till reconciles and the manager was firm about it last year.
• Branch three says probably, but ring the original branch to check, and gives her a number that goes to voicemail at lunch.
• The website says nothing at all about it, and the chat widget offers to take her details.

Why it happens

The scene above is not a people problem, and it is worth being precise about that, because the people fix is the one everyone reaches for and it is the one that wears off.

Three things produce it, and they are present in almost every group we have looked at.

• Each branch invented its own workaround. When a question came up and nobody central answered it fast enough, the branch decided. A laminated sheet by the till, a pinned message in the staff chat, a rule the manager states out loud. Each is sensible, each is undocumented, and each is now the branch's answer.
• The answer lives in a manager's head. The person who knows the policy is the person who is busiest, on leave, or on the other site today. Staff answer from memory of what she said, or guess and hope.
• Head office wrote a policy PDF that nobody opens at the counter. It exists, it is correct, it was emailed in January, and it is fourteen pages. At the moment the customer is standing there, nobody is going to search for it.

It is a systems problem, and the fix has four parts

Nine branches giving nine answers is what happens when there is no system, and the honest description of the fix is that you build one. It has four parts. They are simple to state and each of them is real work.

1. One source of truth for the answers. A knowledge base: the written answers, in one place, owned by one named person, that every channel at every branch draws on. Update it once and every site is correct from that moment.
2. One intake path for the leads. An enquiry that arrives centrally reaches the right branch, once, with its context, in seconds. The whole shape of that is on the multi location page; the point here is that it is part of the same fix, not a separate project.
3. One definition of what an enquiry is. A system of record for enquiries, so that when branch two says it had forty and branch five says it had twelve, the numbers were counted the same way and the comparison is honest.
4. A Monday view. Something a regional manager looks at on Monday morning that shows which branch drifted last week, a month before the quarterly pack would have said so.

What one answer actually means, and where each answer should live

People hear one answer and picture a script. That is not it, and a script is roughly what the policy PDF already was.

One answer means the same substance reaches the customer whichever way she asks, and the parts that are genuinely local are filled in from data rather than from whoever happens to be on.

• The same answer by every channel. Phone, text, Instagram DM, web chat, email, and the person at the counter all draw on the same written source. The customer who phones and the customer who messages get the same policy in different words, not different policies.
• The same answer in French and in English. Not a translation done once and left to drift. Both versions maintained in the same place, changed together, so a French caller and an English caller are told the same thing on the same day.
• The branch-specific parts filled from data. Today's hours, this branch's address, who is on the floor this afternoon, whether the item is on the shelf here. Those come from the hours table, the roster, the stock system, not from memory. The policy is identical everywhere; the local facts are local and current.
• An honest not-yet. When the source has no answer, the system says so and routes the question to the person who can answer it, and that question goes on the list to be written up. It does not improvise, and neither should the counter.

Building the single answer set in a week, without a project

The answer set is the document, the written answers themselves. Getting it wired behind every channel at every site is the build, and that takes longer. The document, though, can exist by Friday, and it is the part groups put off for years because it looks like a big project.

It is not, if you start from the questions your sites already get asked rather than from a blank page.

1. Monday: get the list from your own sites. The FAQ extractor reads a page and returns the thirty questions buyers ask before getting in touch, flagging the ones the page never answers. Run it on two or three of your branch pages. Where the outputs differ, that difference is your list: it is the questions where your own site is already giving different answers, or none.
2. Tuesday: sit with two branch managers, not nine. Pick the branch that gets the most complaints and the branch that gets the fewest. Go through the list. Every question where their answers differ goes on the drift list. Twenty minutes each, and you will fill the sheet.
3. Wednesday: decide, once, per question. For each item, is it identical everywhere or genuinely local? If identical, write the one answer, in both languages, and note who owns it. If local, name the table it comes from. Do not write local facts into the answers.
4. Thursday: get the honest not-yet list. The questions nobody could answer confidently go in a separate section, with a name against each. That section is where the next month of decisions lives, and it is more useful than the answers you already had.
5. Friday: put it where the counter can reach it. Not a PDF in a shared drive. A single page, searchable, that a phone can open in one tap. The system that answers the phone and the chat gets pointed at it next; the counter can use it today.

Central leads and the one intake path

The second half of the consistency problem is not about answers. It is about the enquiry that arrives at the brand rather than at a branch.

Head office runs a campaign. The form on the group site fills. The enquiry lands in a shared inbox, or in the marketing manager's personal one, and from there it has to reach the branch that will do the work. This is where groups quietly lose the leads they paid the most for, and it goes one of four ways.

• The lead reaches the right branch a day later, after somebody read the inbox and forwarded it. By then the customer has spoken to a competitor who answered on the day.
• Two branches work it at once, because it was forwarded to a regional group and both keen managers picked it up. The customer gets two calls and one confused impression.
• Nobody works it, because it was forwarded to a branch that thought it was FYI.
• Nobody knows which of those three happened, because each branch counts an enquiry differently, or not at all, and the campaign gets judged on form fills rather than on conversations that happened.

1. Captured once, at the moment it arrives, on the shared definition, so the number head office reports and the number the branch reports are the same number.
2. Matched to a branch by area, service and availability, using the same location table and service areas the answers already use.
3. Delivered with its context attached, not as a name and a blank, so the branch's first reply can be a real one.
4. Reassigned automatically if it sits unclaimed past an agreed window, and the fact that it sat is recorded, because that is the number nobody currently sees.

Measuring drift on a Monday, not in the quarterly pack

Consistency decays. A new manager arrives, a policy changes, a branch gets busy and starts improvising, and three months later the group has drifted back to several answers without anyone deciding to. The quarterly pack will show it eventually, by which time it is a habit.

The alternative is a short weekly look, per branch, on the shared definitions. Thirty minutes on a Monday. The fuller method is in the weekly review guide; the group-specific version watches for four things inward and one outward.

• Enquiries in, and the median time to first real response, per branch, counted the same way everywhere. A branch whose median moved this week is a conversation this week.
• The not-yet log. Every question the system or the counter could not answer from the source, grouped by branch. If one branch is generating most of them, either it is being asked something the others are not, or it has stopped using the source. Both are worth knowing on Monday.
• Corrections. How many times a branch's answer was overridden or contradicted by another branch or by head office. This is the direct measure of drift and it is almost never tracked.
• Reviews mentioning the other branch. A review that says the other branch told me something different is the customer doing your consistency audit for you, and it should reach a person that week.
• What changed across the road. Competitor watch is a free tool that emails one weekly digest of what changed on up to three competitor pages. For a group it earns its place for one reason: head office watches the same competitor once, rather than nine branches each guessing what the shop across the road did this month.

What a new branch inherits on day one, and what none of this fixes

The moment all of this pays back most visibly is when you open the next site.

Without it, the new branch starts with an empty head. Every answer, every rule, every routing decision gets rebuilt in person, slowly, by whoever head office can spare, and everyone calls the resulting six months a ramp. With it, the new branch inherits the group on the morning it opens. Four things arrive with it, and then, because a post arguing one side is not much use, three things it does not fix.

• The answer set, complete and current, in both languages, with the local facts already pointed at its own hours, address and stock.
• The intake path, so central leads reach it from the first campaign, matched to its service area, and counted on the same definition as everyone else.
• The Monday view, so its first weeks are compared against something real, and drift is caught in week two rather than month four.
• A far shorter first fortnight for the staff, because the answers exist before they arrive. The people side of that is in the new hire guide, and it is mostly the same document doing a second job.

1. A knowledge base does not fix a branch that is understaffed. If the phone rings and nobody is there, the quality of the answer nobody gave is irrelevant. Consistency helps a branch that has hands. It does not replace them.
2. Consistency is not centralised control. The things that get standardised are the ones where variation is a defect: policy, what customers are told, how things are counted. Local judgement about a customer, a market or a team is not on that list, and a system that tries to standardise those will be rejected by the branches, correctly.
3. The branch still owns the relationship. The customer in the composite scene did not want a policy. She wanted the person she was talking to be able to help her, confidently, and to be right. One answer gives the branch that confidence. It does not, and should not, take the conversation away from the branch.

Where this connects

The full shape of the group build, including the parts this post does not cover, is on the multi location page. The trade underneath is still the trade: retail groups and dealer and service networks each have their own version of the same nine questions.

For the weekly habit, the weekly review is the thirty minute version. For what the same document does for a new starter, new hire in three days. To get the list of questions this afternoon, run the FAQ extractor on two of your branch pages and compare. And if the term itself is new, the glossary entry on knowledge bases is the short definition of what you are building.