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.
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 |
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.
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.