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.

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 mistake that rules out a backup entirely

Do not buy your voice service and your internet from the same provider. When a cable or internet company also supplies your phone service, a second internet circuit from a different carrier usually cannot connect into it, and neither can an SD-WAN device. You end up with one circuit carrying everything, and no way to add a backup path. Keep voice and internet separate, and redundancy stays possible.

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, to the VoIP app on your team’s smartphones and laptops, or to an alternate location. Your customers reach a person. They never learn that your office is dark.

A virtual auto attendant is part of a hosted system, and it can also be added to an on-premise PBX when the SIP trunking provider can handle the failover. In our case, if we cannot see your PBX, we automatically reroute the calls — to a virtual auto attendant that forwards them to cell phones and other numbers. That makes it a good interim step if you are still under contract on your current system and want protection against outages now.

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

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: What Is a PBX Phone System — and Why Yours May Be on Borrowed Time.

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.

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 one more 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. And when the primary connection fails, it automatically switches the conversation to the backup path.

What does this look like in a real business?

A food distributor running everything on one circuit

This one is a business we are talking with now. They have had outages and have not yet decided to move. The entire company — voice and internet — runs on a single cable internet circuit, with their phone service supplied by the same provider and no backup internet at all. Because the voice service comes from the ISP, they could not even bring in a redundant circuit: a second carrier cannot connect into the first carrier’s voice service.

The system fails from time to time, and when it does, everything is down. Voice and internet. They estimate that if their internet goes down on a Friday morning, it could cost them over $500,000 in top-line revenue.

We have proposed a solution with a one-time charge of $3,500 and monthly charges about the same as they pay today — including SD-WAN with redundant 5G/LTE service so the system does not fail. That is what bringing in an expert to review the current setup looks like: the fix for a half-million-dollar exposure costs less than a single bad morning.

A medical group whose PBX kept taking them down

We migrated a medical group from a premise-based PBX to hosted VoIP for exactly this reason. When the PBX got stuck or lost internet, their phones were down. Now there are multiple layers of redundancy. First the SD-WAN backup. And if something else fails — an electrical problem, a failed switch, or the main office itself going down — we reroute calls to the app on their smartphones.

One circuit carrying everything?Request an assessment

Six questions to ask before you need the answers

1. Show me the failover working. Not the diagram. Unplug the primary circuit and let me watch.
2. What happens to inbound calls during an outage — specifically, where do they go?
3. Who do I call at 9am when the phones are down, and who answers?
4. How many companies are involved in my phone service, and which one owns the outage?
5. What happens if the building is unavailable rather than the internet?
6. How do you find out my backup has failed, and how long before somebody looks at it?

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.

We offer an assessment. We will come out, look at what you have, and tell you what can be added to put a real disaster recovery plan in place. Often that means adding some level of failover now, along with a migration plan for when your current contracts come due — so you are protected today without walking away from an agreement early.

And we will do what this article tells you to ask for: show you the failover working. We bring an SD-WAN device, connect it to a switch and phones, and tie it into your primary internet service. Then we unplug the primary and you watch the calls stay up.

You will know whether you have a plan or an assumption.

Frequently asked questions