Alert when the phones go quiet

Most monitoring is built to catch errors. A request fails, a server throws an exception, a webhook returns a 500, and someone gets an alert. That covers a lot. It misses the failure that hurts service businesses the most: the phone line that stops ringing and nobody notices.

We see this pattern on voice reception projects. The AI receptionist is working fine. Then something upstream changes. A carrier port finishes and the forwarding rule points at the old number. Someone on the client side edits the business hours in the phone system and accidentally sends daytime calls to a voicemail box. A billing card expires on the telephony account and inbound service gets suspended. A new office manager "cleans up" call routing and removes the step that sends overflow calls to the agent.

In every one of those cases, no error fires. The agent is healthy. The servers are healthy. The logs are clean, because there is nothing to log. Calls are going somewhere else, or nowhere at all, and the first signal is usually an owner asking why the schedule looks thin this week.

The fix is simple to describe and a little fiddly to build: alert on the absence of expected activity, the same way you would alert on an error.

Learn what normal sounds like first

You cannot alert on quiet until you know what normal volume looks like for that specific business. A plumbing shop and a dental office have very different shapes. So the first step is to pull a few weeks of call history and look at it by hour and by day of week.

Most service businesses have a pretty stable rhythm. Monday mornings are busy. Lunch dips. Late afternoon picks up again. Saturday is lighter, Sunday lighter still, and overnight is close to zero outside of emergency trades. Once you see that shape, you can set a reasonable expectation for each window.

We keep the rules plain. For each block of time, we write down how long it would be strange to go without a single inbound call. During a weekday morning for a busy shop, that might be an hour. On a slow Sunday afternoon, it might be most of the day. Overnight, we usually do not alert on quiet at all, because silence at 3 a.m. is normal for most clients.

A few things make these rules more accurate:

• Use the client's own history, not a guess or an industry average.
• Separate weekdays from weekends, since the rhythm is different.
• Account for holidays and known closures, so the system does not page someone on the day the office is shut.
• Revisit the thresholds after a busy season or a slow season, because volume shifts.
• Start loose. A rule that fires too often teaches people to ignore it, and then it is worse than no rule.

The goal is a check that only speaks up when something is actually off. One honest alert a month is far more useful than a daily alert people learn to swipe away.

Check the whole path, not one piece

Counting inbound calls is the first layer. It tells you the line went quiet. It does not tell you why, and it misses cases where calls still arrive but something after the call is broken.

So we watch the path end to end. For a typical voice reception setup, a caller dials the business number, the carrier routes it, the phone system forwards it to the agent, the agent handles the call, and then the result gets written somewhere useful: a booking in the scheduling tool, a lead in the CRM, a summary sent to the team. Every one of those steps can fail quietly.

For each step, we ask the same question: what should we expect to see, and how long can we go without seeing it?

• Calls answered by the agent compared with calls reaching the business number. If the carrier shows calls but the agent sees none, forwarding broke.
• Bookings or lead records created compared with calls that ended in a booking intent. If the agent keeps saying "you're all set" but nothing lands in the calendar, the integration broke.
• Summaries delivered to the team compared with calls completed. If the messages stop, the office is flying blind even though calls are being handled.
• Transfers to a person that actually connected. If every warm transfer rings out, the transfer number or the staff phone setup is wrong.

None of these checks need anything exotic. They are counts and timestamps compared on a schedule. The value comes from writing them down per client and pointing them at the right person.

We also place a test call on a schedule. A short automated call to the client's main number, during business hours, that confirms the call reaches the agent and the agent answers with the right greeting. This catches the cases where real traffic is too low to tell the difference between a slow afternoon and a broken line. It takes a few minutes to set up and it has caught more routing problems for us than any other single check.

Send the alert to someone who can act

An alert that goes to the wrong place is the same as no alert. Before turning any of this on, decide who receives each type of problem and what they are supposed to do.

Some problems belong to us as the builder. If the agent stops answering, or the booking integration starts failing, that is our job to fix, and our on call person gets it. Other problems belong to the client. If the carrier suspended service for a billing issue, or someone changed the routing inside their phone system, we can diagnose it, but the client usually has to make the change. Those alerts go to us first with a clear note, and we call the client contact with a specific ask.

Each alert should say what was expected, what was seen, and the first thing to check. "No calls answered since 10:12 a.m. on a weekday. Normal for this window is at least a few per hour. Last test call at 11:00 a.m. did not reach the agent. Check call forwarding on the main line." That is far more useful than "anomaly detected."

We also write a short runbook for each client that lists the usual suspects in order: forwarding rules, business hours settings, the telephony account status, the integration credentials, and the staff transfer numbers. When an alert fires, whoever picks it up works down that list. Most quiet line problems turn out to be one of the first two items, and they take minutes to fix once someone looks.

Why this matters more for small businesses

A large company with a call center has people watching queues all day. If volume drops, a supervisor notices within the hour. A five person service business does not have that. The owner is on a job site, the office manager is juggling three things, and the phones are supposed to just work.

That is exactly why an AI receptionist needs this kind of monitoring around it. The whole point of the system is that the business stops thinking about the phones. That only works if someone else is thinking about them, and the simplest version of that is a set of checks that notice when the phones go quiet and say so before the owner has to ask.

If you already run an AI receptionist, or any automated intake, a good first exercise is to ask: if this stopped working at 10 a.m. tomorrow, how would we find out, and how long would it take? If the honest answer is "when a customer complains" or "when the week looks slow," that is the gap to close first. It is usually a small build, and it protects everything else you spent time setting up.