Giving an ecommerce chatbot the entire website and expecting it to answer everything is not a reliable service design. Product explanations, current stock and private order information require different sources and permissions. Requirements should first identify which source answers each question, then define which actions the assistant is actually authorised to perform.
Separate general knowledge from changing data
Product guidance, category explanations and opening hours can belong in an approved knowledge source. Stock, prices and promotional terms need a current operational source when they change. Presenting an old price as current can create a false expectation. Information must also match the correct product variant.
In a hypothetical furniture store, one product may have several sizes and finishes. After recognising the product family, the assistant should clarify the configuration being discussed. Applying one stock or delivery statement to every variant may be convenient but inaccurate.
Distinguish answering from taking action
Explaining a return process and opening a return request are different tasks. Viewing an order and changing its delivery address require different controls too. Define the information accessed, verification needed and explicit user confirmation for each operation.
| Task | Required source | Boundary |
|---|---|---|
| Product question | Approved product and variant information | Do not invent missing detail |
| Stock or price | Current commercial system | Do not present stale data as certain |
| Order status | Verified customer context | Do not reveal another person's record |
| Requested change | Authorised transaction system | Apply after required checks and confirmation |
| Exception | Relevant support owner | Transfer with context intact |
Design conversation that handles uncertainty
Product comparisons should use verified attributes and the customer's stated requirements. The assistant should not invent technical compatibility to provide a definitive recommendation. Where information is missing, it can offer the relevant page, verification route or human support. Answering every question is not a useful definition of reliability.
Summarise the relevant part of a policy instead of pasting the entire document, and link to the authoritative explanation where appropriate. Preserve conditions and exceptions when shortening the answer. Provide an escape from repeated, unhelpful responses when the customer needs more assistance.
Test requirements through realistic failure cases
Include misspelled products, unavailable variants, expired promotions, missing order context and interrupted connections. Failed-operation behaviour matters alongside successful conversations. If the assistant announces completion, the relevant system should confirm that the record or change actually exists.
Check how source updates reach responses. Support staff need a way to flag an incorrect answer, with an information owner responsible for correction. Report suitable tasks completed automatically, correct human handoffs and misinformation separately. Keeping someone in a long conversation is not itself a successful outcome.
- Does each answer type have an authoritative source?
- Are freshness and variant checked?
- Are private access and action permissions separate?
- Is there a route to correct a wrong response?