Yes, a warm transfer on the same call, with a spoken summary so nobody repeats themselves.
Published September 11, 2026
Yes, and how well this works is probably the best single test of whether an automated system is any good, because it is where most of them fail and where customers form their opinion.
A blind transfer drops the caller onto a colleague who knows nothing, so the caller explains everything again. That is worse than not automating at all, because the person has now spent their time twice and been given a reason to distrust the first half of it.
A warm transfer brings your team member onto the same call with a spoken summary first: who is calling, what they want, what has already been said and what was promised. The colleague arrives informed, and the caller carries on from where they were rather than starting over.
On text, WhatsApp or email, a handoff means a person joins the existing conversation with the full history attached. It does not mean a new thread from a different number, which reads to the customer as being passed around a company that is not paying attention.
Because the conversation is stored against the person rather than the channel, the colleague can also see what happened elsewhere. Somebody who reported a leak by text on Tuesday and is calling on Thursday does not have to explain the leak again.
The first item is the one worth insisting on. A system that tries to talk somebody out of reaching a human, or that buries the option behind three more questions, will generate more complaints than it prevents.
This is where the design has to be honest. At two in the morning there may be nobody to transfer to, and pretending otherwise produces a worse experience than admitting it.
So the rules differ by time and by category. A maintenance emergency pages your on-call contact, because that is what on-call is for. A leasing question at the same hour is answered, logged and flagged for the morning, with the caller told clearly when somebody will be in touch rather than left guessing.
The transfer is not finished when the colleague picks up. The record should show that an escalation happened, why, and what the outcome was, so the weekly review can tell the difference between a rule working correctly and a gap that keeps producing escalations.
Over time that record is the most useful thing the system produces, because it is a list of exactly where the automation ends. That tells you what to fix, what to accept, and what genuinely requires a person.
During the build, call in and ask for a person. Then call in and ask something it cannot answer. What happens in those two calls tells you more about the product than any demonstration of it answering well.
Worth deciding deliberately rather than defaulting to whoever is nearest the phone. A maintenance emergency and an unhappy resident need different people, and routing both to the same place wastes one of them.
Most operators end up with a short routing table: emergencies to the on-call contact, anything about an account to whoever handles accounts, anything about a specific unit to the agent who owns it, and everything else to the desk. That is a fifteen minute conversation during the build and it prevents a category of frustration later.
It also gives you something to check in the weekly review. If escalations are consistently reaching the wrong person, that is a routing problem rather than a script problem, and the two get confused easily when all you see is that somebody complained.
On the site
Keep reading