A customer asks your central team for a repair appointment at one location. The team quotes the usual price, but the branch says the requested slot is unavailable. The customer asks, “Which answer should I trust?” This is not primarily a WhatsApp number problem. It is a decision-ownership problem.
If you operate several branches, define who can approve what before buying another inbox or hiring more agents. Some answers should be consistent across the company. Others depend on the location that will actually deliver the service.
Three operating models, with different trade-offs
Fully centralized: One team receives inquiries and owns replies and next steps. This can work when services, prices, and schedules are genuinely standardized. It becomes a bottleneck when every availability question requires a call to a branch manager.
Branch-led: Each location handles its own customers and decisions. Local knowledge can improve execution, but different branches may give conflicting answers about a shared warranty or return policy. Management can also lose visibility when a case moves between locations.
Hybrid: Headquarters approves shared policies and reviews quality, while the branch confirms local capacity, fulfillment, and exceptions. It is a useful model to test, not a universal answer.
The critical distinction is where reliable information lives and who has authority to act, not where an agent happens to sit. Zendesk's guide to one versus multiple support instances describes the trade-off between shared records and reporting on one side and access-control and routing complexity on the other. It documents a separate global product, not built-in capabilities of Mr. AI.
Assign four decisions, not just four queues
General information: Central operations owns the approved description of services and core policies, including review dates. An agent or AI assistant uses the current approved version regardless of location.
Location-specific price: Do not quote one price as universal unless it really is. The authorized branch or pricing owner must confirm what applies before anyone makes a commitment.
Booking or fulfillment slot: Reception can capture the request and intended location, but the responsible team must verify availability before a booking is confirmed. “We received your request” is not the same as “Your appointment is confirmed.”
Complaint or exception: Keep one accountable case owner even when several departments contribute to the resolution. Reassigning a complaint is not resolving it.
For each decision, record three things: who maintains the facts, who approves the commitment, and who communicates it. If two teams believe they have final authority over the same promise, resolve that conflict before automating replies.
Example: the customer switches branches mid-conversation
Consider a hypothetical repair-service chain. A customer first asks about the Giza location, then switches to New Cairo for an earlier appointment. The reception team should not restart the conversation. It can retain the service type, device model, and preferred time, then check the new branch's availability.
The original branch should no longer own the new appointment, but the record should preserve why the request moved. If the customer has already paid or received a confirmed booking, changing locations requires review by the booking owner before any existing commitment is altered. This is an illustrative workflow, not a real customer result or proof of a booking-system integration in Mr. AI.
If your immediate question is one WhatsApp number versus a separate number per location, read our guide to multi-branch WhatsApp inquiries. Number architecture is a channel decision. Approval authority is a separate operating decision.
Test the ownership model for one week
Review a sample of branch conversations from a normal working week, removing personal details where appropriate. Do not borrow a generic success target. Establish your own baseline.
At intake, note the intended branch, request type, current owner, and whether approval is required. At the end of each day, review cases transferred between teams. Was a reply delayed because nobody owned the decision? Did the customer receive conflicting prices? Did they repeat their details? Did the case finish with a clear next action?
Track time to an accountable owner, unnecessary transfers, and cases left without an owner. Do not count a handoff as a resolution. If the test fails because nobody maintains current appointment availability, a faster routing tool will not solve the underlying information gap.
Zendesk's custom routing queue documentation, edited October 8, 2026, explains primary and fallback agent groups in a specialist support system. It supports the operating principle of a backup owner; it does not establish that the same routing features are available in Mr. AI.
Where AI helps, and where it does not decide
The current published scope of Mr. AI includes responses based on company knowledge, follow-ups, conversation summaries, and human handoff. Those functions can preserve context and make next steps clearer. They do not authorize an assistant to promise a branch-specific price or confirm a booking without an approved source and the right checks. Nor should you assume automatic geographic routing or branch scheduling integrations.
Define decision rights first, test realistic inquiries from each location, and then use a one-branch AI pilot before expanding. If agents work shifts, combine case ownership with a documented support shift handover so responsibility does not disappear when people change.
The right answer is rarely “centralize everything” or “leave everything local.” It is to ensure every customer commitment has an approved source, a decision owner, and someone accountable for follow-through.
