Summary: If your missed-call system texts every caller, some of those callers are on landlines. The message is accepted, your logs record a success, and nothing reaches the customer. Nobody investigates, because from the inside it looks like the system is working perfectly. The fix is a line-type lookup before sending, costing a fraction of a cent per check, plus a different path for landlines.
Why this one is worse than an outage
An outage is loud. Something errors, an alert fires, you fix it. The bug is expensive for an hour and then it is over.
Silent success is quiet forever. You promise a reply within five minutes. A customer calls, you miss it, your system fires a text, the API returns an accepted status, and your dashboard records the promise kept. The customer sits there having heard nothing at all and calls the next business on the list.
You will never audit this, because you have no signal that anything went wrong. Every metric you look at says you are doing great.
What actually happens when you text a landline
The important distinction is between accepted and delivered. When a messaging API returns a success, it usually means the message was accepted for delivery, not that a handset displayed it. Those are different claims and only one of them is about your customer.
Send to a landline and the outcomes vary by carrier. Some landline carriers support a text-to-speech service that will call the number and read the message aloud. Many simply discard it. A few return a delivery failure late, long after your system has moved on and recorded the send.
The practical consequence for a small business is that the behaviour is inconsistent and mostly invisible. You cannot design around “it depends on their carrier.” You have to know the line type before you send.
Who is actually calling from a landline
It is easy to assume landlines are extinct. In the context of inbound service calls they are not, and the callers who use them are often the ones worth the most.
Property managers calling from an office. A receptionist at a business that needs a commercial HVAC repair. An older homeowner who has kept the same number for thirty years. A front desk at a clinic. These are not fringe cases, and a commercial account calling from a main line is frequently a larger job than a homeowner calling from a mobile.
I am not going to quote you a percentage, because I have not measured one and neither has anyone else quoting one at you. The right move is not to estimate the rate. It is to check every number, because the check is cheap enough that the rate does not matter.
The fix: check before you send
A carrier lookup returns the line type for a number: mobile, landline, or VoIP. Twilio Lookup is the common option and the line type check costs roughly half a cent per query. Verify current pricing before you build a budget on it, but the order of magnitude is what matters: it is small enough that checking every inbound number is not a real cost.
Then route on the answer:
| Line type | What to do |
|---|---|
| Mobile | Send the text. This is the normal path. |
| Landline | Do not text. Fire an immediate high-priority alert to a human for callback. |
| VoIP | Attempt the text, and fall back to a human alert if delivery fails. VoIP is genuinely mixed: some receive SMS perfectly, some never will. |
Check at send time, not once. Numbers get ported between carriers and between line types. A result cached a year ago is a guess wearing a fact's clothing.
Why not just auto-dial them back?
It is technically straightforward. You can have a system call the number back and play a recorded prompt that connects them to you when they press a key. That would satisfy a five-minute response promise on a landline outright.
I would not start there, for three reasons.
First, it is a recorded automated outbound call, which sits in a meaningfully different regulatory category than replying by text to someone who just contacted you. If you go this route, get advice on it rather than reasoning from a blog post, including this one.
Second, it only works if the owner is actually available when the caller presses the key. A callback that connects to another ringing voicemail is worse than the alert, because now you have used up the customer's patience twice.
Third, you do not know yet how often it would fire. Ship the flag-and-escalate version, watch the real logs for a few months, and find out whether landlines are two percent of your calls or twenty. Then decide with data instead of building for a case you have not measured.
The general lesson
This is one instance of a pattern worth internalising: the failure modes that survive longest are the ones that report success.
When you build or buy any automated follow-up, ask what the system does when the thing it is trying to do is impossible. Does it tell you, or does it log a success and move on? A vendor who cannot answer that question has not thought about it, which means their system does the second one.
If you take one operational habit from this: make sure at least one of your alerts is on the absence of something rather than the presence of an error. A system that only alarms when it throws an exception cannot tell you about the message that was cheerfully accepted and quietly binned.