An answer needs a source
Imagine a customer asks whether a product will arrive on Friday. The assistant has a product description but cannot access the order status. A convincing reply could promise a date nobody has confirmed.
Design customer service around the information actually available. Decide what the assistant can consult, who maintains it and how often it changes. Opening hours might come from a public page. An answer about an order needs a different source and different permissions.
Prepare the content behind the conversation
Review common questions and approved answers. Resolve contradictions between pages about terms, availability or service steps. When an answer depends on a person, define how the question reaches them.
The assistant also needs a path for missing information. It can ask for a necessary detail, explain what it cannot confirm or prepare a handoff to the team. It should not fill the gap with a likely sounding statement.
Keep context during the handoff
A visitor who has already explained a problem should not have to start again. Offer a short summary, let them review it and use the agreed channel to continue. Share only the information needed and authorized for that request.
Keep separate states for summary prepared, request sent and team reply. Each state should correspond to something that actually happened. Clicking a button alone does not demonstrate that a person received the message.
To test the assistant, collect common queries, ambiguous questions and cases with no available answer. Check whether the content is correct, understandable and points to a suitable next step. Watch for questions people repeat after an answer; they may reveal unclear information.
Start with a short list of important questions. For each, write down its source, who updates it and the expected response when the information is missing. That preparation is useful for both a simple chatbot and an agent with tools.
