A support assistant can explain how orders work from an AI knowledge base. To confirm what happened to a particular customer's order, it needs an authorized view of the order system. To change that order, it needs a permitted operation and evidence that the operation succeeded.
Those requirements can sit behind the same chat window. They should be separate in the project brief.
For a startup adding AI support, this distinction determines more than the choice of model. It shapes the integrations, account access, maintenance and customer promises the team will have to support. Uploading more documents cannot fill every gap, because some answers depend on records that belong in the business software.
Read the verbs in the customer’s request
“Explain your delivery options” asks for general information. An approved help article can describe service levels, exclusions and the steps a customer should expect. The assistant needs to find the relevant material and explain it without dropping the conditions.
“Where is my order?” asks for the state of a specific record. A guide describing delivery options cannot establish whether that order has been packed, dispatched or delayed. The assistant needs the right order, the customer's right to see it and a trustworthy status from the system that manages it.
“Change my delivery address” asks for a transaction. Reading the order is only the beginning. The system must decide whether an address change is still allowed, accept the new details and confirm the result. A fluent message saying the address has changed does not make the change real.
These example questions are deliberately ordinary. They show why a single label such as “AI chatbot with company data” is too broad to define a working product. Each verb adds a different responsibility: explain, inspect or change.
A small business can reasonably launch with only the first responsibility. It should describe the assistant as a source of guidance and provide a clear route to staff for account-specific help. That is a useful scope when it matches the intended service.
A knowledge base can contain more than documents
The boundary is not simply “documents are old, APIs are live.” That shortcut creates its own design mistakes.
A retrieval system may search an index of uploaded files, query a connected repository or retrieve structured records. Some platforms offer several approaches. Microsoft's Copilot Studio knowledge-source documentation describes different source types and authentication requirements. The words “knowledge base” alone do not tell a buyer when information refreshes or whose permissions apply.
Likewise, an API response can come from a delayed integration or a cached copy. Connecting an API is not proof that every field is current. Ask where the record originated, when it was observed and what its status actually means.
The useful distinction is the authority required for the answer. General guidance needs an approved explanation. A customer-specific status needs a permitted record that represents the requested event. A change needs a completed operation in the responsible system.
That leaves room for a structured retrieval service to supply an order status, provided its freshness and access rules fit the promise. It also leaves room for a straightforward account page to do the job better than a conversational interface. Choose the simplest reliable route for the customer's task.
One answer may need two kinds of evidence
A customer rarely separates questions according to the architecture. “Why can't I change this order?” may need both the relevant policy and the order's current stage.
A useful response would explain the condition and connect it to the observed record. It should not infer the order's stage from an old support message, nor claim that every order is locked simply because one article describes a restriction.
Design the response so the evidence stays distinguishable. The policy link explains the rule. A status label describes the record checked. If the information is delayed or the rule requires a staff decision, the answer should say so. A citation to a help article cannot stand in for evidence that an individual request was approved.
This also helps the support team investigate disagreements. A vague answer such as “the system does not allow it” hides whether the restriction came from policy, account permissions or an integration error. A response that identifies the reason gives staff a starting point.
Keep the design modest. Customers do not need an architecture diagram in every chat. They need to understand what was checked, what is still uncertain and what they can do next.
Customer identity belongs in the integration
An assistant should not gain access to an order merely because someone typed its number. The business needs an appropriate way to establish who is asking and which records they can use.
For an authenticated SaaS product, the application may already know the signed-in user and their organization. The integration should carry that context through to the record lookup. It should not let a model-selected customer identifier replace the application's access decision.
Public support channels need a different arrangement. Depending on the task, the assistant may direct the customer into a secure account flow or pass the request to staff. Do not turn a conversational exchange into a substitute for the identity controls the underlying business process needs.
Microsoft's documentation for agent tools distinguishes end-user credentials from maker-provided credentials. That distinction matters when evaluating a supplier: a connector authorized by an administrator may have a much wider view than the person using the assistant should receive.
Ask the implementation team to demonstrate the access boundary with controlled sample accounts. One customer's request must not reveal another customer's record. A response that omits a sensitive field is insufficient if the tool already fetched data it should never have accessed.
An unavailable system changes the answer
If the order service cannot be reached, the assistant can still explain the general delivery process. It cannot honestly turn that explanation into a current order status.
Make that difference visible. “I can't check your order right now” is more accurate than guessing from the standard delivery window. Offer an appropriate next step, such as opening the account page or creating a request for staff, and distinguish a submitted request from a completed resolution.
The same discipline applies when a write has an uncertain outcome. A timeout might leave the assistant unable to tell whether a change completed. Repeating the operation without checking can introduce a second problem. The implementation needs a way to inspect the result or send the unresolved request to someone who can.
These behaviors belong in the specification, alongside the successful path. They affect the customer experience and the ongoing support burden. They are not details to discover after the demonstration has been approved.
Avoid one broad fallback message for every failure. Missing account access, an unavailable service and a business rule preventing a change require different next steps. Clear distinctions help customers act without making them interpret technical error codes.
Buy the supported tasks, then the interface
When comparing proposals, ask suppliers to describe the evidence behind each promised task. For general questions, identify the approved sources and who maintains them. For record lookups, identify the responsible system, access rules and acceptable delay. For changes, identify the permitted operations and what counts as confirmation.
That conversation exposes scope earlier than a feature list. A document assistant may be a sensible first release. Adding an authenticated lookup expands its usefulness, while adding integration work and failure handling. Allowing transactions expands responsibility again. None of those steps has a universal price or timeline; the existing systems and the exact operations determine the work.
Before release, use sample records to review the promises separately. Ask a general question, an account-specific question and a change request. Include an unavailable service and a request outside the user's permissions. Inspect the record behind any claimed change. These are proposed acceptance checks, not tests performed for this article.
Lesscode offers AI knowledge systems and RAG development alongside integration services. A useful starting brief names the customer tasks and the systems that can establish their answers. That gives the team a concrete basis for deciding what belongs in retrieval, what needs a live lookup and what should remain with staff.
The chat window can stay simple. The promises behind it need to be precise.