One brand, forty branches, and an inbox that has to know which

Multi-location businesses have an email problem that single-site businesses do not: the customer writes to the brand, and the answer lives at a branch. Somebody at head office reads it, works out which site, forwards it, and hopes.

6 August 2026 · 4 min read

That forwarding step is where the delay and most of the dropped threads live.

Work out the location first#

Routing is the whole design, and it is a classification problem with unusually good signals available.

The customer says so. Most messages name a town, a branch, or an address. Extract it and match against your site list.

The context says so. A booking reference, an order, or an account already maps to a location in your systems. Look it up rather than reading it out of the prose.

The address they wrote to says so. If you publish per-branch addresses, routing is solved before it starts, which is the strongest argument for doing it.

Nothing says so. Then ask, in one short message, rather than guessing. A wrong branch guess produces a confidently wrong answer about opening hours or stock, which is worse than a clarifying question.

One agent or one per site#

The question everyone asks. The honest answer depends on how much genuinely differs between locations.

One agent, location as a parameter. Correct when branches differ only in facts your systems already hold: hours, address, stock, staff. The agent looks up the location and answers from data. Simplest, and it stays consistent as sites are added.

An agent per site. Correct when branches are genuinely separate businesses, as in franchises with their own owners, their own policies, and their own liability. Each gets its own identity and key, so a franchisee's correspondence is theirs, per giving every customer their own agent inbox.

For franchises the isolation is not a nicety: one franchisee should not be able to read another's customer correspondence, and the head-office agent should not be answering on behalf of a business it does not run.

Who owns the reply#

Decide this before launch, because ambiguity here produces double replies and dropped threads.

The pattern that works: the agent answers anything factual from central data regardless of location, and hands over to the branch only when the answer requires local knowledge or a local action. That keeps the common case fast and puts the branch in the loop only when it must be.

The handover is a forward with the thread intact, so the branch has the whole conversation and the customer's next reply lands with whoever now owns it, per when an agent and a person are on the same thread.

Consistency is the point, and the risk#

The upside is real: every location answers in minutes, in the same voice, with the same facts, which is precisely what a multi-site brand struggles to achieve manually.

The risk is the mirror image. One wrong central fact is now wrong everywhere at once, and a prompt change affects forty sites simultaneously. That makes the golden thread suite more valuable than usual, and it makes staged rollout worth the effort: change one region first, read the threads, then widen, per evaluating an email agent.

The data has to be right#

An agent answering location questions is only as good as your site records, and most multi-location businesses have a table somewhere that is quietly wrong: a branch that moved, holiday hours nobody updated, a phone number redirected years ago.

Deploying an agent surfaces that immediately and publicly, because it will confidently tell customers the old hours. Treat the first week's corrections as a data cleanup exercise rather than an agent problem, and fix the source rather than the prompt, per making an agent answer only what it can prove.

Questions#

How does an agent know which branch a customer means?

From what they wrote, from a booking or order that maps to a location, or from the address they wrote to. When nothing identifies it, ask rather than guess.

Should each location have its own agent?

For franchises with separate ownership, yes, with isolated identities. For company-owned sites that differ only in facts your systems hold, one agent with location as a parameter is simpler and stays consistent.

Who answers, head office or the branch?

The agent answers anything factual from central data, and hands to the branch when local knowledge or a local action is needed, forwarding the whole thread.

What is the main risk of centralising?

One wrong fact is wrong everywhere at once, and a prompt change hits every site simultaneously. Stage rollouts by region and keep a golden thread suite.

What usually goes wrong in week one?

Your location data. Branches that moved, stale holiday hours, old phone numbers. The agent surfaces it publicly, and the fix is the data rather than the prompt.

How do franchisees keep their correspondence private?

Separate identities with no cross grants, so one franchisee cannot read another's customer threads and head office is not answering for a business it does not run.