What happens when AI does not know the answer?

It says so and hands off. That is the whole behaviour, and the reason it is worth a page of its own is that the alternative is the single most expensive failure an automated system can have.

Why a wrong answer beats a missed call in cost

A missed call is a lost opportunity. Unpleasant, measurable, and the person simply calls somebody else.

A confident wrong answer creates an expectation. Somebody has been told a unit is available, or a fee does not apply, or a repair is covered. They act on it. Undoing that costs a conversation your team did not plan for, and it damages trust in a way a missed call never does, because you did not just fail to help, you told them something untrue.

The three cases it treats differently

• A fact with no source: it says it will get the exact figure and brings in a person.
• A question outside its lane, such as anything touching a protected class: it routes to a person without attempting an answer.
• A decision that commits you, like waiving a fee or making an exception: it does not decide, it escalates.

These look similar from the outside and are different rules internally. The first is about sourcing, the second about scope, the third about authority.

What a good handoff looks like

Saying it cannot help is only half of it. A handoff that ends in a contact form has not really handed anything off.

On a call it is a warm transfer on the same line, with a spoken summary so the colleague arrives knowing what has already been discussed. In a thread it is a person joining the same conversation with the history attached. Either way the customer does not repeat themselves, which is the part that makes escalation feel like help rather than a restart.

Frustration and sensitive topics

Not knowing is not the only reason to hand over. It also detects frustration, disputes and legally sensitive topics and pulls a person in mid-conversation rather than pushing through a script.

Collections is the clearest example: the sequence pauses the moment somebody disputes a charge. Continuing to send reminders into a live dispute is how a small disagreement becomes a complaint.

Tuning the boundary

The first version will hand off more than it eventually needs to. That is the correct direction to be wrong in, and the weekly review is where it narrows: read what it escalated, decide which cases it should have handled, and give it the source it was missing.

Handoffs when nobody is there

The case that needs deciding before launch is the one where a handoff is the right answer and it is two in the morning.

There are only a few honest options, and the choice differs by situation. A genuine emergency pages your on-call contact, which is what the maintenance triage rules are for. Anything else is a commitment: somebody will come back on this, and a specific time is better than a vague soon. The record goes into your system so the morning starts with it rather than with somebody discovering it.

What does not work is leaving the person with nothing, or with an instruction to call back during office hours. They contacted you outside office hours because that is when they are available, and telling them to try again when they are at work is not a plan.

Not knowing is useful information

Every handoff for a missing fact is a signal about a gap in what the agent was given, and those gaps cluster in ways worth reading.

• A policy question asked repeatedly usually means the policy is not written down anywhere.
• A recurring pricing gap often means a rate sheet that is incomplete rather than a system problem.
• Questions about a specific property may mean its data was never fully set up.
• A pattern of escalations at one hour of the day may be a data refresh rather than a knowledge gap.

Reviewing those weekly is how a deployment improves. Most of the improvements are things your team also had to look up, which means the exercise tends to fix your documentation as well as your automation.