Quick answerYes, but only when the customer states it as a standing rule, not just as an escalation in one conversation. Store it as a durable account level preference, separate from a single conversation's escalation flag, and re-apply it automatically at the start of every future session without making the customer ask again. Give the customer an easy, visible way to see the preference is active and to turn it off, since a preference that silently persists forever without any visibility starts to feel less like a courtesy and more like a trap.
Why a one-off escalation and a standing preference are different data
When a customer asks to speak to a human in the middle of a conversation, that is a signal about this conversation. The agent should honor it immediately and completely, the way any well designed sentiment aware escalation path works. But nothing about that single request tells you whether the customer wants the same treatment next month, for an entirely unrelated question. Treating a one-time escalation as a lifetime preference is a mapping error, and it is surprisingly easy to make if your system stores escalation events and routing preferences in the same table with the same shape.
What actually counts as a standing request
A customer has to say something closer to an explicit rule for it to count: always send me to a person, I do not want to deal with the bot anymore, stop having the AI answer my questions. That is qualitatively different from being upset about one bad answer. The safest implementation treats a standing preference as an opt in that requires unambiguous language, confirmed back to the customer in plain terms, rather than an inference the system makes on its own after two or three heated conversations. Inferring the preference from behavior alone risks locking a customer out of a channel they would have used again for a simple question.
Where the preference has to live and how far it has to travel
This only works if the preference is attached to the customer's identity, not to a device, a channel, or a single conversation thread. A customer who set the preference on chat and then calls in on the phone should get the same treatment, which means the storage layer has to be the same account level memory that already needs to survive a channel switch mid-conversation, just applied at session start instead of mid session. If your memory and personalization layer was built or bought specifically to solve short term context continuity, confirm it was designed to persist an indefinite, low frequency flag like this one, since some memory systems are tuned to decay context quickly and were never meant to hold a rule that has to survive for years.
From the team
We build production AI systems for startups.
LLM pipelines, RAG, and agent workflows that hold up under real traffic — not just in the demo.
Designing the override and the exit
A standing preference should not be a one way door. Give the customer a simple way to see the preference is on, ideally surfaced the first time they land back in a channel where it applies, and a simple way to turn it off if their situation changes, for example if the reason they wanted a human no longer applies. Also decide explicitly what happens when no human is available. Silently falling back to the agent defeats the entire point of the preference, and a customer who set the rule specifically because they were frustrated should not discover the exception during their next bad day. A visible queue message that is honest about wait time is better than a quiet policy violation.
How this interacts with pattern recognition you may already be doing
Some teams already track repeat contact patterns across sessions to flag customers who keep coming back with the same unresolved issue. A standing human routing preference is a related but distinct signal: pattern recognition is something your system infers about a customer's behavior, while a routing preference is something the customer explicitly told you. Keep the two systems separate in your data model even if they end up triggering similar downstream behavior, because conflating an inferred pattern with an explicit instruction makes it much harder to explain to the customer, or to a regulator, exactly why they were routed the way they were.
FAQ
Does honoring this preference forever create a support cost problem?
It can, which is exactly why the opt in language matters. A preference triggered by clear, deliberate customer language is a small population by definition. A preference inferred from mild frustration would capture a much larger population and could meaningfully shift your human agent staffing needs, so keep the bar for triggering it high.
Should the preference expire automatically?
Most teams do not expire it automatically, since an unprompted expiration reintroduces the AI agent to someone who explicitly asked to avoid it, which reads as broken trust rather than a helpful reset. A better pattern is a periodic, low friction check in, framed as a courtesy rather than an assumption that the preference has lapsed.