Why we will never answer your phone, and what to use if calls are the problem

We are not going to answer your phone. Not as a later phase, not as an add-on, not if enough people ask. If most of your enquiries arrive as calls, this is the wrong tool and you should buy a different one. What follows is the reasoning, separated into the part that is ours and the part that belongs to the platforms.

Answering a call would not break the reply-only rule

The first constraint in this project is that no code path may originate a conversation. It is not a setting. It is held in place by no send accepting a raw destination: a send takes a branded target whose one constructor is named for the single caller allowed to mint it, and the guard in front of it accepts only a conversation with an open window. That is an unforgeable type plus a loud convention rather than an impossibility, so an originating send would have to be written deliberately.

A phone call is started by the caller. So picking one up would not violate that rule, and it is worth saying so plainly rather than hiding behind the architecture. The reply-only rule is not the objection we have.

The rules we do live inside are about permission, not medium, and both platforms write them down. Telegram’s introduction for developers:

Bots can’t start conversations with users. A user must either add them to a group or send them a message first.

Meta defines a window rather than a prohibition, and the window is opened by the customer:

When a WhatsApp user messages you or calls you, a 24-hour timer called a customer service window starts. If the user messages or calls you again before the timer expires, the timer resets to 24 hours.

Note that a call counts: Meta names messages and calls as equally window-opening. The WhatsApp Business Messaging Policy is blunt about the other direction, “You may only initiate conversations using an approved Message Template”, and Meta even documents a message type for moving a text conversation to voice, whose direction is worth reading twice: “Interactive voice call messages allow you to trigger a WhatsApp call from users.”

So the platform’s own sanctioned route to voice is a caller phoning a human. We think that human should be you.

What voice would actually require

This part is our engineering judgement, not a citation. A voice agent is not a text agent with a microphone attached. It needs a telephony leg, which means a number, a carrier relationship and a media path held open for the length of the call. It needs speech recognition on a line with a dog barking on it, and speech synthesis going the other way, both inside a turn-taking budget short enough that silence does not read as a dropped call. It needs interruption handling, because people talk over greetings. And it needs a position on recording, retention and consent, which varies by jurisdiction rather than by product.

Set that against the shape of a reply pipeline as this one is designed. A message arrives, it is queued, it is answered from the owner’s own notes, and the draft passes a guard before anything is sent. Every step may take time, and the guard is allowed to refuse outright. Delay is the cheapest resource text has: nobody is listening to silence, so a reply composed in four seconds reads the same as an instant one.

Voice removes exactly that. It replaces a queue you can inspect with a socket that has a deadline, and a draft you can reject with words already in somebody’s ear. There is no window to attach a call to and nothing to hold. Building it would mean a second runtime, a second failure model and a second compliance surface. Worse, it would mean a code path that can speak without anything having queued it, and the sentence we intend to keep forever is that nothing here messages anyone first. One narrow path out is auditable. Two is twice the surface for that claim to quietly stop being true.

Three failure modes text does not have

The caller cannot see what was understood. In a message thread, the customer reads the exact words that arrived and can correct them. On a call they hear an answer to a question they may not have asked. The repair is one line: Sorry, did you say fifteen or fifty? An agent that does not do that reliably has no visible failure, which is the worst kind.

Nothing can be reviewed before it lands. Our preference is for replies held until they pass a check, and we are not alone in it. Google moderates a review reply before it appears, and our guide to rejected replies quotes the field where it publishes the reason. A spoken sentence has no such stage. It is published by being said.

A handoff mid-call is worse than no answer. The design here answers only from what you wrote down and escalates when it is not sure, so handoffs are frequent and cheap: I will check and get back to you costs a customer nothing, because the question waits in your queue and you answer it. The identical behaviour on a call is hold music, or a transfer to a phone nobody is holding. What makes the text version safe is precisely what makes the voice version unusable.

If calls really are the problem

Then buy something built for calls. We are not going to name one. We have not tested any voice agent against real callers and we are not going to assert a recommendation on someone else’s account of their own client base.

What we can offer is the questions we would ask:

• What does it do when it does not know? Ask for a recording of that path, not a demo of the happy one.
• Does it book against the calendar you actually keep, or a copy of it?
• What happens when a transfer fails, and who hears what?
• Does the meter run during silence?
• Who owns the recording and the transcript, and how long is each kept?
• What does consent for recording require where you operate?

Two options are not software at all. The first is a human answering service. The second is to move the enquiry to text deliberately at the point of failure: a voicemail greeting or a profile link telling the caller the fastest route to an answer is a message. Google documents the attributes for this, and says that by implementing them, “businesses enable customers to contact them using WhatsApp or SMS”, which “allows merchants to open direct communication channels with users on GBP”. The caller then starts the conversation, which is the only way anything reply-only can work.

To be clear about our own state: no channel is connected here yet, and nothing on this site has answered a real customer.

The refusal next door

One fix for a missed call is to text the caller automatically. That is outbound: the business writes first, to someone who has not written. Meta puts the rule in one line, “Thus non-template messages can only be used to respond - not reach out - to users”, so on WhatsApp it is a pre-approved, billable template operation, and the reply-only constraint forbids it here whatever it costs. A companion guide compares answering services with message answering out of the vendors’ own pages, and covers that refusal too.

If you are choosing between tools that write on your behalf, what the category can and cannot do is a better question than which has the longest feature list.

The actual answer

If your customers phone you, this is not your product, and no future version of it will be. If they message you, that is the problem this is built for, and the reason we can promise a machine will never ring your customers is that we never built anything that can ring anyone.