Define authorised answers and actions
Looking up information, drafting a reply and changing an order have different consequences. Describe the authorisation for each action and what still requires confirmation. In customer service, this distinction enables timely help without confusing an assistant’s suggestion with a decision actually made and recorded by the business in its operating systems.
Begin with the work you want to delegate and list the access required to perform it. An opportunity summary may need to consult particular fields without changing prices or exporting every contact. Restricting access to the purpose reduces the gap between the business request and what the integration is technically able to do.
Instructions to the model should be accompanied by permissions and checks in the application. Writing that an action is prohibited does not replace restricting the tool that performs it. Ask the technical team to demonstrate the effective limits with authorised cases and cases that should be refused by the system.
Also define what counts as approval. Approving a specific draft for one recipient should not become permanent permission for future messages. If the content, destination or commitment changes, the previous decision may no longer cover the action about to happen, even when it looks similar to an earlier task.
Transfer the case with enough context
A useful handover gives the responsible person the question, the details already confirmed and the reason the assistant should stop. Also define how the customer understands the next step. The transfer is incomplete if it merely ends the automated conversation, leaving the request without an owner, information or follow-up from the team.
Consider a request for information about corporate training received by a customer service assistant. In the training example, the assistant can organise the brief and explain the planned formats. An exception to commercial conditions may require a decision from the responsible person. Missing information and missing authority are different reasons to stop, and the message should make that distinction understandable.
When considering when automation needs AI and when rules are enough, separate interpretation from execution. The application can require mandatory fields before allowing an action. Necessary permissions and confirmations should be checked by the system executing it, rather than relying only on the model's written response.
When I made an assistant available to the public, people tried to obtain its instructions and internal information. That experience reinforces the need for boundaries around what the assistant can access and disclose. An insistent conversation does not create permission to provide information outside the legitimate request.
When handing over to the team, retain only the context required to resolve the matter. Explain what has already been asked and avoid promising a response deadline that has not been defined. If the system only prepares a draft handover, it should say so, without claiming that the message has already been delivered.
Protect each customer’s context
Customer service should confirm that the answer and data belong to the correct person and request. Test context identification, recipients and what the system can access. Internal organisation needs to prevent information crossing between customers, including when the team reuses response templates or resumes conversations that were previously left awaiting follow-up.
Look for signs of mixing that a superficial reading can miss. A report might name the correct client on its cover but mention another client's offer in the body. A recommendation might assume a budget from an earlier conversation. These errors require returning to the source, rather than simply replacing words in the result.
If you find information outside the scope, pause sharing and clarify how it entered the document. Identify the affected materials and involve the person responsible for the process. Correcting only the final sentence may leave the same source available to contaminate the next task performed in that context.
Maintain a delivery record that identifies the version and recipient. You do not need to copy sensitive data into that record: a reference to the file and project may suffice. The purpose is to verify what left the team and avoid sending an old version or an attachment from previous work.
When someone stops working with a client, the team should review permissions associated with their role. The same applies to tool connections that are no longer necessary. Assign responsibility for that review so the original organisation does not disappear gradually as projects grow and the people involved change.
Separating client data is a daily practice of defining scope, controlling access and checking deliveries. AI enters that process with the same boundaries the team needs to respect. Clearer boundaries make it easier to understand when a result is ready to leave the internal working context and reach its intended recipient.
Test clear, incomplete and conflicting questions
Build a case set representing real work: frequent questions, insufficient information, conflicting data and out-of-scope requests. Evaluate correctness, usefulness and handover as well as fluency. An assistant can write well and still create unnecessary work by requesting information already available or reaching a conclusion without a sufficient basis in the records.
You can start with different versions of the same brief. Remove the objective from one, change the delivery format in a second document for another, and supply all necessary information in a third. The test becomes clearer when you know exactly what changed and how that change should affect the response.
Assess the content, rather than merely looking for a cautious phrase. An assistant can state that it is uncertain and then invent the missing detail in the next sentence. It can also ask for clarification about something already explicit. Both cases require reviewing the instructions or the organisation of the context.
Save examples that reveal failures and reuse them after making changes. If a correction improves contradiction handling, check that it has not started blocking simple requests. The evaluation should consider the usefulness of the conversation and fidelity to the data, alongside the ability to stop.
Teaching this behaviour means defining, illustrating and testing instructions; it does not imply retraining the model or guarantee perfect compliance. Keep a review path for important cases and update examples when the process changes. The aim is to make gaps visible and manageable before they become unsupported decisions.
Maintain an exception queue that someone owns
Requests requiring human intervention need to remain visible, with an owner and an understandable status. Monitor handover reasons and repeated cases to distinguish legitimate uncertainty from a fixable information or process problem. This review helps improve service without increasing autonomy simply to reduce the number of transfers to the human team.
A useful alert explains which stage is pending and what prevents progress. It might require a category to be confirmed, a request clarified or an earlier message delivery checked. The recipient should recognise the required decision without reconstructing the entire route through several systems just to understand the problem.
Group exceptions by cause when that helps the work. If several cases fail because the same field is missing, improving collection may be more useful than treating each occurrence as an isolated problem. The owner uses the set of cases to understand where the underlying process needs to change.
Define urgent handling and cover during absences as well. An alert inbox nobody checks during holidays cannot fulfil its purpose. The process must remain understandable to a second person, with appropriate access and enough instructions to act without depending on the unavailable owner's memory of how the system works.
To discuss a solution, prepare anonymised question examples, the channels used and your current method for tracking unresolved cases. Connect the design to customer retention and experience and internal knowledge assistants when answers depend on company documentation. Introduce the challenge through the implementation form. The conversation aims to select a useful scope with a concrete way to verify answers and handover to the team.