# A franchise network

A franchise network is separate businesses, so it is separate workspaces — one per franchisee, each with its own plan, mailboxes, numbers, Knowledge and records. Isolation is enforced three times over and there is no mechanism to read across it, which means there is no network-wide view of customers and no franchisor console. That constraint is the design, not a missing feature.

- **Status:** Available
- **Audience:** both
- **Channels:** email, phone, whatsapp
- **In the app:** #/account, #/knowledge, #/billing
- **Last verified:** 2026-09-10
- **Canonical:** https://connectbyjbrh.com/docs/use-cases/franchise/

## Why the isolation is absolute

`workspaces` is the root of the data model. Nearly every table carries a `workspace_id` and is filtered automatically, and the filtering happens three times independently: an allowlist in the middleware, a workspace kernel over the ORM, and row-level security in PostgreSQL, forced on every scoped table. A query written by mistake to read another workspace's rows returns nothing at the database, not just at the API.

That is what a franchisee is buying when they run their own workspace, and it is worth being blunt about the consequence: **there is no supported way for a franchisor to see inside one.** No cross-workspace reporting capability exists in the registry, and building one would be building past the isolation rather than on top of it.

> **Note** A franchisor running Connect is a customer like any other. The two operator-only surfaces — verifying payments and the platform's own pricing — belong to JBRH as the operator of the platform, and they are not a network-management console for anybody else.

## What a network can genuinely standardise

| Thing | Shared how | Caveat |
|---|---|---|
| Brand answers and policies | The same Knowledge documents loaded into each workspace | You distribute the document; there is no push mechanism |
| Tone and standing instructions | Written the same way in each workspace | Set per workspace; nothing propagates automatically |
| Voice and speaking style | Configured per line, per workspace | Each franchisee's line is theirs |
| What Connect may do | The same autonomy modes chosen in each | A franchisee can change their own; you cannot enforce it remotely |
| Customer records | Not shared | Isolation. A customer of two franchisees is two unrelated records |
| Reporting | Not shared | Each franchisee sees their own usage; there is no roll-up |

The practical shape most networks land on is a written standard plus a starter set of Knowledge documents, applied by each franchisee in their own workspace. It is not automatic, and pretending otherwise would be the overclaim this documentation is built to avoid.

## The lead-routing question

Networks usually ask whether a central enquiry can be routed to the right franchisee. Within Connect the honest answer is that a message belongs to the workspace whose mailbox or number received it, and it does not move across workspaces. A central line can answer, qualify and record; passing the enquiry onward is an act outside the isolation boundary — an email your central workspace sends to the franchisee, which then arrives in their workspace as ordinary inbound mail.

- That transfer is a real message with a real send record, which is arguably better than a silent internal hand-off nobody can audit.
- The customer exists twice — once as a contact of the central workspace, once of the franchisee's. Neither record knows about the other.
- A completed human transfer of a live call is not available on the live carrier, so a central phone line cannot warm-transfer a caller to a branch. A call-back follow-up is the workable pattern.
- Outbound SMS does not run on the live carrier at all, and in India would need DLT registration with the operators before any of it.

## What each franchisee owns

**Their plan and allowance** — Bounded per workspace. One busy franchisee cannot consume another's capacity, which is the flip side of not being able to share anything.
**Their mailboxes and numbers** — Connected with their own credentials, sealed on save and never echoed back to a screen. Nobody is handed a stored secret, including the franchisor.
**Their memory and Knowledge** — Theirs to read, correct and erase at every tier. A network standard is a document you gave them, not a control you retain.
**Their decision log** — What was decided, by what, under which rule, and what happened — including refusals. It answers questions about their workspace and only theirs.
**Their commercial refusals** — `safe_sales` refuses terms Knowledge does not support in each workspace independently. A network price only exists where each franchisee has written it down.

## Where the money goes

Per workspace, which is what makes the model workable for a network: each franchisee's usage is metered against their own plan, and the daily ledger is theirs. The dominant cost in each is voice — audio tokens at four times the text input rate, a session re-billed for its whole context every turn, and a duration charge even where no tokens are reported — so the variation across a network follows call volume rather than anything structural.

## Questions

### Can head office see how each franchisee's Connect is performing?

No. There is no cross-workspace reporting capability, and isolation is enforced in the middleware, the ORM kernel and the database. A franchisee can share what they choose to share — an export, a figure they report — but nothing is readable from outside their workspace by design.

### Can we push a brand-approved answer to every franchisee at once?

Not automatically. Knowledge belongs to a workspace, so a network standard is distributed as a document each franchisee loads into their own. That is slower than a broadcast and it is the only shape consistent with each of them owning their own data.

### Can a central enquiry line pass a caller to the right franchisee?

It can answer, qualify, record the enquiry and send it onward as a real message to that franchisee's mailbox, where it arrives as ordinary inbound mail. It cannot transfer a live call — completed human transfer is not available on the live carrier — and the customer will exist as a separate record in each workspace.

## Related

- [A business with several locations](https://connectbyjbrh.com/docs/use-cases/multi-location/)
- [Multi-tenancy in Connect](https://connectbyjbrh.com/docs/security/multi-tenancy/)
- [Row-level security](https://connectbyjbrh.com/docs/security/rls/)
- [An agency with several clients](https://connectbyjbrh.com/docs/use-cases/agency-multiple-clients/)
- [The operator's workspace and a customer's](https://connectbyjbrh.com/docs/account/owner-vs-tenant/)
- [Who decides what is true](https://connectbyjbrh.com/docs/knowledge/owner-authority/)

## What this page is based on

- docs-source/sources/GENERAL.md §1, §2 and §3 — isolation and the data model
- docs-source/sources/CHANNELS.md §6 — the two operator-only surfaces
- docs-source/sources/PHONE.md §12 — transfer and SMS on the live carrier
- Connect capability registry (docs-source/facts.py)