Yes. Your chatbot can show customers the approved policy section behind an answer, with its version and effective date. The important part is not adding a source badge. It is checking that the linked section supports what the chatbot actually says, applies to the customer’s situation and can be opened by that customer.
For an AI chatbot, treat policy citations as a support workflow: retrieve the relevant evidence, check the answer against it, display a useful reference and hand unresolved exceptions to a person. The process below is a proposed design, not a claim of completed implementation or tested results.
1. Decide which policy answers may reach customers
Start with policies that your team has approved for customer use, rather than everything in the shared drive.
A public returns policy, delivery guide or subscription cancellation page may be suitable. Staff notes, draft terms and internal exception instructions need a separate decision. A chatbot should not expose an internal file merely because that file explains how agents handle an issue.
Assign a policy owner who can confirm the wording, audience and effective dates. Ask that owner to distinguish a general explanation from a decision about an individual customer. Explaining the cancellation process is different from confirming that a particular account qualifies for a refund.
The proposed boundary is simple: the chatbot may explain supported policy wording, but disputed rights, payment consequences and exceptions go to an authorised person. For a South African business, legal interpretation and consumer-rights questions need appropriate human judgement. A policy citation is not a legal conclusion.
Use the broader AI automation plan to assign these responsibilities before connecting the customer-facing channel.
2. Give every section a stable identity and applicable version
Create a section register so the application can distinguish similar documents and select the policy that applies.
For each section, record its policy name, section heading, version label, effective period, applicable product or service, intended audience and approved customer destination. Keep the section text with that record. These are proposed application fields, not an assertion that a retrieval tool supplies them automatically.
Do not assume that the latest version governs every question. A customer asking about an earlier purchase may need a previous version. If the applicable date is unknown, ask for the minimum information needed or send the question to an agent.
Keep historical versions distinguishable from current guidance. Avoid replacing a document while retaining a label that makes the old and new wording look identical. If a section moves, maintain a deliberate destination mapping rather than allowing the chatbot to invent a link.
The register should also identify who resolves conflicts. Two documents with different names can still contain competing rules, so filenames alone are not a sufficient authority check.
3. Retrieve evidence before writing the policy answer
Require supporting evidence for policy answers instead of relying on the model’s general knowledge.
Source: OpenAI’s file search documentation describes retrieval from uploaded files using semantic and keyword search. It also shows responses containing file-citation annotations. This establishes a retrieval and citation capability, not a guarantee that a cited passage supports an answer.
For the proposed workflow, provide the relevant customer question and known context, retrieve candidate sections, then check their audience, effective period and scope against the register. Retain the supporting passage for evaluation. If the integration exposes only a filename without enough text to verify the claim, obtain the section through the application before releasing the answer.
Keep headings, conditions and exception text together where practical. A sentence about a return window may depend on the next paragraph about excluded products.
Do not choose retrieval limits merely to make responses shorter. The documentation notes that limiting results can trade answer quality for lower token usage and latency. Evaluate that choice on your own policy questions.
4. Map retrieved files to customer-accessible sources
Resolve customer links through your application, not through free-form model guesses.
A file-citation annotation is not the same as a public policy URL. Your team needs a mapping from the retrieved evidence to an approved customer page or authorised document viewer. That mapping should preserve the section and version used in the answer.
Source: OpenAI’s function calling guide explains that the model can request a function and the application executes the corresponding code. A proposed read-only lookup could return the approved destination for a policy section. This lookup and its permission checks would be custom application work, not a native policy-publishing feature.
Have the developer validate the requested section against the register and return only allowed destinations. Security-sensitive access decisions need qualified human review. Do not expose storage locations, internal filenames or unrestricted document links.
If there is no approved customer destination, provide an approved public explanation if one exists, or offer human help. Do not pretend the customer can inspect a source they cannot access.
5. Check each claim before displaying the citation
Check whether the source supports the exact statement, including its conditions and limitations.
Split the proposed answer into material claims. For each one, ask: does the cited passage establish this statement, or does it merely discuss the same topic? A delivery section mentioning estimated dates does not necessarily support a promise that an order will arrive tomorrow.
Use a proposed response structure containing the answer, separate claims, supporting passages, source destinations and an exception reason where needed. Source: OpenAI’s structured outputs guide describes schema-constrained responses. A predictable structure can help the application display and inspect these fields; it does not establish that their contents are factually correct.
Validate destinations and versions in code, and use human-labelled examples to evaluate substantive support. A second model check may assist review, but should not be treated as independent proof.
As a proposed release rule, withhold any material claim that lacks support. Rewrite the answer more narrowly or route it to an agent. Do not hide an unsupported promise behind an otherwise valid citation.
6. Display a short answer with a useful source label
Show the answer first, then place the relevant source beside the claim it supports.
A useful label includes the policy name, section heading, version and effective date. Let the customer open the relevant section without searching through a long document. Where several sections support different statements, attach each reference to the appropriate statement rather than adding an undifferentiated source list.
Distinguish policy information from an individual outcome. Wording such as “This section explains the request process” is safer than implying that opening the policy confirms approval.
Check the actual delivery channel. The WhatsApp AI agents planning resource is relevant when designing a message-based support journey. Test whether the customer can read the label, follow the destination and return to the conversation. Do not assume a web citation panel translates directly into a messaging interface.
Avoid flooding customers with references. The goal is inspectable evidence for the answer, not a long list of documents that leaves them to resolve contradictions themselves.
7. Evaluate exceptions and maintain the evidence path
Evaluate unsupported answers and broken references separately, because either can make a citation unhelpful.
Build a proposed test set covering ordinary questions, missing dates, excluded products, historical policies, contradictory versions, inaccessible links and questions combining several rules. Include paraphrases so the test does not depend on customers using policy headings.
Have a support reviewer label whether each claim is supported, applicable and complete. Separately check whether each customer destination opens and identifies the correct version. Record failures by cause: retrieval, interpretation, version selection, destination mapping or display.
A proposed acceptance rule is that every material claim in the evaluation set must have applicable support and every displayed destination must open for its intended audience. This is a release gate to consider, not a measured performance claim or a guarantee about future conversations.
Repeat relevant checks after policy changes. The customer service agents resource can help frame the wider handover. If handover uses customer records, the glossary entry on AI CRM integration provides useful terminology; keep this citation exercise distinct from granting live-data access.
Reusable source-checking support template
Use this proposed template for each evaluated policy answer and each escalated citation exception.
Question and context
- Customer question: [exact wording]
- Relevant product, channel and policy-applicability date: [known facts or unknown]
- Missing context to request: [minimum necessary detail]
Evidence record
- Policy name and section heading: [approved reference]
- Version and effective period: [applicable version]
- Supporting passage: [exact section text retained for checking]
- Approved customer destination: [registered link or unavailable]
Claim check
| Proposed claim | Supporting passage | Conditions preserved? | Outcome |
|---|---|---|---|
| [One material statement] | [Specific supporting text] | [Yes/no, with omission] | [Supported/rewrite/escalate] |
Customer response
- Answer: [only supported statements]
- Source label: [policy, section, version, effective date]
- Limitation or clarification: [what remains unresolved]
- Next step: [customer action or human handover]
Exception handling
- Missing evidence: withhold the unsupported claim and ask the policy owner.
- Conflicting evidence: retain both passages and request an authority decision.
- Inaccessible destination: do not display it; request an approved alternative.
- Individual refund, disputed right or override: refer to an authorised person.
Completion check Confirm that every material claim has applicable support, the customer can open every displayed source, and unresolved exceptions have a named human owner. Do not mark an answer complete merely because it contains a citation.
Worked walkthrough: a normal answer and conflicting evidence
A hypothetical retailer has an approved collection policy, version 3, section “Collection notices”, effective from 1 September 2026. In this fictional example, the section says customers should wait for a ready-for-collection message before visiting.
Normal case: A customer asks, “Can I collect before the message arrives?” Retrieval finds that section, and the register confirms its applicability. The proposed answer is: “Please wait for the ready-for-collection message before visiting. Source: Collection policy, Collection notices, version 3, effective 1 September 2026.” The interface would attach the registered destination. The check passes only if the answer preserves the condition and the customer can open the cited section. It must not add a promise about when the message will arrive.
Conflicting case: A second file says customers may collect after an order confirmation, but has no clear effective period. The chatbot should not select whichever wording is more convenient. Its proposed response is: “I cannot confirm the collection instruction from the available policy information. A support agent needs to check it before you travel.”
The agent receives the question and both passages. The policy owner determines which wording applies, then corrects or retires the conflicting entry. If the conflict depends on an unknown order date, the agent requests that detail. Duplicate copies with identical wording can share one customer reference once the team verifies their identity; conflicting wording requires an authority decision.
FAQs
Can we cite an internal PDF that customers cannot open?
Not as an inspectable customer source. The internal PDF may support staff review, but the customer needs an approved public page or authorised viewer containing the relevant policy wording. If no such destination exists, explain the limitation and offer an agent handover. Do not publish the internal document simply to make the citation clickable, particularly where it includes staff guidance or sensitive material.
What if one answer needs two different policy sections?
Check and cite each material claim separately. A cancellation answer might need one section for the request process and another for timing conditions. Keep both conditions visible and attach each source to the statement it supports. If one part is supported and another is unresolved, answer the supported part narrowly and identify what an agent must confirm. Do not let one valid reference stand in for the whole answer.
How do we test an old policy version without misleading customers?
Create a clearly hypothetical question tied to a date within that version’s effective period. Check that retrieval selects the applicable wording and that the destination visibly identifies it as historical. Also test a question without a date: the expected response should request context or escalate when version choice matters. Human reviewers should decide disputed applicability rather than relying on the chatbot’s confidence.
If your business needs customer-visible policy sources, start with a small approved policy set and the template above. For help planning the retrieval, source display and exception handover, get in touch with Symaxx to discuss the scope.