When Business Phones Go Down, Who Actually Fixes It?

Your internet goes out at 9:15 on a Tuesday. Within about thirty seconds every desk phone in the building reads “No Service.” Calls in progress have already dropped.

Most articles about this will tell you how to design a system so it does not happen. That advice is real and I will cover it. But it skips the question that actually decides how bad your morning is: when it happens anyway, who picks up the phone and fixes it?

I’m Robert Harney. I’ve been running phone systems for Chicago businesses since 2009, and I still answer the phone here myself. So I have been on the other end of that call a lot of times.

How would yours behave?Talk to a real engineer

What actually happens in the first minute

Being precise about this helps, because the failure is faster and quieter than people expect.

• Active calls drop almost immediately. Voice packets stop arriving, both sides hear silence, and the call ends without a goodbye.
• Phones notice within seconds. Handsets send keepalives to the provider. No response means something is wrong.
• The displays change. “No Service.” “Network Unavailable.” “Unregistered.”
• Your handsets are now paperweights. Powered, lit, and unable to make or receive a call.

The important part is what happens to people calling you. Those calls never reach your building — they reach your provider’s platform. What the platform does with them was decided months ago, by whoever configured your system. If nobody decided, they go to voicemail, or they ring out.

The honest answer about cloud phones and outages

If your internet goes down and nothing was engineered for it, your cloud phones go down. Anyone who tells you otherwise is selling.

What separates a bad morning from a non-event is whether somebody built the backup path before you needed it. There are four layers, and they are not alternatives — they stack:

1. A second internet path — carrier- and route-diverse, so a single outage cannot take both down at once.
2. SD-WAN — it fails over automatically, prioritizes voice when it switches, and is monitored so we see a problem before you do.
3. Cellular (LTE/5G) backup — for when the wired paths are both gone.
4. Cloud, off-site routing — a virtual auto attendant and the mobile app, so calls still reach you even when the building itself is dark.

A second modem is not a backup. A SIM card in a router is not SD-WAN. The difference is whether the switch happens automatically, whether voice gets priority when it does, and whether anyone tested it. Ask to see the failover demonstrated, not described.

One caveat worth knowing before you count on all four: your provider’s own network can limit which layers you can even deploy. Some cable providers are built so you cannot put a second internet line or an SD-WAN device in front of their service at all — only their app keeps working when the circuit drops. So the first question isn’t which layers to add; it’s what your provider’s design will actually allow. That is one of the first things an assessment answers.

The outage nobody plans for: the building

Almost all of the advice out there assumes your internet failed and your people are still at their desks.

Think about the outages that actually cost businesses money in the last few years. A burst pipe. A fire alarm that empties the building for a day. A power failure on the block. A snowstorm nobody can drive in. In every one of those, your internet circuit might be perfectly healthy and completely useless, because nobody is in the building.

That is where a cloud-based virtual auto attendant earns its keep. It sits outside your building entirely, answers your main number, and routes calls to mobile phones or an alternate location. Your customers reach a person. They never learn that your office is dark.

And for organizations that genuinely cannot be down, dual systems — a secondary providing disaster recovery if the primary fails — remove the last single point of failure.

We migrated a Chicago medical group off a premise-based PBX for exactly this reason. When their PBX hung or lost its circuit, the phones were simply down. On the hosted system an SD-WAN backup now covers the internet path, and if something else fails — power, a switch — calls reroute to the Open One app on each person’s phone. Layers, not a single lifeline.

This is also the honest answer to the on-premise question. A local PBX keeps internal calls working during an internet outage, which is a real advantage on a warehouse floor. It does nothing at all when the building is empty. That trade-off, and what is actually happening to the manufacturers who built those systems, is a longer story we covered separately.

Now the part nobody writes about

Say you have done all of it. Second circuit, SD-WAN, mobile failover, tested. Something still breaks — and something eventually does.

Who do you call?

For most businesses the honest answer is four companies. The phone system vendor. The internet provider. The SIP carrier. And whoever manages the network. Each one can see their own piece. None of them can see the whole path a call takes.

So the morning goes like this. The phone vendor says the system is fine and it must be the network. The ISP says the circuit is up and it must be the phone system. The SIP carrier says their trunks are healthy. Somebody suggests you reboot something. Three hours later your phones are working and nobody can tell you why they stopped.

Every failover design in the world assumes somebody is coordinating during the failure. Usually that somebody is you, and it is the worst possible morning to be learning who owns what.

I’m working with a Chicago food distributor right now who lives this. Their voice and internet both run over a single circuit from one cable company — and because that cable company owns the voice service, they cannot even add a second internet line or an SD-WAN device in front of it. The redundancy is architecturally impossible as long as one company owns both. When it fails, everything fails, voice and internet together. They have put the cost of a Friday-morning outage at over $500,000 in lost top-line revenue. That is what “single vendor” really costs when the single vendor is also the single point of failure.

How would you even know something had failed?

Here is the failure nobody plans for, because it does not look like a failure.

Your backup path stops working. Not the primary — the backup. The cellular card, the second circuit, the battery on the device in the closet. Everything still works, every call connects, nobody notices a thing. You now have no redundancy and you believe you do. That situation can run for months, and it ends on the morning the primary fails.

A redundancy you have not verified is not redundancy. It is a belief.

The equipment we deploy is proactively monitored. If a battery backup is not performing correctly, or a path stops responding, the system sends us an alarm code and we investigate — before you have any reason to call us. That is a different relationship to an outage than waiting for a phone to ring.

So add a fifth question to the list you are asking providers: how do you find out my backup has failed, and how long before somebody looks at it? If the answer is that they find out when you tell them, then what you have bought is equipment, not a service.

What single-vendor accountability actually means

This is why, when we deploy a system, we supply the whole path: the phone system, the SD-WAN appliance at the network edge, the SIP trunks, and the support.

It is not a packaging preference. It means that when you call, the person who answers can see the handset, the local network, the internet path, the failover, and the carrier trunks — all at once. There is no one to point at, which is exactly the point.

And the person who answers is a certified engineer, not a queue. On a morning when your phones are down, the difference between an engineer and a ticket number is the whole difference.

It is also why SD-WAN is standard in our deployments rather than an upsell. It is the piece that gives us the secure path in — to monitor, to patch, and to troubleshoot without waiting for someone to let us onto the network.

See it before you need itAsk to see the failover live

Five questions to ask before you need the answers

• Show me the failover working. Not the diagram. Unplug the primary circuit and let me watch.
• What happens to inbound calls during an outage — specifically, where do they go?
• Who do I call at 9am when the phones are down, and who answers?
• How many companies are involved in my phone service, and which one owns the outage?
• What happens if the building is unavailable rather than the internet?

Ask any provider, including us. The answers tell you more than a feature list will.

What to do next

If you do not know how your phones would behave in an outage, that is worth finding out on a quiet Tuesday rather than a loud one. Send us your setup and we will walk through what actually happens — where inbound calls go, what fails over, what does not, and who you would be calling.

Better yet, let us come out and look. We will assess what you have today, map where it would fail, and show you what it takes to put a real disaster-recovery plan in place — the fail-over worth adding, and a migration plan timed to when your current contracts come due, so you are not stuck waiting for a bad morning to switch.

And if you would rather see it than hear it, we will show you. We bring an SD-WAN device, connect it to your network, and pull the primary circuit while you watch the calls keep running — the exact test this article tells you to demand.

Frequently asked questions