Escalation rules are written for a call centre you do not have

Short answer. The escalation rules everyone publishes assume a queue of agents. A company of fifteen has no queue. The receiver is one named person who may be in a meeting, asleep, or unable to read the language the enquiry arrived in. So the thing to design is what happens when there is nobody to hand off to.

Search for when an AI agent should escalate and you get ten good pages. They agree with each other, and they are right.

Then you try to build it and find the interesting part missing.

What does everyone say, and why is it not enough?

The triggers are settled, and I am not going to argue with them.

Open any vendor guide and the same list comes back:

• the customer asks for a person;
• the agent has failed twice running at the same thing;
• the request touches money, account changes or personal data;
• the tone turns while the problem stays open;
• the agent is uncertain and going in circles.

That list works. Take it as it stands.

Then the guides stop. None of them covers the sentence right after the trigger fires. They write "route to a human agent", "the appropriate queue", "an available human agent". Look at what all three assume: somewhere there is a pool of people whose job is to be available, and the only problem left is picking the right one.

That holds at a company with a support rota. It stops holding at fifteen people, and almost every company reading this has fifteen people.

Who is actually on the other end?

Not a support function. One or two people you know by name, and everything downstream follows from that.

At scale, "escalate to support" is a queue with a service level. At your size it is Ahmed, who is in a meeting until four, or you, at nine in the evening. Routing stops being "find a free agent" and becomes "find Ahmed, and if not Ahmed, then who".

Two things narrow the list further, and both are specific to operating here.

Start with language. An enquiry arrives in Arabic, English or Russian depending on who sent it, and the person who takes it over has to continue in that language. A pool of three drops to a pool of one.

Then the calendar. An earlier piece goes through why "after hours" is not one thing in the UAE: the law names no weekend for private companies, the federal government moved to a Monday-to-Friday week while much of the market did not, and Saudi buyers work Sunday to Thursday. Your escalation path inherits all of it.

So the receiver has three states rather than two: free and answering now, busy and answering later, unavailable and not answering at all. Most systems cannot tell the third from the second and carry on as though the person will reply. That is how enquiries die quietly, without a single error in the log.

What happens when there is nobody to take it?

Decide, before launch, which matters more for this kind of enquiry: not getting it wrong, or not losing it. The answer differs by type, and it has to be written down.

A dead end has three outcomes, and sorting your enquiry types into them is most of the work.

Hold and continue. The agent keeps the conversation going, says plainly that a person will pick it up and when, and collects everything that person will need. Use it where a delay costs little and a mistake costs a lot.

Proceed with a narrower promise. The agent finishes what it can and stops short of the part that needed a person, naming that part out loud. This works more often than you would think, because most enquiries contain a piece the agent can close without risk.

Refuse honestly. The agent says this needs somebody who is not here, and gives a real time. Money, legal questions and anything irreversible belong in this one.

A fourth option waits underneath, and a system falls into it on its own unless you say otherwise: promising a callback that nothing guarantees. Never do that.

Compare two buyers. One was told "someone will contact you shortly" and then heard nothing for two days. The other was told "not before Sunday morning", and spent those two days making other arrangements. Waiting cost the first one more than the honest refusal cost the second.

That is the same asymmetry as the after-hours piece above. The loss is not spread evenly across the week. It sits in the hours when the receiver is unavailable, and those hours are known in advance.

What has to travel with the enquiry?

Everything the person would otherwise ask again. One repeated question eats the benefit of everything the agent did before it.

Four things travel with the handoff:

1. What the customer wants, in their own words rather than as a classification.
2. What the agent established, and how sure it is of each part.
3. What the agent has already promised, so nobody contradicts it.
4. What it could not do, and why.

A summary beats a transcript. Handing a person twenty turns of conversation moves the reading work onto them without making it any smaller, and at a small company the receiver is doing this between two other things.

One thing does not travel automatically: anything the customer gave under an expectation about who would see it. If the agent collected an account number or a scan of a document to complete a task, forwarding that into a group chat for speed is a decision, not a default.

That third row is the one worth building first. It is the row every published guide leaves out, and it is where the enquiries go missing.

How do you know the rules are wrong?

Two numbers. Both come from your own logs over a week, and both are worth more than any threshold borrowed from somebody's guide.

The share of enquiries that escalate. This one is misread in both directions. Too high and the agent is doing nothing useful, which means fixing the design rather than the model. Too low is worse, because it usually means the agent is answering things it should not, and a customer notices before you do. No number here is the right one to aim at. You have a number. Ask whether you can defend each escalation behind it.

The share of escalations that never got answered. Nobody measures this one, and it matters more than the first. Count the handoffs where no person responded within the time the customer was given. If that share sits far from zero, the trigger list is fine, the receiving end is broken, and adding cleverer triggers will not help.

You may see a confidence threshold quoted as the answer, typically sixty to seventy percent. One of the ranking pages states exactly that, with no study, sample or source attached. It reads like somebody's default that the rest copied from each other. You can compute your own two numbers this week.

Our AI team is built around the third row: each agent has a defined procedure, a named person behind it, and an explicit answer for what happens when that person is not there. That last part is the one that takes the longest to set up and the one that decides whether any of it works after six in the evening.