Ten locations.
One phone system.
Nine fewer FTE.

The practice started with three locations in and around Detroit, running on a mix of Comcast and AT&T voice service. The setup worked, more or less, in the way most multi-site small businesses work: three phone systems, three bills, three admin interfaces, and no particular ability for one office to answer calls that came in for another. If someone called the Detroit office looking to schedule an appointment and nobody picked up, the call rang out, went to voicemail, or dropped. The patient called back later, or called a different practice, or gave up.

Then the practice started growing. Three locations became five. Five became seven. The expansion was reaching into cities with different cable franchise footprints and different incumbent carrier territories — some where Comcast had the fiber in the ground, some where AT&T did, some where neither of them was the right vendor for the service the practice actually needed. Each new location added another vendor contract, another standalone phone system, another bill, another set of credentials. The problem wasn't that it couldn't be done. It was that doing it meant the phone system got worse every time the practice grew.

That's the point at which the practice called us. They weren't just looking for a vendor — they were looking for a way out of a structural problem: how do you run one coherent communications operation across ten locations when the physical carrier infrastructure underneath you doesn't allow it?

The problem nobody tells you about multi-site expansion

A detail most buyers only discover after they've committed to it: the US telecom landscape is carrier-regional, not national-uniform. Comcast serves some cities and not others. AT&T serves some cities and not others. Different cable franchise agreements, different ILEC and CLEC footprints, different fiber reach, different last-mile infrastructure. The map of "who can give you voice service at this address" looks less like a national grid and more like a patchwork quilt where the seams don't quite line up.

This is invisible when you have one office. It's manageable when you have two. By the time you have five, it has started to shape your operations — because each carrier has its own phone system, its own admin interface, its own billing, and critically, no native way to route a call from one carrier's territory to another carrier's territory as if they were the same system. Multi-site communications across carrier regions is not a feature you turn on. It's an integration project that most national providers can't deliver cleanly, because they don't actually operate as a single provider — they operate as a stitched-together collection of regional subsidiaries, resold capacity, and partner agreements.

For the podiatric practice, this meant something concrete: when a patient called the Detroit office on a Wednesday and the Detroit office happened to be closed that day, there was no mechanism for that call to reach the Dearborn office that was open. Not because the Dearborn staff didn't want to take the call. Because the Detroit office's phone number lived on one carrier's network, the Dearborn office's phone number lived on another carrier's network, and the only way to bridge them was to install a third system that could sit on top of both. That system is what EBC built.

What a cloud-resident platform actually unlocks

EBC's platform doesn't live on any particular carrier's network. It lives in the cloud, routing SIP traffic over whatever internet connection each location happens to have — Comcast cable in one city, AT&T fiber in another, a smaller regional provider in a third. The underlying internet carriers don't need to be the same across locations, and the practice doesn't need to care which one is at each address. From the phone system's perspective, every location is just another endpoint on a single platform, and routing between them is a configuration choice, not an infrastructure limitation.

Once the practice was off the legacy carrier phone systems and onto a single cloud platform, the operational transformation wasn't just that the systems unified — it was that previously impossible routing patterns became configurable in minutes. Here are a few that mattered for the practice:

Day-of-week routing

Not every location is open every day. Some branches close on Wednesdays; others close on Fridays; a few operate only a half day on certain weekdays. Historically this meant patients calling the "closed" location got voicemail. On the EBC platform, each location's inbound number has a schedule: during open hours, calls route to the local branch; during closed hours, calls route to a sister location that is open — selected by proximity, by availability, or by whatever logic the practice administrators prefer. The patient doesn't know their call was redirected. They just reach someone who can help them.

Holiday and snow-day overrides

Metro Detroit gets weather. Holidays shift from year to year. The practice needs the ability to flip a schedule for an entire network of locations with one setting — "we're closed today" — and have all inbound calls across all branches route to a central answering coverage without someone having to log in to ten separate systems and reconfigure them individually. In the legacy setup this was practically impossible. In the EBC setup it's a single administrative action that propagates across all locations in seconds.

Branch-of-origin awareness

When a Wednesday-closed Detroit call routes to the Dearborn office, the agent answering the call needs to know what the patient actually called about: which branch they consider their home office, which doctor they typically see, whether they're calling to schedule, confirm, or reschedule. That context travels with the call. The screen pop tells the Dearborn agent "this patient is calling the Detroit location, their primary provider is Dr. X, their last visit was [date]." The patient experience is seamless. The agent is informed. The practice doesn't lose the call to a confused handoff.

Granular administrative control

Not every schedule change should require an admin's involvement, but not every daily user should be able to change routing either. The platform supports a role model that gives location managers the ability to update that location's own schedule and voicemail greetings; administrators get the ability to change network-wide routing, holiday overrides, and after-hours coverage. The permissions are declarative and visible — nobody is accidentally rerouting a hundred calls to the wrong office because they clicked the wrong setting.

The staffing math that pays for the architecture

This is the part of the story that makes CFOs lean forward. The traditional model for staffing a ten-location practice looks like this: each location needs its own front-desk coverage for phones, which realistically means two full-time employees per location — one primary, one backup for lunch, breaks, and absences. Ten locations × 2 FTE = twenty front-desk employees whose primary job is answering phones.

The EBC-architected setup replaced that model with something structurally different: one centralized FTE handles inbound call traffic for all ten locations, supplemented by one in-branch FTE per location when that location is open. The central operator — working from a home office with full remote access to the platform — handles overflow, after-hours routing, cross-branch coverage, and any call where the local branch isn't available. The in-branch staff handles the immediate, in-person side of the operation.

Nine FTE eliminated by routing architecture. At typical front-desk compensation plus benefits in a mid-market healthcare operation, that's a materially large annual cost structure the practice doesn't carry — not because they cut corners on patient service, but because the communications architecture let one centralized person do work that would otherwise have required a distributed team they'd have had to hire, train, retain, and manage across ten locations.

And critically, the patient experience didn't degrade with the staffing change. If anything, it improved. A single central operator with full context about every location can route a call more intelligently than a decentralized front desk that only knows its own branch. The central FTE sees the whole network. The in-branch FTE handles what happens inside their four walls. The split works because the platform makes it work.

Fax, remote access, and the other things that came with the move

Replacing the legacy phone systems wasn't the only part of the transition. Multi-site medical practices have a specific set of adjacent communications infrastructure that tends to all break at once:

• Analog fax — the practice had analog fax machines at every location for insurance filings, provider referrals, and prescription authorizations. These were replaced with e-fax, delivered through the same platform. Faxes now arrive as PDFs in secure folders routed by location; outgoing faxes are sent from any workstation.
• Remote administrative access — the central operator works from a home office. The platform's web and softphone clients mean they have full access to every location's call flow, voicemail, and routing configuration without needing to be physically present anywhere. For a role that's effectively doing the work of a ten-location switchboard, remote work isn't a perk; it's the only configuration that scales.
• Messaging and SMS — patient appointment reminders, confirmations, and reschedule requests now move through SMS integrated with the practice management system. Phone, SMS, and e-fax share a single administrative surface, which means staff training is one skill set, not three.

None of these are exotic capabilities on their own. The point is that consolidating them onto a single platform — rather than operating phone, fax, and messaging as three independent systems from three independent vendors — removes a layer of operational friction that most multi-site practices just quietly absorb as the cost of doing business.

Why this architecture works everywhere legacy carriers can't

Here's a routing scenario that would have been impossible on the practice's old setup, and is routine on the new one:

On the legacy setup, step 2 was where the call ended. The Detroit office's phone system had no idea the Dearborn office existed, and no mechanism to route to it. They were different carriers, different systems, different worlds. On the cloud-resident platform, step 2 is the start of the real routing logic — because the platform sees all ten locations as a single system, and routes based on who's available rather than who the call was directed at.

This is the structural claim at the heart of the story. The problem the practice had wasn't a vendor problem — any individual carrier could have given them better service at any individual location. The problem was an architecture problem: no national carrier could give them an integrated system across a geographic footprint that spans multiple carrier regions. The only architecture that solves it is one that doesn't depend on any particular carrier's infrastructure — a cloud-resident platform that routes over whatever internet connection each location happens to have.

The principle this leaves behind

Multi-site growth exposes the limitations of carrier-tied communications in a way that single-site operation never does. A practice with one location can be happy on Comcast for a decade. A practice with ten locations across metro Detroit discovers, usually painfully, that no single national carrier can give them what one unified system should be able to give them — and that the operational cost of running fragmented systems quietly accumulates in overhead, staffing, and lost calls.

The podiatric practice is now one of our longer-running multi-site deployments. The architecture they're on today was designed around their specific operational shape — ten locations, variable schedules, central-plus-local staffing, integrated fax and SMS, patient-context-aware routing. The reason it works isn't that we invented any of those capabilities. It's that we stitched them together into one coherent system on a platform that doesn't care which carrier is in each city — and that willingness and ability to do the stitching, specific to each client's actual operation, is what separates a bespoke deployment from a templated UCaaS plan.

For any mid-market multi-site business — healthcare practices, retail chains, professional services with branch offices, distributed nonprofits — the diagnostic question is the same: are your communications currently constrained by the fragmentation of the carriers underneath them? If the answer is yes, the fix isn't a different carrier. It's a different architecture.

That's the work. We've done it. We're happy to talk about doing it for you.