One WhatsApp number for a multi-location team: the operating model

A multi-location business does not fail WhatsApp because the staff are lazy. It fails because four phones, four memories, and no shared calendar cannot keep a promise. This guide is the operating model behind a central number: what to decide, what to log, and what to refuse to automate.

Start with one number, not a new app

Most multi-location teams already live in WhatsApp. Receptionists screenshot bookings. Managers forward voice notes. Owners wake up to unread threads on four different phones. The instinct is to buy a new app. The cheaper first move is to treat one WhatsApp number as the public front door and to write down what happens after a message arrives.

A single number is not a product. It is a contract with the customer: this is the only place you need to write, and someone (or something) will answer with the right branch, the right slot, and the right human when the bot is unsure. If you cannot describe that contract in a page, adding an AI assistant will only speed up confusion.

This article is an operating model, not a vendor pitch. It is written for clinic groups, home-service companies, and small retail chains that already take work on WhatsApp. It assumes Arabic and English both show up in the same inbox. It does not invent conversion rates, no-show percentages, or time-to-reply. Those numbers belong in your own logs after you launch.

TeethFlow, the clinic system on this site, is one implementation of the pattern: one Evolution API session, a router, an assistant named Linda, a clinic CRM, and a command center where staff take over. You can copy the pattern without copying the stack. What you cannot skip is the routing, the calendar truth, and the human hand-off. Write this down in the same language your staff use at the desk, not in architecture slang. If two managers disagree, pick the rule that is kinder to the customer and put the other rule in a later version. A short messy document that is true beats a long diagram nobody opens. Re-read the thread the next morning as if you were the patient. Anything that feels like a trap is a trap. Train one super-user per branch before you train everyone. They will translate the tool into local habit. Keep a paper fallback for the first fortnight: a printed slot grid still saves a Saturday. Do not connect billing until bookings survive a public holiday. When in doubt, send fewer messages. Two useful notices beat a drip campaign.

Write the intents before you pick a model

Open last week’s WhatsApp export, or sit with a receptionist for two hours, and tag every inbound message with one intent: book, reschedule, cancel, ask a price, ask a location, complain, emergency, spam, or other. “Other” should hurt. If it is large, your taxonomy is wrong.

Intents drive buttons. Buttons drive speed. If patients can pick a branch from a list, they will. If they must type a neighbourhood, they will type it five different ways and your router will guess. WhatsApp interactive lists and reply buttons exist so that the model is not doing data entry.

Keep a written definition of each intent: what information you must capture, which system of record you write to, who is allowed to override, and what the customer sees while they wait. Booking needs a branch, a service or clinician if you offer a choice, a slot from a real calendar, and a confirmation that can be cancelled. A price question needs a public answer or a human. An emergency should never wait on an LLM.

Do not start with the prompt. Start with the list of intents, then the slots those intents need, then the systems that already hold those slots. Only then decide whether a small FAQ bot, a booking bot, or a full assistant is the right package. Write this down in the same language your staff use at the desk, not in architecture slang. If two managers disagree, pick the rule that is kinder to the customer and put the other rule in a later version. A short messy document that is true beats a long diagram nobody opens. Re-read the thread the next morning as if you were the patient. Anything that feels like a trap is a trap. Train one super-user per branch before you train everyone. They will translate the tool into local habit. Keep a paper fallback for the first fortnight: a printed slot grid still saves a Saturday. Do not connect billing until bookings survive a public holiday. When in doubt, send fewer messages. Two useful notices beat a drip campaign.

Sticky routing beats a daily lottery

Four branches and one number means every conversation must belong to a branch, even when the customer has not said so yet. Sticky routing is the default: if this phone number booked in branch two last month, open the thread on branch two unless they ask to move. First-time contacts land in a “needs routing” board with a time limit. If nobody picks in that window, alert a human. Do not invent a branch.

Round-robin feels fair to managers and is unfair to patients who already have a file. Geography is useful when the customer shares a pin or a district you can map. It is useless when they write “near the club.” History, then explicit choice, then a human, is the order that fails least often.

Document the re-route. Staff will move a chat because the specialist is in another location. That move should leave an audit line: who moved it, when, and why. The outbound WhatsApp number stays the same. The patient should not see a new sender. The CRM record should show the new branch so reminders go out with the right pin.

If two people in the same family share a phone, sticky routing will be wrong sometimes. Allow a “this is for someone else” path. Do not solve that with a clever model. Solve it with a button. Write this down in the same language your staff use at the desk, not in architecture slang. If two managers disagree, pick the rule that is kinder to the customer and put the other rule in a later version. A short messy document that is true beats a long diagram nobody opens. Re-read the thread the next morning as if you were the patient. Anything that feels like a trap is a trap. Train one super-user per branch before you train everyone. They will translate the tool into local habit. Keep a paper fallback for the first fortnight: a printed slot grid still saves a Saturday. Do not connect billing until bookings survive a public holiday. When in doubt, send fewer messages. Two useful notices beat a drip campaign.

The calendar is the only source of truth

A booking bot that offers slots from a spreadsheet someone updated on Sunday will double-book by Tuesday. Read availability from the same store the clinic already uses: doctor shifts, room blocks, public holidays, and already-held appointments, in Africa/Cairo or whatever zone the front desk uses. Convert everything to that zone before you speak to the customer.

Hold a slot when they tap it. Expire the hold if they vanish. Write the appointment when they confirm. Send a WhatsApp confirmation that includes the branch name, time, and a way to cancel. If you take a deposit, send the payment link in the same thread and mark paid only from the payment webhook, never from a screenshot.

Reminders are not marketing. A T-24h message with confirm / reschedule / cancel buttons is operations. A T-2h message with a location pin is operations. If you cannot send those two messages reliably, you are not ready for an AI that books at midnight.

Never let the assistant invent a doctor’s afternoon. If the API is down, say so and offer a human. Silence is worse than a short apology. Write this down in the same language your staff use at the desk, not in architecture slang. If two managers disagree, pick the rule that is kinder to the customer and put the other rule in a later version. A short messy document that is true beats a long diagram nobody opens. Re-read the thread the next morning as if you were the patient. Anything that feels like a trap is a trap. Train one super-user per branch before you train everyone. They will translate the tool into local habit. Keep a paper fallback for the first fortnight: a printed slot grid still saves a Saturday. Do not connect billing until bookings survive a public holiday. When in doubt, send fewer messages. Two useful notices beat a drip campaign.

Linda is a policy, not a personality

Name the assistant if you want. Patients remember names. The important part is the policy: which intents it may close alone, which ones require a button, and which ones stop the bot.

A useful policy looks like this. Booking, reschedule, and cancel may complete without a human if the calendar agrees. FAQ answers may complete if they come from an approved list. Complaints, clinical advice, emergencies, and anything the classifier is unsure about go to a human immediately. When a human takes over, queued AI replies are cancelled. That cancellation must be atomic. Two voices in one thread destroy trust.

Arabic-first does not mean English-never. Detect language per message, not per contact. Keep buttons short. Do not make people type paragraph answers to get a Tuesday slot.

Log the tool calls: which branch was chosen, which slots were offered, which appointment id was written. If you cannot replay a booking from the log, you cannot debug a furious owner on Saturday. Write this down in the same language your staff use at the desk, not in architecture slang. If two managers disagree, pick the rule that is kinder to the customer and put the other rule in a later version. A short messy document that is true beats a long diagram nobody opens. Re-read the thread the next morning as if you were the patient. Anything that feels like a trap is a trap. Train one super-user per branch before you train everyone. They will translate the tool into local habit. Keep a paper fallback for the first fortnight: a printed slot grid still saves a Saturday. Do not connect billing until bookings survive a public holiday. When in doubt, send fewer messages. Two useful notices beat a drip campaign.

The command center is the product for staff

Reception will not open n8n. They need a board that looks like work: needs routing, AI in progress, waiting on customer, waiting on staff, human live, closed. One tap to take over. One tap to send an approved template. A reason when they open a medical note. An 8-hour session that is audited, then closed.

Broadcasts belong here too, with an opt-out that is actually honoured. If you cannot honour opt-out, do not broadcast.

Mobile matters. The person covering Friday evening is not at a desktop. A clinic app that shows AI threads and booking requests, in Arabic, is how the system survives the weekend. The web command center is how a manager sees the whole group on Monday.

Do not hide the bot from staff. Show them the last five assistant turns so they do not ask the patient to repeat. That context window is the whole point of a central number. Write this down in the same language your staff use at the desk, not in architecture slang. If two managers disagree, pick the rule that is kinder to the customer and put the other rule in a later version. A short messy document that is true beats a long diagram nobody opens. Re-read the thread the next morning as if you were the patient. Anything that feels like a trap is a trap. Train one super-user per branch before you train everyone. They will translate the tool into local habit. Keep a paper fallback for the first fortnight: a printed slot grid still saves a Saturday. Do not connect billing until bookings survive a public holiday. When in doubt, send fewer messages. Two useful notices beat a drip campaign.

CRM, WhatsApp, and the spreadsheet must not drift

Pick one system of record for the patient and one for the appointment. WhatsApp is a channel. It is not a database. If the CRM says the visit is cancelled and WhatsApp still sends a reminder, you will look careless.

Write the WhatsApp conversation id onto the patient. Write the appointment id onto the conversation. When staff drag a card on a pipeline, do not invent a second pipeline in chat. One board.

Lead scoring and follow-ups belong after the booking path is boring. A “we missed you” sequence is useful. A clever scorer on day one is theatre. Automated follow-ups should be templates you can read aloud without cringing, with stop conditions: booked, opted out, human live, or three touches.

GoHighLevel, HubSpot, or a custom Postgres with RLS are all valid. The constraint is the same: row-level access so branch staff cannot browse another branch’s phone numbers for fun. Write this down in the same language your staff use at the desk, not in architecture slang. If two managers disagree, pick the rule that is kinder to the customer and put the other rule in a later version. A short messy document that is true beats a long diagram nobody opens. Re-read the thread the next morning as if you were the patient. Anything that feels like a trap is a trap. Train one super-user per branch before you train everyone. They will translate the tool into local habit. Keep a paper fallback for the first fortnight: a printed slot grid still saves a Saturday. Do not connect billing until bookings survive a public holiday. When in doubt, send fewer messages. Two useful notices beat a drip campaign.

After-hours is a design problem

The reason you wanted a bot is the pile of messages at 07:00. Decide what “closed” means per branch, including Ramadan hours and the Thursday that is always short. The assistant can book into tomorrow’s shifts. It should not pretend a clinician is in the chair.

Publish the hours in the first reply. Offer the next open slot. For pain or swelling, give the emergency rule you actually follow: go to a hospital, call this number, or wait until morning. Copy that rule from the medical director, not from a model.

Unrouted after-hours chats still need the 15-minute (or whatever you choose) alert, but the alert goes to the on-call person, not to an empty desk. If nobody is on call, the bot must say when a human will look. Do not leave a typing indicator forever. Write this down in the same language your staff use at the desk, not in architecture slang. If two managers disagree, pick the rule that is kinder to the customer and put the other rule in a later version. A short messy document that is true beats a long diagram nobody opens. Re-read the thread the next morning as if you were the patient. Anything that feels like a trap is a trap. Train one super-user per branch before you train everyone. They will translate the tool into local habit. Keep a paper fallback for the first fortnight: a printed slot grid still saves a Saturday. Do not connect billing until bookings survive a public holiday. When in doubt, send fewer messages. Two useful notices beat a drip campaign.

Privacy, screenshots, and what you put on a marketing site

Clinic WhatsApp is full of names, phone numbers, x-rays, and complaints. Treat the inbox as sensitive even if you are not making a legal claim in this article. Default to least privilege. Gate medical content behind a reason and a timed session. Do not dump raw threads into a shared Google Sheet.

When you later take screenshots for a case study, blur patients. Label redesign mocks as mocks. Never publish a metric you did not measure. This site hides TeethFlow performance numbers until the owner fills them. Copy that discipline.

Vendors will ask for production exports “to improve the model.” If you cannot say what leaves Egypt, do not send the export. Write this down in the same language your staff use at the desk, not in architecture slang. If two managers disagree, pick the rule that is kinder to the customer and put the other rule in a later version. A short messy document that is true beats a long diagram nobody opens. Re-read the thread the next morning as if you were the patient. Anything that feels like a trap is a trap. Train one super-user per branch before you train everyone. They will translate the tool into local habit. Keep a paper fallback for the first fortnight: a printed slot grid still saves a Saturday. Do not connect billing until bookings survive a public holiday. When in doubt, send fewer messages. Two useful notices beat a drip campaign.

A launch sequence that does not require heroics

Week one: one number, one branch, FAQ plus booking into a real calendar, human take-over, reminders. No AI personality. No broadcasts. Watch the needs-routing board like a hawk.

Week two: add the second branch and sticky routing. Only then turn on the assistant for booking intents. Keep complaints on humans.

Week three: remaining branches, templates, the Friday on-call rota. Measure time-to-first-response and percent of chats that needed a human. Do not publish those numbers until you trust the clock.

Week four: deposits if you need them, and a care plan so someone watches failed webhooks. Multi-number and multi-brand wait until one number is boring.

If this matches a paid package on the services page, use that as a scope boundary. A WhatsApp Booking Bot is week one. WhatsApp plus AI CRM is weeks two and three. Full business automation is the reporting panel, extra numbers, and the n8n agent that is not pretending to be a clinician. Write this down in the same language your staff use at the desk, not in architecture slang. If two managers disagree, pick the rule that is kinder to the customer and put the other rule in a later version. A short messy document that is true beats a long diagram nobody opens. Re-read the thread the next morning as if you were the patient. Anything that feels like a trap is a trap. Train one super-user per branch before you train everyone. They will translate the tool into local habit. Keep a paper fallback for the first fortnight: a printed slot grid still saves a Saturday. Do not connect billing until bookings survive a public holiday. When in doubt, send fewer messages. Two useful notices beat a drip campaign.

What “good” looks like in the logs

You are looking for absences. No double bookings. No reminder after a cancel. No AI reply after take-over. No broadcast to opted-out numbers. No slot offered outside a shift. No thread stuck in needs-routing past your alert.

You are also looking for a replay. Given a conversation id, you can see the intents, the tools, the appointment row, and the human who jumped in. If the log is only prompt text, you will not sleep.

When something breaks, the first question is “which branch did we think this was?” The second is “what did the calendar say at that second?” Everything else is decoration. Write this down in the same language your staff use at the desk, not in architecture slang. If two managers disagree, pick the rule that is kinder to the customer and put the other rule in a later version. A short messy document that is true beats a long diagram nobody opens. Re-read the thread the next morning as if you were the patient. Anything that feels like a trap is a trap. Train one super-user per branch before you train everyone. They will translate the tool into local habit. Keep a paper fallback for the first fortnight: a printed slot grid still saves a Saturday. Do not connect billing until bookings survive a public holiday. When in doubt, send fewer messages. Two useful notices beat a drip campaign.

Buying versus building

Build when the calendar is idiosyncratic, when Arabic buttons matter, and when staff already have a clinic app. Buy when you are one location with a simple booking page and you will not custom-route.

Middle path: a booking bot into a sheet, then a CRM, then an assistant. That is how you avoid paying for a command center you will not open.

Whatever you choose, keep the WhatsApp session under an account you control. Session loss is an outage. Treat Evolution API, Cloud API, or a BSP as infrastructure with a named owner, a backup login, and a test number that is not the public line. Write this down in the same language your staff use at the desk, not in architecture slang. If two managers disagree, pick the rule that is kinder to the customer and put the other rule in a later version. A short messy document that is true beats a long diagram nobody opens. Re-read the thread the next morning as if you were the patient. Anything that feels like a trap is a trap. Train one super-user per branch before you train everyone. They will translate the tool into local habit. Keep a paper fallback for the first fortnight: a printed slot grid still saves a Saturday. Do not connect billing until bookings survive a public holiday. When in doubt, send fewer messages. Two useful notices beat a drip campaign.

Copy-paste checklist for the kickoff call

Bring: the public number you want to keep, the list of branches with legal names you are allowed to print, the calendar system, the CRM, who is on-call after hours, the emergency sentence, the services that can be booked without a clinical exam, and whether deposits are required.

Decide: sticky routing rules, hold duration, reminder times, languages, and which intents are human-only.

Refuse: scraped competitor prices, invented wait times, and any screenshot with a real patient face.

Leave with: a one-page scope, a week-one milestone that books into a real shift, and a named human who will tap take-over on night one. Write this down in the same language your staff use at the desk, not in architecture slang. If two managers disagree, pick the rule that is kinder to the customer and put the other rule in a later version. A short messy document that is true beats a long diagram nobody opens. Re-read the thread the next morning as if you were the patient. Anything that feels like a trap is a trap. Train one super-user per branch before you train everyone. They will translate the tool into local habit. Keep a paper fallback for the first fortnight: a printed slot grid still saves a Saturday. Do not connect billing until bookings survive a public holiday. When in doubt, send fewer messages. Two useful notices beat a drip campaign.

Closing

If you only do one thing after reading this, write the intent list and the human-only list on a single page and hang it next to the reception printer. The software can wait a week. The contract with the customer cannot.

When you want the pattern in production rather than on a whiteboard, the live TeethFlow case study and sample-data demo sit at /demos/whatsapp-crm, and the services page lists the booking-bot, AI CRM, and full-automation packages with their current starting prices.

The work is unglamorous: a routing rule, a calendar that does not lie, a take-over button that actually stops the bot, and two reminder messages that respect a cancel. Do those four things on one number for one branch until they are boring. Then add a branch. Then add a model. That order is how a daily operations inbox becomes a system you can hand to a new receptionist without a two-hour speech. If a vendor or an agent inverts the order, ask them to show the needs-routing board and the appointment row for a chat that happened at 23:40 last Thursday. If they cannot, you are buying a demo, not a front door.