# A business with several locations

One business with five branches is one workspace with five lines and as many mailboxes. Each line carries its own number, hours, routing and voice; each mailbox its own role and signature. The relationship stays whole underneath: a customer who rings one branch and emails another is one Person with several identities, and the second conversation knows about the first.

- **Status:** Available
- **Audience:** both
- **Channels:** phone, email, whatsapp
- **In the app:** #/calls, #/mailboxes, #/memory
- **Last verified:** 2026-09-10
- **Canonical:** https://connectbyjbrh.com/docs/use-cases/multi-location/

## A branch is a line and a mailbox, not a new tenant

A phone line is a row in `channel_routes` — the same table that answers 'whose endpoint is this and what is it for' for every channel. On it sit the provider, the assignment, inbound and outbound permission, the hours, the routing, the recording policy, the capabilities and the limits. Adding a branch adds a row, not a schema.

- **Hours per branch.** A line that is closed answers with the closed-line message rather than improvising an opening time from a prompt.
- **A voice per branch**, if you want one. The voice is configured per line, so a city site and a rural one need not sound identical.
- **A mailbox per branch**, each with a role, a signature, its own autonomy setting and its own health verdicts.
- **Routing per line**, so an enquiry that should reach a particular person does, and the rest is answered.

## Branch facts that stay in the branch

This is the mechanism that makes the shape work, and it is easy to miss. Memory resolves at four tiers, narrowest first: workspace, channel, endpoint, contact. An **endpoint** is one mailbox or one phone number. Facts true of the Leeds site — the entrance round the back, the parking, the manager's name — belong at the endpoint tier and apply only to work arriving there.

| Fact | Tier | Why |
|---|---|---|
| Company-wide returns policy | Workspace | True everywhere; writing it five times invites five versions |
| How calls are handled generally | Channel | A property of the channel, not of a site |
| This branch's address, parking, manager | Endpoint | Applies to the line or mailbox for that site alone |
| This customer prefers the Bristol branch | Contact | Follows the person, not the site |

> **Note** An empty tier is returned rather than dropped, so 'nothing is set for this branch' is a visible answer rather than an absence you have to infer.

## One customer, several branches

A Person is the canonical human and an Identity is one address on one channel; a person may hold many. Somebody who rang the Leeds number in March and emailed the Bristol mailbox in June is one relationship with two identities, so Customer 360 and the timeline show both. That is the behaviour customers assume every business already has and almost none does.

Where two records do exist for one human — a common outcome when branches were previously separate systems — duplicates are proposed rather than merged. `merge_people` is a human decision and preserves identities, stages, follow-ups, deals, demos, cases and onboarding from both sides.

## What is shared whether you want it or not

**The daily allowance** — It belongs to the workspace, not to a branch. One site having an exceptional week consumes capacity the others would have used, and there is no per-branch quota to protect them.
**Worker capacity** — The fleet is shared. `ring` refuses `not_ready` when every live worker is over a load of 0.85 per core, and that gate does not know which branch a call was for.
**The relationship graph** — Deliberately. Every person with workspace access can see every branch's customers — that is the point of one workspace, and it is the reason a franchise network usually needs a different answer.
**Knowledge** — Sources are a workspace's, so a document loaded for one branch grounds answers for all of them. Branch-specific detail belongs in endpoint memory instead.

> **Careful** There is no completed human transfer on the live carrier, so a caller cannot be handed from the central line to a named person at a branch mid-call. An escalation phrase queues a transfer and a supervisor can act on a live call; the reliable pattern is a call-back follow-up carrying the branch and the reason.

## Where the money goes

Per line, in voice, and it concentrates wherever your busiest number is. Audio tokens run at four times the model's text input rate and roughly 2.7× on output, and a session is re-billed for its whole context every turn. The per-call profiler reports what was measured and says what was not rather than estimating it, which is the tool for finding out that one site's calls run twice as long as the rest — usually because its Knowledge is thinner and the conversation has to work harder.

## Questions

### Should each branch have its own workspace?

Only if they are genuinely separate businesses. A workspace is the isolation root and records never cross one, so separate workspaces mean a customer known to two branches is two unrelated records with no shared history. For one company with several sites, one workspace with a line and a mailbox each is the shape that keeps the relationship whole.

### Can one branch's answers be different from another's?

Yes, through endpoint memory and the mailbox's own role, signature and autonomy. Facts written at the endpoint tier apply only to work arriving on that line or mailbox, so branch detail does not leak into another site's replies while company-wide policy stays written once.

### Can we stop one branch seeing another's customers?

Not within one workspace — isolation is per workspace, not per branch, and every member with access sees the workspace's records. If that separation is a requirement rather than a preference, separate workspaces are the honest answer, with the loss of the shared relationship record that implies.

## Related

- [A franchise network](https://connectbyjbrh.com/docs/use-cases/franchise/)
- [Configuring a phone line](https://connectbyjbrh.com/docs/phone/line-configuration/)
- [Channel and endpoint memory](https://connectbyjbrh.com/docs/memory/channel-context/)
- [One person across phone, email and WhatsApp](https://connectbyjbrh.com/docs/relationships/cross-channel-identity/)
- [Add a second phone number](https://connectbyjbrh.com/docs/how-to/connect-a-second-number/)
- [Mailbox roles](https://connectbyjbrh.com/docs/email/mailbox-roles/)

## What this page is based on

- docs-source/sources/PHONE.md §1 and §5 — channel_routes and capacity
- docs-source/sources/GENERAL.md §6 — the four memory tiers
- docs-source/sources/CHANNELS.md §1 and §5 — mailboxes, people and merging
- Connect capability registry (docs-source/facts.py)