Define the permitted answer scope
List the subjects the assistant may answer, the approved sources it may use and the decisions reserved for people. Make those boundaries specific to its job. A fictional internal service assistant might explain the published equipment-request process but leave exceptions to a manager. Avoid a vague instruction to answer everything confidently. Separate information from authority: locating a procedure does not authorise the assistant to approve a request. Give users a short description of what the assistant covers so they understand why some questions need another route.
Distinguish missing information from unclear intent
If the question could mean several things, ask a focused clarification before searching further or declining. If the request is clear but the approved material does not answer it, say what is missing. Do not make the user restate a clear question repeatedly. For example, an absent policy about a particular exception needs an owner to decide, not another rephrasing of the same search. Agree a limit on clarification attempts and offer a staff route when the conversation is not resolving the uncertainty.
Make the fallback informative
A useful fallback identifies the unsupported part without guessing its answer. It might say that the available procedure explains ordinary requests but does not cover the exception described. Include any supported information that still helps, while keeping the unresolved decision clear. Avoid wording that sounds like a refusal by the business when the actual issue is missing evidence. Do not promise a response time unless a staffed review process supports it. The next step should tell the user where the request goes and what information is needed.
Create a review task people can act on
Include the original question, relevant context, sources considered and the exact unresolved point. Assign the task to an approved role rather than a general inbox with no owner. Keep unnecessary personal information out of the task. The reviewer should be able to distinguish a knowledge gap, a conflicting instruction and a request outside the service scope. Record whether staff answered the individual question, updated an approved source or declined the request. Those are different outcomes and should not all appear as a generic completed item.
Test both refusal and useful answering
Prepare examples with supported answers, absent information, conflicting documents and ambiguous questions. Include a straightforward question that should not be escalated. A system that declines everything avoids some mistakes but fails its intended purpose. Review the answer and supporting material, not just whether a fallback phrase appears. Use independent reviewers where practical and record disagreements. Test the staff handoff as well: a sensible refusal with a broken review link still leaves the user without a usable next step.
Improve boundaries using reviewed cases
Review escalations for repeated missing material and unnecessary refusals. Read actual cases before expanding the answer scope. A low escalation count is not automatically good if unsupported answers are reaching users. Similarly, a high count may reflect a legitimate boundary rather than poor performance. Update approved information through its owner, then retest the original examples and nearby cases. Keep a record of why a boundary changed. The objective is useful supported answers with dependable review of the remainder, not the smallest possible number of handoffs.