A business opens a second office, then a third. Each one arrived with its own phone line, its own handsets and its own way of answering. Head office has a receptionist; the Leeds branch rings every desk at once; the warehouse number goes to an answerphone after 5pm. A customer who calls the wrong site is given another number to try. Nobody can say how many calls were missed last week, and adding a new starter means three phone calls to three suppliers.
That is the situation a multi-site phone system is meant to resolve. This guide is about the planning decisions behind it: which numbers to keep, who answers, how calls move between locations, who makes changes, and what happens when one site’s internet goes down. Cisco Webex Calling is the platform used to illustrate the answers, but most of the decisions apply whichever cloud phone system you choose, and they are worth settling before you speak to any supplier.
What is a multi-site phone system?
A multi-site phone system is one business phone service that covers two or more locations, so that calls, numbers, extensions and call handling are coordinated across the organisation rather than managed site by site.
The contrast is with the arrangement most growing businesses drift into: several locations, each operating a disconnected telephone system. Separate lines, separate contracts, separate voicemail, and no way to transfer a caller from one office to another except by reading out a number.
With a coordinated cloud phone system, the service runs in the provider’s data centres rather than in a cupboard at each site. Every location connects to the same system over its internet connection, so staff in different offices can dial each other by extension, transfer calls between sites and appear on the same company directory. Administrators see all locations in one place.
It is worth being precise about what “one system” does and does not mean:
- It does not mean one public phone number. Each site can keep its own numbers, subject to porting, and callers need not notice any change.
- It does not mean identical settings everywhere. Each location can have its own opening hours, greetings, routing and even its own way of connecting to the public telephone network.
- It does not mean every manager gets full administrative control. Access can be scoped, and many businesses prefer the provider to make most changes.
- It does mean one directory, one set of rules for how calls flow between sites, one place to report on calls, and one supplier relationship.
Where Webex Calling fits. Cisco Webex Calling is a cloud phone system in which each physical site is set up as a location within the business’s account. Cisco’s documentation describes locations as the way to organise users and shared devices by physical address; each user and each shared workspace belongs to exactly one location, and calling features and settings are applied at that level. That structure maps naturally onto a business with a head office, branches and remote staff, which is why it is a sensible basis for the decisions that follow.
Keep local numbers or use one main number?
This is usually the first question a multi-site business asks, and the answer is rarely all-or-nothing.
Separate local numbers for each branch. Customers who have always rung the Bristol office keep ringing the Bristol number, and calls land with the Bristol team. Local identity is preserved, which matters for businesses whose customers choose them partly because they are nearby: trades, estate agents, surgeries, regional depots. The trade-off is that each branch needs its own answering arrangement, and a caller who rings the wrong site needs to be transferred rather than told to redial.
One main number with a menu or reception team. All advertised contact goes through a single number, answered centrally or by an automated menu (“press 1 for Bristol, 2 for Leeds”). This gives a consistent experience and makes staffing easier, because one team covers everything. The trade-off is weaker local identity, and a longer route for a customer who simply wants the person they spoke to last week.
A combination. In practice most multi-site SMEs land here. Branch numbers stay live for existing customers and local marketing, while a central number is used for new enquiries, head-office functions and out-of-hours cover. Calls to any number can be routed anywhere, so the public-facing numbers and the people who answer them no longer need to be in the same building.
Two practical points shape the decision.
First, transferring between sites becomes a normal action rather than a workaround. With all locations on one cloud phone system, a receptionist in one office can transfer a caller to a colleague in another office, or to a remote worker, by extension or by name from the directory. That alone removes most of the “let me give you another number” moments.
Second, keeping existing numbers depends on porting. Number porting is the process of moving a phone number from one provider to another. Most UK geographic numbers can be ported, but eligibility depends on the current provider, the type of line and the contract it sits on. Treat retention as something to confirm number by number with your provider, with a plan for the porting dates, rather than an assumption. A business that has acquired another company, or that has numbers spread across several legacy suppliers, should list every number early because this is where surprises tend to surface.
Centralised, local or shared reception?
Once calls can be routed anywhere, who answers them becomes a design choice rather than a consequence of where the phone line enters the building.
| Model | When it may suit | Main trade-off |
| Centralised answering | A small reception or admin team at head office can comfortably handle call volume for all sites; a consistent first impression matters more than local familiarity; branches are small or often unstaffed at the front desk. | Central staff need good knowledge of every site and reliable ways to transfer. Local callers may feel they are talking to “head office” rather than their branch. |
| Branch-based answering | Each location has staff available to answer, local knowledge matters (directions, stock, local contacts) and customers value speaking to the branch directly. | Quality depends on each site’s staffing. Lunch breaks, sickness and busy periods create gaps unless an overflow is designed in. |
| Shared or overflow answering | Branches answer first, but unanswered or out-of-hours calls roll to another site, a central team or a remote worker. Suits businesses with uneven staffing across sites or long opening hours. | Needs clear rules about who picks up what, and the overflow team must be able to help rather than just take a message. More routing to maintain. |
The third model is often the practical answer, because it keeps local identity while making sure the phone is answered when the local team cannot. Designing it means thinking about:
- Opening hours. Which sites open when, and where calls should go outside those hours. A branch that closes at 5pm can route to head office until 6pm and to voicemail after that.
- Holidays and closures. Bank holidays, Christmas shutdowns and local closures such as a stock-take day, and who is responsible for switching the routing.
- Busy periods. Monday mornings in a service business, month-end in accounts, campaign launches. Overflow after a set number of rings or a set wait time protects the caller’s experience without adding permanent headcount.
- Staff availability. Whether the people in an answering group are at desks, on the shop floor or moving between sites, and whether they answer on a handset, the app or a mobile.
Three building blocks make these designs work, and it helps to know their names. An auto attendant is a recorded menu that greets callers and routes them by key press. A hunt group rings a defined set of people, in sequence or all at once, until someone answers. A call queue holds callers in line with announcements until a member of the group is free. In Webex Calling, these are configured against the relevant location, so a Leeds hunt group and a Bristol hunt group can behave differently while living in the same system. Which of them you need, and how they chain together, is the substance of a reception design; the full feature list is a separate subject.
How should calls move between locations?
The internal side of a multi-site phone system is less visible to customers but matters just as much to staff. Five decisions cover most of it.
A clear extension-numbering plan. Every user and shared phone gets an internal extension. Decide the length once, for the whole organisation (Cisco’s dial-plan documentation allows 2 to 10 digits, with 4 as the default), and allocate ranges by site or by department so that numbers are easy to remember: 1xxx for head office, 2xxx for the first branch, and so on. Changing extension length later is possible but disruptive, so it is worth getting right before the first site goes live.
Transferring to another branch or department. Because every location is on one system, a transfer to a colleague in another office is the same action as a transfer to the next desk: by extension, or by searching the directory in the app. Decide whether transfers should be announced (the transferring person speaks to the colleague first) or blind, and make that the house style, because it shapes the caller’s experience more than any setting does.
Duplicate extensions and location prefixes. If two sites have both used extension 200 for reception for years, you have a choice. Either renumber one of them, or keep both and use a location prefix. Webex Calling supports a routing prefix per location: Cisco’s documentation states that where multiple locations share the same extension, users dial the location prefix followed by the extension to reach the other site. Each location’s prefix must be unique, and the prefix length is set organisation-wide. Renumbering is cleaner for a small number of sites; prefixes become more useful as the site count grows or when an acquired business arrives with an established extension plan.
Branch-specific opening hours and overflow. Each location can have its own schedule, so the Leeds auto attendant can switch to an out-of-hours greeting at 5.30pm while head office stays open until 6pm. The overflow destination is a separate decision for each site: another branch, a central team, a named person’s mobile app, or voicemail. Write these rules down as a simple table before anyone configures anything, because this is where most “why did that call go there?” questions come from later.
Remote staff in the wider arrangement. A home-based account manager or a field engineer belongs to a location for administrative purposes but works from the Webex App on a laptop or mobile. They can be a member of a hunt group or queue just like an office-based colleague, which means a thin branch can be backed up by people who are not in the building. The design question is whether remote staff should be in the first ring group or only in the overflow, and whether their presence status in the app should be relied on to show availability.
None of this requires a technical manual to decide. It requires someone who knows how the business actually works to answer the questions above; the configuration follows from the answers.
Who manages the system?
A single system raises a question that separate systems never did: who is allowed to change what?
There are three sensible answers, and most businesses use a mix.
- Central administration. An office manager or IT manager at head office makes changes for all sites. Consistent, but it can become a bottleneck if every branch greeting goes through one person.
- Local responsibility. A nominated person at each branch handles routine local changes. Faster, but it needs training and clear limits, so that a well-meaning branch manager cannot accidentally reroute head office.
- Provider-managed changes. Changes are requested from the provider, who makes them. Lowest effort and lowest risk for the business; the trade-off is that the business depends on the provider’s responsiveness and the terms of the support arrangement.
Three everyday examples show how the choice plays out:
- Adding a starter at a branch: creating the user, assigning a licence, an extension and a device, and adding them to the right hunt group. Often central or provider-managed, because it touches licensing.
- Updating a branch greeting for a local promotion or a change of staff: a candidate for local responsibility, if the right person has access to that location only.
- Changing holiday opening hours across all sites before Christmas: central, with a checklist, because a missed site means callers hearing the wrong message for a week.
Webex Calling’s administration portal, Control Hub, is where all of this happens. Cisco’s documentation describes applying settings and administrative features to groups and locations, and the platform supports administrator roles with different scopes. Whether your organisation holds full administrator access, scoped access for named people, or requests changes through Fidelity, is a matter of the service you agree, not something that comes automatically with the licences. Fidelity’s Webex page describes role-based admin access and a consultative approach to how each business is set up; the right split of responsibilities is one of the things to settle in that conversation, alongside what is included in ongoing support.
What happens if one location loses connectivity?
This is the question that worries operations directors most, and it deserves a clear answer rather than reassurance. It helps to separate four things that are easy to run together.
The cloud service itself. Webex Calling runs in Cisco’s cloud, not at your sites. A broadband fault in Leeds does not switch off the phone system; the other locations carry on, and the Leeds numbers still exist and can still be routed.
The affected site reaching it. Desk phones and apps in the affected building depend on that building’s internet connection. If it is down, those devices cannot register with the service, so they will not ring. A backup connection, such as a second broadband line or a 4G/5G router, is a separate arrangement to specify and pay for, not a default.
Calls reaching somewhere else. Because routing lives in the cloud, calls to the Leeds numbers can be sent to another site, a central team or named individuals. Staff with the Webex App on a mobile can continue to make and receive calls over mobile data, where coverage allows. Whether this rerouting happens automatically, requires an administrator to switch a pre-built “site down” rule, or needs a request to the provider, is a design decision. Make it deliberately, and make sure someone knows how to trigger it at 8.30 on a Monday morning.
Separately configured survivability. Cisco offers survivability options that allow certain calling functions to continue locally during a loss of cloud connectivity. Fidelity’s Webex page refers to survivability options for multi-site organisations. These are additional components with their own design and cost; they are not included with a standard calling licence and are not needed by every business. If a site cannot tolerate any interruption, raise it specifically.
Continuity is therefore a plan, not a feature. Decide which sites matter most, what the fallback is for each, who triggers it, and then test it in a quiet period rather than discovering the gaps during an outage.
One further item to confirm with your provider is emergency calling. In the UK, calls to 999 and 112 from a cloud phone system depend on the service holding accurate location information for each site and each user, and on the arrangements the provider has in place for when a site’s connectivity fails. Keep registered addresses current as staff move between sites or work from home, and ask how the service handles it rather than assuming. Detailed broadband and resilience specifications are outside this guide; Fidelity’s business phone systems page is the starting point for the connectivity conversation.
An illustrative three-site example
The following is a hypothetical design, not a Fidelity customer story, and it makes no claims about results. It shows how the decisions above fit together for a 75-person business with a head office and two branches.
The business keeps all three local numbers. Head office also advertises a national number for new enquiries. Each branch answers its own calls first, with head office as overflow. Head office’s own overflow is a small group of experienced staff who work partly from home.
| Location | Preferred incoming-call arrangement | Overflow destination | Who manages local changes |
| Head office (40 staff) | Local number and national enquiry number answered by a two-person reception team via a call queue; auto attendant out of hours. | After 20 seconds, a hunt group of three account managers (two remote, on the app). After hours, voicemail with email notification. | Office manager holds scoped admin access for all locations; licensing and new users requested through the provider. |
| Northern branch (20 staff) | Local number rings a branch hunt group of four front-desk staff simultaneously. | Unanswered after 15 seconds, or outside branch hours (8.30am to 5pm), to the head-office reception queue. | Branch manager can update the branch greeting and holiday hours only; everything else via head office. |
| Southern depot (15 staff) | Local number answered by a shared-area phone on the trade counter, with a second shared phone in the warehouse. | Unanswered after 15 seconds to the depot manager’s mobile app, then to head-office reception. | Depot manager has no admin access; changes go through head office. |
Internally, all three sites use four-digit extensions in distinct ranges (1xxx, 2xxx, 3xxx), so no prefixes are needed and any member of staff can transfer a caller to any other site by extension or by name. If the Northern branch’s broadband fails, its number is already configured to overflow to head office, so callers are answered; the branch team use the mobile app for outbound calls until the connection returns. Whether that overflow needs a manual switch or happens on the existing timer is something the business would decide and test.
Planning the next location
One of the quieter benefits of a coordinated system is that a fourth site becomes an addition to an existing design rather than a new project. Even so, each new location should be reviewed on five points before it goes live:
- Users and shared workspaces. Who is based there, who needs a personal extension and app, and which areas need a shared phone (reception, meeting room, warehouse, kitchen).
- Numbers and extension ranges. Whether the site brings existing numbers to port, needs new ones, and which extension range it takes in the organisation-wide plan.
- Reception and opening-hours rules. Which answering model applies, the opening schedule, and the overflow destination in both directions (does the new site also back anyone else up?).
- Devices, connectivity and emergency-calling information. Handsets or apps, the quality of the site’s internet connection, any backup, and the registered address for emergency calls.
- Permissions, training and responsibility. Who can change what at the new site, and a short induction for staff on transferring and the app.
A note of realism for businesses growing by acquisition: an acquired company arrives with its own contracts, numbers, possibly a different phone platform and sometimes a separate Microsoft or Webex tenant. These can usually be brought onto the same system, but not always instantly. Contract end dates, porting lead times and any tenant consolidation set the pace, which is why a phased approach, site by site, is normal. Fidelity’s practical guide to moving a business phone system to VoIP covers how a phased migration is run.
A practical planning checklist
Before speaking to a supplier about a multi-site phone system, gather the following. It turns a vague “we need to sort out the phones” into a brief a provider can respond to properly.
- Sites: every location, its address, headcount and whether it has a front desk.
- Numbers: every number the business owns, which provider holds it, and which contract it sits on.
- Peak incoming calls: roughly when and where calls peak, and how often they go unanswered today.
- Reception model: centralised, local or shared, and who would be in each answering group.
- Operating hours: per site, including seasonal or holiday variations, and who changes them.
- Remote users: who works away from a site and whether they should answer customer calls.
- Existing contracts: end dates and notice periods for current phone, line and broadband services at each site.
- Connectivity: the type and reliability of each site’s internet connection, and whether any site has a backup.
- Continuity requirements: which sites cannot tolerate an outage, and what an acceptable fallback looks like.
- Growth plans: sites or acquisitions expected in the next one to two years.
Frequently asked questions
Can each branch keep its local phone number?
Usually, through number porting, but it must be confirmed for each number with the provider. Eligibility depends on the current supplier, line type and contract, and porting needs to be scheduled around the cut-over for each site.
Can two locations share responsibility for answering calls?
Yes. Hunt groups and call queues can include staff from different locations and remote workers, and one site can be set as the overflow for another. The design work is deciding the order and the timing, not whether it is possible.
Can different offices have different opening hours?
Yes. Each location can have its own schedule, greetings and out-of-hours routing within the same system, which is one of the main reasons to treat sites as separate locations rather than one block.
Can we introduce the system one location at a time?
Yes, and a phased roll-out is the usual approach. The sequence is typically set by contract end dates, porting lead times and which site’s current arrangement causes the most problems. Calls can be routed between the new system and sites that have not yet moved during the transition.
Can an acquired business join the same system?
Generally, yes, but the timing depends on its existing contracts, numbers and platform, and on whether any separate tenant needs consolidating. Treat it as its own phase with its own review rather than assuming it can be absorbed on day one.
Fidelity Group’s role and the next step
The decisions in this guide are not technical ones, but they do benefit from someone who has seen how they play out across many businesses. Fidelity Group works with UK organisations on this basis: starting with how the business operates, its sites, its numbers and its call-handling requirements, and then designing the Webex Calling set-up around that, rather than fitting the business to a standard template. Fidelity’s Webex page describes this consultative approach, phased roll-outs and ongoing administration through one accountable partner.
If your business operates from two or more locations and the phones have grown up site by site, the useful first step is a structured look at what you have and what you want it to do. Book a multi-site phone system review with Fidelity to work through your sites, numbers and reception model, or read more about Cisco Webex Calling from Fidelity Group.
Sources referenced in this article
- Cisco, Locations in Control Hub (updated 5 June 2026)
- Cisco, Configure your Webex Calling dial plan (updated 22 April 2026)
