What happens now when a transfer fails

• The problem: a failed transfer got an apology, and nothing else
• What we wanted: the AI to get a name and callback number automatically, without the caller having to offer them first
• What was in the way: we already had a way to save that information — the AI just was never told to use it at this moment
• The fix: one new instruction, added to the same script every client's AI follows
• Still open: we haven't pushed it live or tested it on a real call yet

In the last post, we fixed why transfers to a real person kept failing. But every one of those failed calls ended the same way, no matter what the caller was asking about — a pricing question, or something urgent:

The AI offered to take a message. Nobody followed up when the caller didn't hand over their number unprompted. That's where the last post left it.

Simple bar again: if a transfer fails, the caller should not be able to just say "okay, thanks" and hang up with nothing captured. The AI should get a name and a number to call back, every time, without waiting for the caller to volunteer it.

The tool for this already existed. The AI saves the caller's details as a lead throughout the whole call — the moment it connects, not just when someone books — using a function called save_lead. It's silent, it's safe to call more than once, and it was sitting right there the entire time those five transfers were failing.

Nobody had told the AI to reach for it the moment a transfer came back failed. So it didn't. It offered once, in words, and treated that offer as the end of its job.

One new instruction, added to the same script every client's AI follows for every call:

If transfer_to_staff fails, do not just apologize and ask what else you can do — capture a callback. Ask for their name if not already confirmed, get and confirm a callback number per Speech formatting, and note why they called if that isn't already established, then call save_lead with status "callback_requested". If they brush off the offer, ask once more before letting the call end.

The apology stays — but now it's the start of a required next step, not the end of the conversation. And if the caller brushes off the offer, the AI is told to ask once more before letting the call end — the same two-tries pattern we already use when someone has an urgent, same-day request.

This had to go in the instructions the AI reads on every call, not in the code that logs a failure after the fact — that part already existed, it's how we found and quoted every transcript in the last post, but it only runs once the call is already over. It can't change what the AI does while the caller is still on the phone. Because the instruction lives in the one script every client's AI shares, this fix reaches every deployment the moment it's turned on — not just the one where we found the gap.

Every claim in the last post was backed by a real call — five failures, then a clean transfer on the retest. This one isn't there yet. The instruction is written, and we've got an automatic check in place that fails loudly if anyone ever removes it by accident. What we haven't done is turn it on for a real client and place a call where the transfer fails on purpose, to watch whether the AI actually asks for a callback number instead of just apologizing.

We're publishing it at this stage anyway, same as last time — a fix nobody's tested with a real call is still just a claim, not a result, and we'd rather say that plainly than wait until it's convenient to leave out.

• Logging a failure after the call ends and fixing it while the caller is still on the line are two different problems. One doesn't solve the other.
• Having a tool available isn't the same as telling the AI to use it at the exact moment it matters.
• The same "ask twice before giving up" pattern is worth reusing anywhere a caller might wave off something that's actually in their interest — not just the one place it was first written.