The instinct when configuring a robot is to make it answer as much as possible. The better instinct is to decide deliberately what it should not answer, because a robot that knows its boundaries is trusted more than one that attempts everything.
Topics that should always transfer
A default list, adjustable by sector.
Commitments. Prices agreed, delivery dates promised, discounts offered, exceptions granted. These may be read as binding, and the robot has no authority to make them.
Complaints. A dissatisfied customer talking to a machine becomes more dissatisfied. Detect and transfer immediately.
Professional advice. Medical, legal, financial. The highest-risk category by a wide margin.
Personal account information. Anything specific to an individual customer, unless there is proper authentication.
Safety-critical instructions. Where following wrong guidance could cause harm.
Anything about other customers. Even inadvertently.
Legal and contractual questions. Terms, liability, obligations.
Configure these as hard boundaries rather than as guidance the model may weigh. The distinction matters: a preference can be circumvented by persistent or cleverly phrased questioning; a hard boundary cannot.
Making refusal work well
How a robot declines determines whether it feels helpful or obstructive.
Acknowledge and redirect in one line. A brief statement that it does not have that information, followed immediately by a route forward.
Name the route. Not just that it cannot help but who can, and how to reach them.
Do not over-apologise. One short apology and a redirection. A sequence of apologies is worse than none.
Do not explain the limitation at length. Customers want the answer or the route to it, not an account of the robot's scope.
Make the handover easy. A visible button, a displayed number, or the robot notifying staff. Requiring the customer to find someone themselves defeats the purpose.
Ensure someone responds. A robot that summons help nobody provides is worse than a robot that simply says it cannot help.
Log it. Refusals are the best source of information about whether the boundaries are set sensibly.
Configuring boundaries so they hold
The technical side, in practical terms.
Hard rules, not soft guidance. Instructions that the model treats as preferences can be worked around. Rules enforced outside the model cannot.
Detect by topic, not by keyword. Keyword lists are easily evaded and produce false positives. Topic detection is more robust.
Prefer declining when uncertain. Many systems default toward producing an answer. That default should be reversed for anything near a boundary.
Detect sentiment as well as topic. A frustrated customer should be transferred regardless of what they are asking about.
Handle indirect approaches. Customers sometimes reach a restricted topic gradually rather than directly. Test for this deliberately.
Verify by attacking it. Have people inside the organisation attempt to elicit restricted answers, including through circuitous routes. Do this before customers do.
Re-test after every content update. Changes can weaken boundaries unintentionally.
Why refusal increases trust
The counter-intuitive part, and the reason to configure boundaries generously.
Customers can tell when an answer is confident but hollow. Not always, but often enough that it damages credibility across the whole interaction.
A clear boundary signals design. A robot that knows what it does not handle appears to have been built carefully, and that impression transfers to the answers it does give.
It prevents the worst outcome. A confidently wrong answer on a consequential topic is far more damaging than a refusal.
It sets expectations correctly. Customers learn quickly what to use it for and stop testing the edges.
It protects staff. They are not left dealing with the consequences of commitments the robot made.
Narrower is usually better. A robot answering thirty questions well is more useful than one attempting three hundred and getting a portion of them wrong — because the second one cannot be trusted on any of them.
Reviewing the boundaries over time
Boundaries set at launch should not stay fixed.
Watch the refusal log. If a topic is refused frequently and it is genuinely within scope, it should be added to the content rather than left as a refusal.
Watch the transfer rate. Very high means the boundaries are too tight or the content too thin. Very low may mean the robot is answering things it should transfer.
Ask staff what they receive. If they are constantly handling questions the robot should manage, adjust. If they are receiving nothing, check whether the robot is overreaching.
Reassess after any change in the business. New products, new policies, new regulatory requirements.
Tighten after an incident. If something went wrong, the boundary in that area needs revisiting rather than only the content.
Document the reasoning. Why each boundary exists, so the next person configuring the system does not remove it as an apparent restriction with no purpose.
Frequently asked questions
Which topics should always transfer to a person?
Commitments on price or delivery, complaints, professional advice in medical, legal or financial areas, personal account information, safety-critical instructions, and anything concerning other customers.
Why must boundaries be hard rules rather than guidance?
Because instructions treated as preferences can be worked around by persistent or cleverly phrased questioning. Rules enforced outside the model cannot be, and that difference is what makes a boundary reliable.
Why does refusing increase trust?
Because a clear boundary signals that the system was designed carefully, and that impression transfers to the answers it does give. A robot answering thirty questions well is more useful than one attempting three hundred unreliably.
What does a very high transfer rate indicate?
Either boundaries set too tightly or content that is too thin. The refusal log shows which — a topic refused frequently that is genuinely in scope should be added to the content instead.
More in Robots in Vietnamese business and Myths and questions.
