The failure nobody plans for
Continuity planning in service businesses is almost always about demand. What happens when a freeze triples the call volume, what happens after a storm, what happens in peak season. That is a real problem and it has its own playbook — the storm and freeze call-surge playbook covers it.
This is the other one. Not too many callers — no capacity to answer. The office loses power. The fibre is cut by a contractor two streets away. The VoIP provider has a bad hour. The dispatcher is off sick and the backup is on a roof. The owner's mobile, which is the last hop in the forwarding chain, has a voicemail box that has been full since spring.
As of September 2026, the striking thing about this class of failure is how quietly it happens. Nobody rings to tell you your phones are down; they ring, get nothing, and call the next company. From inside the business it looks like a slow day. The revenue is simply absent, and it never shows up in any report as a loss because the calls were never recorded.
This guide is about the specific ways your own answering capacity fails, what the caller experiences in each case, and how to find out whether your chain actually works before you need it to. The operational system referenced throughout is Run with Jarvis, whose control layer is described in the Jarvis AI Brain overview.
The failure modes, ranked by how often they actually happen
Ranked by real-world frequency rather than by how dramatic they sound.
1. Nobody available. By a wide margin the most common. Every technician is on a job, the office person is at lunch or off sick, and three calls come in at once. No equipment failed. The effect on the caller is identical to an outage.
2. A full or misconfigured voicemail box. The chain runs to its end and lands on a mailbox that cannot take a message, or one nobody checks. This is the failure that most often masquerades as working, because every layer above it reports success.
3. Office internet down. A cut line, a failed router, a provider fault, or an ISP outage affecting the street. If the phone system depends on that connection, it is gone.
4. Office power cut. Kills the router, the switch and any on-premise phone system together. Frequently accompanied by a storm, which means simultaneous demand spike and capacity loss.
5. A wrong forwarding rule. Somebody changed a setting for a holiday, a one-off, or a test, and it was never changed back. Silent, indefinite, and invisible until somebody dials in from outside.
6. A dead or silenced mobile. The last hop is a handset that is flat, in a van cab, or on do-not-disturb.
7. Carrier or platform outage. Genuinely out of your hands, usually short, and the only one where the answer is a second destination rather than better configuration.
Notice the shape of that list. The top two are not technology failures at all, and the most damaging characteristic of both is that they look fine from the inside.
Where your number is answered decides almost everything
This is the single structural fact that determines how badly each failure hurts.
If your business number terminates on equipment in your building — a phone system, a box in a cupboard, handsets that register to it — then your building is a single point of failure for your revenue. Power cut, router failure, cut line: the call has nowhere to go, because the thing meant to answer it is dark. Callers get a fast busy, or ringing with no answer, or a dead line.
If your number is answered in the cloud, before anything of yours is involved, then a power cut in your office is invisible to the caller. The call is already answered; where it goes next is a routing decision that can be changed from a phone. The building being dark stops being an outage and becomes an inconvenience.
That distinction is why an AI receptionist changes the profile of this problem rather than just adding a feature. The answering does not depend on your power, your internet, your handsets or your staff being free — which addresses failure modes one through six on the list above, the entire top of the distribution. What it does not address is failure mode seven: if the carrier or the platform itself is down, you need a second destination, and the continuity sheet should name one.
This is also where a single integrated stack differs from an assembly of separate tools. When answering, booking, dispatch and messaging are one system, a routing change is one change; when they are four subscriptions with four logins, the outage is when you discover which of them you cannot get into. That trade-off is worked through more generally in the all-in-one versus point solutions comparison.
The forwarding chain, and the dead end at its end
Nearly every service business has a chain. The main number rings the office, then a manager's mobile, then an owner's mobile, then something.
That "then something" is where the money goes.
The pattern is almost comically consistent. Each hop rings for a set number of seconds and moves on, which looks like resilience. The last hop is a personal mobile whose voicemail box has been full for a long time — and a full mailbox answers. It picks up, plays a recording saying the mailbox is full, and hangs up. From the system's point of view the call was answered successfully. From the caller's point of view they reached a wall after ninety seconds of ringing.
The related trap is a carrier voicemail that answers instantly because the handset is switched off or in do-not-disturb. The chain never even gets to its later hops; the second one swallows the call in two seconds.
Three practical rules follow.
Keep the last mailbox empty. This is unglamorous and it is the highest-value maintenance task on this list. A full mailbox at the end of a chain silently converts every escalated call into a lost one.
Know how long the whole chain takes. Three hops at twenty seconds each is a minute of ringing before anything happens. Very few stressed customers wait that long, and the abandon dynamics are worked through in the call abandon rate and ring time guide.
Decide what the end of the chain is for. A voicemail nobody checks is not a destination, it is a bin. Either the last hop reaches something that reliably captures the caller's details and reason, or the chain should be shorter and end sooner in something that does.
Test it, because nobody has
Here is an uncomfortable exercise that takes fifteen minutes and reliably finds something broken.
From a phone that is not on your account, and outside your building, dial your main published number. Do not answer it anywhere. Let it run to the very end of the chain without intervening.
Write down what happens. How many seconds before anything answers. What you hear at each transition. Where it ends. Whether you could leave a message. Whether anything on your side records that the call happened at all.
Then repeat for every number you publish. The main line is usually the one people check; the tracking numbers on your website, your vehicle wraps, your ads and your Google Business Profile are usually the ones nobody has dialled in a year. A tracking number whose forwarding broke is a marketing channel that has been silently dead, and the spend continued.
Then do two more tests. Text each number and see whether the message reaches anyone — texts to business lines are frequently routed nowhere, and customers increasingly reply to a call with a text. And check that a missed call produces a record: if a call that nobody answered leaves no trace anywhere, you cannot recover it and you cannot count it. The recovery side of that is in the missed-call text-back guide.
Most businesses discover at least one of: a full mailbox, a stale forwarding rule, a tracking number going nowhere, texts landing in a void, or a chain so long no real customer would survive it.
| Failure | What the caller gets | Does cloud answering help? | The actual fix |
|---|---|---|---|
| Nobody free to answer | Ringing, then voicemail or nothing | Yes — answering is independent of staff | Something that answers every call, always |
| Full mailbox at chain end | "Mailbox is full", then disconnect | Partly — it removes the dependence on that hop | Empty the box; end the chain somewhere real |
| Office internet down | Dead line or endless ring | Yes — the call is answered before your network | Cloud answering plus a named second destination |
| Office power cut | Dead line | Yes | Same, plus a printed continuity sheet |
| Stale forwarding rule | Rings the wrong place, or nowhere | No — configuration is still configuration | Dial-in testing on a schedule |
| Mobile off or flat | Instant voicemail, chain skipped | Yes — the chain is no longer the front door | Do not make a handset the front door |
| Carrier or platform outage | Varies, often a network message | No | A second destination, decided in advance |
What the customer experiences, and why it is worse than you think
From inside a business, a missed call feels like a delay. From outside, it reads as closed.
A customer with a problem urgent enough to phone about is generally working a list. They call, get nothing, and call the next result. They do not try again later, and they do not leave a message on a mailbox that sounded full — and the specific texture of what they heard matters, because "ninety seconds of ringing then a disconnect" reads as a dead company in a way that a prompt answer with an honest "the earliest we can be there is tomorrow morning" does not.
That asymmetry is the whole argument for answering rather than queuing. A caller who gets a real answer and an honest constraint frequently books anyway, or accepts a callback with their details captured. A caller who gets silence is gone, and the only evidence is an absence in a report nobody is reading.
Out-of-hours makes it sharper still, because the expectation gap is wider: a caller at 8 PM who reaches something competent is pleasantly surprised, and one who reaches a recording assumes you are a daytime-only operation. The after-hours calls playbook deals with that window specifically.
The one-page continuity sheet
When the office is dark, documents in cloud drives are unreachable and nobody remembers the carrier login. One printed page, somewhere findable, in a vehicle and in a wallet.
It should contain: the carrier support number and the account number or PIN they will demand before discussing anything; where forwarding is changed and who holds that login; the failover destinations in order, with the actual phone numbers written out; a list of every published number with what each one is for, marking which are tracking numbers and which is the main line customers know; and a one-line description of who does what — who changes the routing, who tells the team, who posts a notice if it will be long.
Two additions earn their space. A note of which numbers are load-bearing for advertising, because if you have to prioritise restoring one thing, it is whichever number is on the live campaigns. And a line for the last date the chain was tested, which is the only way a quarterly test actually happens.
Number portability and carrier obligations are regulated, and the authority on those rules is the Federal Communications Commission at fcc.gov — worth knowing exists before a dispute, though the day-to-day questions go to your carrier.
Detecting the partial failure
The total outage announces itself. The dangerous one is partial, because it looks like a slow week.
One line broken while the others work. A forwarding rule that sends one number to a handset nobody carries. Texts silently not delivering. A tracking number dead while the main line is fine. All of those produce a reduced call count and no alarm.
The cheapest detector is a daily call count compared against the same weekday. Not a sophisticated dashboard — a number you look at. Tuesdays that normally run twenty calls and today ran four is a signal worth two minutes of checking, and it arrives days before anyone would otherwise notice. What to watch and what a sane baseline looks like is covered in the service business KPIs guide.
The second detector is per-line volume, because it distinguishes "business is slow" from "one channel is broken". If the main line is normal and three tracking numbers went to zero on the same day, that is not the market — that is configuration.
What to automate, what to keep human
Automate the answering, the capture, the record and the alerting. Every call answered and logged regardless of who is free; every missed call producing a record and a text back; every day's volume compared to a baseline without anybody running a report.
Keep human the decisions an outage actually requires: whether to reroute and where, whether to tell customers, whether to pull a technician in to cover dispatch, and when to escalate to the carrier. Those depend on how long it will last and what else is happening that day, and no system should be choosing them.
The general rule holds here as elsewhere: automate the things that fail because a person was busy, and keep the things that fail because nobody thought about them.
Where to start
Do the test. Today, from an outside phone, on every published number, letting each one run to its end without intervening. That single exercise finds more lost revenue than any planning session, because it converts an assumption into an observation.
Then empty the last mailbox in the chain, fix whatever the test found, and write the one-page sheet while the details are in front of you.
Then close the structural gap: move answering off equipment and staff availability so that the top six failure modes stop reaching the caller at all, keep a named second destination for the seventh, and put a daily call count somewhere you will actually see it.
Plans and minutes are on the pricing page — three flat monthly tiers, no setup fee, month-to-month. If you would rather walk your own chain through with someone, get in touch.
