A well-written answer can still be wrong. In retail support, that happens when AI explains an outdated policy, says a product is in stock without checking inventory or describes an order it has never looked up.
The starting point is to separate questions that can use approved content from questions that require a current lookup. This shapes the solution: the model helps interpret the request and communicate clearly, while operational systems provide the facts the answer needs.
Separate general information from transaction data
Usage instructions, materials, dimensions and approved policies can form a knowledge base. Give that content an owner, version history and an update process. An old public page or an isolated customer conversation should not automatically become store policy.
Availability, current prices, calculated delivery estimates and order progress are different. They can change and may depend on a particular variant, location or purchase. Copying them into a document and refreshing it occasionally may not provide the required accuracy.
List common questions and classify them into approved content, system lookup or human support. This helps identify a first use case without trying to automate every request at once. It also exposes questions for which the business does not yet have a reliable answer.
Give answers an identifiable source
An inventory lookup needs to identify the product and variant before asking the responsible system for data. An order lookup needs to find the correct purchase and verify that the requester is authorized to see it. An order number supplied in chat is not, by itself, proof of authorization.
Grounding is the technical term for using external sources to inform model responses. AI platforms document ways to query APIs or search services for relevant information. That connection alone does not establish whether a result is fresh, authorized or correctly interpreted.
Define what the integration may retrieve, which fields it returns and how the answer should use them. “Being picked” does not mean “dispatched,” and “listed in the catalog” does not mean “available to purchase.” Preserve the meaning of each state rather than allowing the assistant to turn it into a more reassuring message.
Use realistic examples to set response limits
Consider an illustrative question: a customer asks whether a black sneaker is available. Until the size is known, the system cannot identify the variant to check. The useful next response asks for the size instead of assuming availability because another size has stock.
In a second example, someone asks when an order will arrive. The system reports dispatch and an estimated delivery date. AI can explain that result and where it came from, but should not convert the estimate into a guarantee or invent an arrival time.
If the lookup fails, the response should explain that the information could not be confirmed at that moment and offer a next step. A short, accurate reply is preferable to a plausible promise that the support team will later have to withdraw.
Control freshness, permissions and data exposure
Different information needs different freshness rules. A commercial policy may remain valid until reviewed, while availability must reflect the operation's update frequency. If caching is used, define expiry and the cases that require a fresh lookup.
Access also needs to match the conversation. A public assistant can retrieve public product information, but purchase-specific data requires appropriate verification. Keep read-only queries separate from functions that modify orders, customer records or commercial terms.
Send the model only what the task requires. An order-progress question rarely needs the customer's entire account record. Review what is retained in conversation logs and who can access it. These controls are part of designing customer support, alongside the quality of its wording.
Make human handoff a useful part of the workflow
Some questions require judgment, negotiation or a business decision. An exception to commercial terms, conflicting system records or a complaint with insufficient information should not remain trapped in repetitive replies.
Define handoff reasons and give the receiving person a useful summary: the customer's request, verified information, the issue found and the action still needed. If the customer has already identified a product size or verified a purchase, support should not ask for everything again without a reason.
Handoff also needs to work when a customer simply asks for a person. Describe the next step according to the store's actual support process, without inventing immediate availability or opening hours. AI should support the operation that exists, not create an imaginary one.
Test accuracy with real customer questions
Start with representative conversations and define the expected outcome before assessing the assistant. Include straightforward requests, incomplete questions and cases where the right answer is to ask for clarification or hand the conversation over.
- A product with multiple options and an unavailable variant.
- A current policy alongside outdated content that must be ignored.
- An order with insufficient identification or unauthorized access.
- A failed lookup or information beyond its permitted freshness window.
- The distinction between an order received, picked and dispatched.
- A request for an exception and an explicit request for a person.
Check both the facts and the route the assistant took. Fluent language does not compensate for a wrong inventory balance or revealing another customer's purchase. Record failures with enough context to correct the source, integration or instruction responsible.
Start small and review outcomes
An initial project might answer questions about one product category and hand off anything requiring order access. Another could retrieve order progress after a defined verification step. The right scope depends on actual demand and the systems available.
Track inaccurate answers, failed queries, necessary handoffs and unresolved questions. Counting only automated conversations can conceal a service that produces plenty of replies but solves few problems.
AGTI develops systems and integrations around business processes. To assess AI support, bring your most frequent questions and identify where their answers live today. This helps define data sources, boundaries and a pilot the team can validate. Learn more at https://www.agti.eng.br/.
Technical reference on querying external sources: https://docs.cloud.google.com/gemini-enterprise-agent-platform/models/grounding/grounding-with-your-search-api.