The instinct when configuring an AI phone agent is to make it handle as much as possible. Transfers feel like failures, so you write instructions that push the agent to keep trying.
That is backwards. A transfer at second thirty is a good outcome. A transfer at minute four, after the caller has explained themselves twice, is the failure — and it costs you 23 cents a minute to produce.
Four signals worth transferring on
The caller has asked for a person. Once, plainly, without hedging. Not "is there anyone else there" as an aside — an actual request. Instruct the agent to transfer on the first clear ask rather than to offer help once more. The second offer reads as stalling, because it is.
The question needs your records. Our agent has no CRM, no calendar, no order lookup, and no way to identify who is calling. It knows what you wrote down and what it can search. Anything shaped like "what's the status of my…" or "when is my appointment" is unanswerable, and the agent should say so and hand over rather than improvise around it.
The caller is upset. This one is judgement rather than rule, and it is worth writing into the instructions anyway. An annoyed caller getting a competent machine is a worse experience than an annoyed caller getting a slightly slower person, and the gap widens with every turn.
The same ground has been covered twice. If the agent has already answered and the caller is asking again, the answer is not landing. A third attempt at the same sentence is not going to be the one that works.
The signal people over-weight
"The agent does not know the answer" is the obvious transfer trigger and it is the least useful one, because it fires constantly at the start and then never again once your document collection is good.
The better instrument is whether the answer exists anywhere you have given it. If it does and the agent is not finding it, that is a documents problem, not a transfer problem, and transferring hides it. If it does not exist, transfer — and then write it down so it exists next time.
There is a hard ceiling here regardless: twenty completed searches in a single call, after which the agent hangs up. A model on its twentieth search is not converging on anything, and the ceiling is a cost control and a circuit breaker at once. If you see calls ending at that ceiling, your collection is missing something specific and the logs will not tell you what — you will have to ask a caller.
The five-minute cap changes the shape of this
The default maximum call length is five minutes; the hard ceiling any configuration can be set to is ten. A timer issues a real hangup. It does not fade out or apologise.
So the transfer decision has a deadline attached, and instructions that encourage persistence are instructions that walk callers into a cut-off. If your calls genuinely need six minutes, either raise the cap or plan for the transfer to happen early — but do not leave a five-minute cap in place and also tell the agent to keep trying.
For a booking or an opening-hours line, five minutes is generous and this never comes up. For anything where the caller describes a problem before you can help, assume the agent's job is triage and hand-off rather than resolution.
Why the agent cannot choose who it transfers to
There is one transfer destination, set in server configuration by an owner or admin, in international format. The model is told to use it. It is never asked to pick one.
This looks like a missing feature and it is a security property. A model that can choose a forwarding number is a model that can be talked into choosing a different forwarding number by a caller who wants it to: persuade the system to route a call somewhere, then answer that call yourself. Removing the choice removes the attack entirely rather than defending against it.
The practical consequence: if sales and support need different destinations, that is two numbers and two agents. Not one clever agent with routing logic. I would rather say that plainly than ship routing with a social-engineering hole in it.
Writing the instruction
Keep it short and make the transfer condition unambiguous. Something in the shape of:
Transfer immediately if the caller asks for a person, asks about their own account, order or booking, or if you have already answered their question once and they are asking again. Say you are putting them through, then transfer. Do not offer to help again first.
The last sentence does the most work. Without it, models reliably make one more offer of help, which is the behaviour that annoys people.
What to check after a week
You have no transcripts to review — no recordings, no caller numbers, nothing but a content-free journal row per call: status, duration, turn count, search count, pricing version, cost estimate, deleted after thirty days. That is a deliberate privacy decision and it means this section is shorter than it would otherwise be.
What the rows still tell you:
- Calls ending at the length cap. Either the cap is too low or the instructions are too persistent.
- Calls ending at the search ceiling. Your document collection has a hole.
- Very short calls in volume. Callers are hanging up. Usually the greeting, occasionally the voice.
- Duration creeping up week over week. The agent is working harder for the same outcomes.
Beyond that you are asking the person on the other end of the transfer number what the calls were like, which is a slower instrument but a better one than most dashboards.
Status
Osokoro Phone is a private beta, approved by a person, one business at a time. Inbound only — the agent answers and never dials. Numbers are provisioned by an operator, the rate is proposed rather than a billing commitment, and production metering is still gated.