Franchise & Multi-Location CRM: Give Every Branch Its Own WhatsApp and Channels

Yes: a CRM for franchises and multi-location businesses—five clinics, a hotel chain, a network with twenty sites—can split phone numbers, WhatsApp and channels across every unit, so that each branch sees only its own customers and HQ sees everything from a single dashboard. You don't need to open a standalone account per location or reconcile spreadsheets at month-end. That's exactly what TotemAI's family-and-subteams structure solves, and it's the difference between "a tool for one business" and "a tool for a group of businesses."

The problem with running multiple locations on one tool

Most customer-service platforms assume there's a single business behind them: one number, one inbox, one team. That works beautifully for a single clinic or a lone real estate office. But the moment you grow to two locations, open a franchise, or run several brands, that model breaks.

The problem isn't technical—it's about boundaries. The Austin clinic's customer isn't the Dallas clinic's customer. A rep at one branch shouldn't see the leads next door. The franchisor wants to measure how each location is doing without asking for screenshots. And every branch wants its own number, its own WhatsApp and its own identity, even when the brand is shared.

When you try to solve that by dumping everything into one inbox, you get the usual mess: crossed leads, reps seeing what isn't theirs, and an HQ that's in the dark until it asks for the monthly spreadsheet. When you solve it by opening a separate account per location, you lose the group view and multiply your admin work by the number of sites.

Franchise CRM: one HQ, one subteam per branch

The family structure starts from a simple idea: there's an HQ (the "family") and, hanging off it, as many subteams as you have branches, sites, countries or brands. Each subteam is a full-fledged team inside TotemAI, with its own lead board, its own conversations and its own calendar. The difference is that they all sit under the same umbrella—just like a franchisor and its franchisees, or a head office and its regional branches.

The key is splitting channels by location. HQ creates the family once and, from there, assigns each subteam what belongs to it: its own phone number, its own WhatsApp channel, its Instagram, its Messenger, its SMS, its email and its web chat. The Dallas branch answers on the Dallas WhatsApp; Austin, on its own. Same dashboard, separate identities, one shared brand.

And underneath, the machinery is the same as always for each branch: the AI answers calls in ~1 second and messages right away, 24/7, and a human picks up the conversation in one click with full context. If you want to see how that shared inbox works from the inside, we cover it in detail in how to put your whole team on one WhatsApp number and in managing WhatsApp, Instagram, Messenger and calls in one place. The family doesn't change that experience for the branch—it replicates it, cleanly, in every subteam.

What HQ sees, and what each branch sees

Here's the detail that makes it usable. Each subteam sees only its own: its leads, its calls, its chats, its calendar. The rep at the Denver branch opens the app and sees their customers, not Miami's. That prevents the mess and, along the way, keeps each book of business separated the way it should be.

HQ, by contrast, has the group view. It can see the aggregated activity of every subteam and compare how each location is doing: lead volume, conversations, booked appointments and per-call sentiment analysis. It's the same real-time analytics we explain in inside the dashboard: response rate and live sentiment, but summed across the whole family. The franchisor stops asking for screenshots and starts comparing real numbers, branch by branch.

And because the apps are native on iOS and Android as well as the web, every member of every branch works from wherever they are without missing a single call. We cover it in how calls ring at once on web, iOS and Android.

Per-location permissions and consolidated billing, without the chaos

A group doesn't just split customers: it splits responsibility and money. The family structure separates the two and makes clear who manages what at each location and what each one uses, even though payment is centralized at HQ.

HQ decides the permissions. It can give each location manager control over their subteam (their members, their channels, their calendar) without opening the door to the rest of the family. A branch manager runs their own patch; a family admin runs the whole. No one sees more than they should.

Billing is centralized at HQ: a single payment for the whole family, without opening an account or an invoice per site. What does get broken out is usage—the dashboard categorizes by subteam what each branch spends: minutes, messages, templates—so you can see who's using what without reconciling spreadsheets, even though the invoice is one. And here's the reassuring part worth repeating: it's a fixed monthly plan, with a pool of included minutes and messages that usage draws down. That keeps the cost predictable month to month, and if usage spikes one month, you top it up with a one-time add-on. We go deeper in why your pricing is predictable.

In the table, column A is "one team for the whole group" and B is "family with subteams." The difference isn't a handful of features: it's order.

The compliance baseline is the same across the whole family, so the same guarantees apply in every subteam—there's no branch that's "less compliant" than another. Two nuances worth getting right. First, the notice that a customer is being served by an AI: if you take calls from or handle the data of EU residents, the EU AI Act requires you to disclose it to the user, unless it's already obvious (Regulation (EU) 2024/1689—the AI Act—art. 50.1); operating purely in the US, treat it as best practice and what the FTC and state law expect, not an EU mandate. Second, the option to escalate to a person, which we offer as good service—not because the GDPR imposes it across the board: the "right to human intervention" under GDPR art. 22.3 only arises with solely automated decisions that produce legal or similarly significant effects, and a booking or reception bot normally doesn't make that kind of decision. As for where the data lives, the GDPR does not require it to sit physically in the EU: it also allows processing outside the European Economic Area as long as valid transfer safeguards are in place (Regulation (EU) 2016/679—the GDPR—Ch. V, arts. 44–46). Totem hosts to the EU standard as a product choice, not because any law makes it—so the guarantee travels to every branch. This takes away the franchisor's risk of one location going rogue. We go deeper in the GDPR and AI Act compliance Totem builds in, applied equally branch by branch.

When you need a multi-location CRM (and when you don't)

Let's be honest: not everyone needs a family. If you have a single location, or one team serving a single book of business, the family structure is overkill. A regular team is simpler and does exactly what you need. Setting up subteams for no reason just adds layers.

When is it a yes? When you have several business units with different customers under one umbrella: a group of med spas or dental practices with multiple locations, a network of real estate offices by area, a hotel chain, a franchise of driving schools, hair salons or restaurants, or any home-services business with branches by city. If that's you, the family stops being a luxury and becomes the only way not to lose control.

A well-run group shows in how boring month-end is: no one asking for screenshots, no one seeing anyone else's leads, no one arguing over who spent what. If you run multiple locations and still do it with standalone accounts and spreadsheets, this structure is going to take a lot of noise off your plate.

Official sources

• AI Act (Regulation (EU) 2024/1689), art. 50 (transparency) and art. 113 (application) — EUR-Lex
• GDPR (Regulation (EU) 2016/679), art. 22 (automated decisions) and Ch. V, arts. 44–46 (international transfers) — EUR-Lex