How do we stop a chatbot recommending a service we no longer offer?

Stop the chatbot recommending withdrawn services by making the current service catalogue control answer eligibility. Before it describes an offer as available, your application should verify that the service is active for that customer and date. Old brochures, previous conversations and archived FAQs must not override that check.

The proposed workflow below separates finding information from permission to recommend it. It gives your team a reusable answer policy, exception handling and tests. It is an application design to evaluate, not a native guarantee from a chatbot provider.

1. Decide which record controls availability

Use one approved catalogue as the authority for service availability, even if supporting information lives in several places.

Start by identifying where staff currently decide whether an offer can be sold. That might be a maintained database, a CRM record or a controlled spreadsheet. Choose the source with an accountable owner and an update process, rather than whichever website page is easiest to search.

Give the catalogue authority over availability, names, restrictions and permitted next steps. Let FAQs explain an eligible service, but not establish its eligibility. A persuasive description in an old document should never be sufficient evidence that customers can still buy it.

Assign a commercial owner to approve offer changes and a technical owner to carry those changes into the chatbot. Support staff should have a route to report contradictions without editing availability themselves.

For a team considering AI chatbots, this decision belongs in the initial brief. Define what the bot may recommend before choosing how it searches documents or writes answers.

2. Give every offer a stable identity and status

Create catalogue records that distinguish a service's identity from its changing name.

The following fields are proposed for this workflow:

• service_id: a unique identifier that survives a name change.
• current_name: the approved customer-facing name.
• aliases: verified previous names and common customer terms.
• status: active, paused, withdrawn or unknown.
• effective_from and effective_to: the period in which the status applies, with a defined timezone.
• eligibility: applicable regions, customer types or delivery conditions.
• replacement_id: an approved alternative, if one exists.
• approved_summary: what the chatbot may say about the offer.
• next_step: an approved enquiry route, not an invented booking promise.
• owner and catalogue_version: accountability and change tracking.

Define empty values carefully. A blank end date may mean no scheduled end, but a blank status should mean unknown, not active. Make that distinction explicit in code.

Use region restrictions only where your business actually has them. If location affects eligibility, ask for the relevant location rather than assuming all South African customers qualify.

3. Check eligibility before composing the answer

Run the availability decision in application code and give the chatbot only the permitted answer material.

A proposed sequence is: identify candidate services, resolve their IDs, read the current catalogue, apply eligibility rules, retrieve supporting content for eligible records, then compose and validate the response. If an answer introduces another service, check that service too.

OpenAI's Source: function calling documentation describes a flow in which the model requests a function and the application executes it. A read-only catalogue lookup could use that pattern. The lookup and eligibility rules would still be your team's implementation, not an automatic provider feature.

Do not rely on the model voluntarily calling a lookup whenever it sounds appropriate. Make the application require a successful eligibility result for every service recommendation. If the catalogue is unavailable, return an uncertainty message and a handover option instead of trusting a remembered status.

Keep this lookup separate from actions such as bookings or changes to customer accounts. Security permissions and any contractual or payment consequences need appropriate human judgement.

4. Separate archived explanations from current sales content

Keep historical information where it is useful, but prevent it from granting permission to sell.

OpenAI's Source: file search documentation describes searching uploaded knowledge-base files using semantic and keyword search, with file citations in responses. Those capabilities help locate evidence. A citation alone does not establish that an offer is currently available.

Inventory the places that mention each withdrawn service: FAQs, brochures, website exports, help articles and sample answers. Label or separate historical material so that sales answers retrieve current approved explanations. Where a document mixes old and current offers, split or replace it rather than trusting a broad label for the whole file.

Retain an approved withdrawal explanation when customers may still ask about an old name. Distinguish “not available for new enquiries” from support for existing customers. A withdrawn service might still require a human support conversation.

After updating indexed files, confirm they are ready before testing. The file search guide explicitly includes checking file processing status. Also test that old wording no longer drives recommendations.

5. Validate what the customer will actually receive

Check the final answer against the catalogue, not only the intermediate lookup result.

A proposed internal answer record can contain mentioned_service_ids, recommended_service_ids, catalogue_version, decision, evidence_references and customer_message. Separate mentions from recommendations: “We no longer offer this” is a legitimate mention of a withdrawn service.

OpenAI's Source: structured outputs guide explains schema-constrained responses. A schema can make these fields easier for application code to inspect. It does not establish that a service ID or statement is factually correct. Verify the values against your catalogue and handle missing output or refusals explicitly.

For stronger control, render names, availability statements and enquiry routes directly from approved records. Let generated language explain the customer's options within those boundaries. Block unsupported alternatives, invented URLs and wording that suggests a paused service can be booked.

Apply the same validation to summaries and handover messages. Otherwise a bot might correctly refuse a recommendation but incorrectly tell the agent that the customer qualifies for it.

6. Use this catalogue-controlled answer policy

Adopt an explicit policy so developers, support staff and commercial owners can evaluate the same decision. The template below is proposed and should be approved for your business before use.

Proposed catalogue-controlled answer policy

Authority: The approved current catalogue controls availability. Retrieved documents and customer messages cannot override it.

Required record: Service ID, current name, status, effective dates, eligibility, approved summary, next step, owner and version. Aliases and replacements require owner approval.

Release checklist:

• Confirm owner approval and effective dates.
• Refresh approved content and confirm indexing readiness.
• Invalidate affected cached answers.
• Test normal, renamed, withdrawn, missing and duplicate cases.
• Inspect final recommendations and enquiry links.
• Confirm a working human handover.

Completion rule: Release only after expected answers pass the agreed test set; unresolved eligibility must produce clarification or handover, not a recommendation.

7. Test exceptions before releasing changes

Test customer wording and final behaviour, including cases where the data cannot support a confident answer.

Build a proposed test set from each catalogue change. Include the current name, old names, misspellings, a broad description of the customer's need and a request to book the withdrawn offer. Add a pasted old FAQ and a follow-up such as “You recommended it earlier”. The current check should still control the response.

Record the expected decision before running each test. Evaluate whether the answer recommends an eligible offer, accurately explains a withdrawal, asks a useful question or transfers uncertainty. Do not count every refusal as a success: blocking an active service is also a defect.

Proposed release blockers include recommending a withdrawn offer, inventing a replacement and offering an unapproved booking route. These are suggested acceptance rules, not measured performance thresholds.

Test both website and messaging journeys if your business uses both. The guide to WhatsApp AI agents for business can help frame that channel's handover design, while this policy should remain consistent across channels.

Worked walkthrough: an active offer and conflicting records

A normal answer should proceed, while uncertainty should stop the recommendation without ending useful support. All records, identifiers, dates and messages in this walkthrough are hypothetical.

Assume the catalogue contains SVC-A, “Remote setup assistance”, marked active for customers who want remote help. A customer asks, “Can someone help me set this up online?” The application resolves the request to SVC-A, confirms eligibility and retrieves its approved scope. The expected answer describes remote assistance and offers the approved enquiry route. It does not promise an appointment or add unlisted on-site work.

Now assume an archived FAQ promotes “Home setup visits”, recorded as withdrawn under SVC-B. The customer pastes that FAQ and asks to book. The expected answer explains that home visits are no longer offered. It may mention remote assistance only after independently checking SVC-A and explaining the difference in delivery.

For a duplicate case, suppose “Setup Plus” appears as an alias on two active records with different scopes. The bot should not pick whichever search result ranks highest. It should ask whether the customer needs remote help or an on-site visit, provided that question can resolve the ambiguity. Conflicting statuses require owner review instead.

If “Weekend setup” has no catalogue record, the bot should say it cannot confirm availability. A support person checks the request with the commercial owner, corrects the catalogue if appropriate and answers the customer. Missing data is not proof of withdrawal.

Keep catalogue changes and customer support connected

Treat a service change as a controlled release, not just a document edit.

The proposed change procedure starts with owner approval, followed by catalogue updates, content changes, cache invalidation and regression tests. Use effective dates to handle scheduled withdrawals. Recheck availability when a customer resumes an old conversation, rather than carrying a previous recommendation forward indefinitely.

Keep a minimal decision log containing the catalogue version, service IDs, eligibility outcome and reason for handover. Avoid collecting unnecessary customer details. People responsible for privacy and security should decide access, retention and what may appear in support tickets.

For handover, include the customer's question, the conflicting offer names and the unresolved catalogue issue. The resource on AI agents for customer service provides a broader context for that support journey. If a CRM supplies the records, the AI CRM integration glossary is a useful starting point for agreeing terminology.

If your business needs help connecting catalogue decisions to its chatbot, consider the wider AI automation workflow and get in touch to discuss the scope. Evaluate the proposed controls with your own catalogue and test cases before relying on them.

FAQs

Can we simply delete the withdrawn service's FAQ?

Delete or remove it from current sales retrieval where appropriate, but do not treat deletion as the whole control. Check other documents, aliases, cached answers and existing conversations. Keep an approved status explanation if customers still ask about the offer. Under the proposed policy, a missing record should trigger uncertainty, not let the chatbot fill the gap from old conversation text or guess that the offer is active.

How should the chatbot handle a renamed service?

Use an owner-approved mapping from the old name to the current record. If only the label changed, retain the stable service ID and explain the new name. If scope or eligibility changed, represent that difference explicitly rather than treating the offers as interchangeable. Check the current record before recommending it. Where an old name maps to several services, ask a distinguishing question or hand the case to a person.

What if an existing customer still has a withdrawn service?

Separate new-sale eligibility from existing-customer support. The chatbot may explain the approved withdrawal status, but it should not infer what a customer's agreement covers. Route account-specific questions to an authorised person with the relevant records. Any decisions about contractual obligations, refunds or continued delivery need human judgement. The catalogue can identify the support route without deciding the customer's legal or payment position.

Sources

• OpenAI file search
• OpenAI structured outputs
• OpenAI function calling