Your support chatbot can say a price is unavailable by making every price answer depend on an approved record. When no valid record matches the request, the application should display a clear unavailable message and offer staff help, rather than ask the model to estimate.
The important change is architectural: let the chatbot understand the question, but let controlled application logic decide whether an amount may appear. The workflow below is a proposed design for a South African support team, not a native feature that a chatbot automatically provides.
1. Define which prices the chatbot may display
Start by agreeing on the price promises the business permits. A public catalogue price, an account-specific rate and a formal quotation are different things. Do not let the chatbot treat them as interchangeable.
A proposed starting scope is public, fixed prices for clearly identified products. Keep negotiated discounts, customised work and disputed quotes with staff until the business has approved a reliable process for them.
Assign a pricing owner to approve records and a support owner to manage unanswered requests. Ask those owners to settle practical questions before development:
- Does the amount include VAT, and who confirms that treatment?
- Is delivery included, excluded or dependent on location?
- Is the unit a single item, a pack, an hour or a month?
- Does the price apply to a particular branch or customer group?
- Is it an informational price or an offer requiring further approval?
Tax treatment, contractual wording and payment consequences require appropriate human judgement. Do not delegate those decisions to a generated answer. Scope this work within AI chatbots, with an explicit boundary between displaying approved information and making commercial commitments.
2. Build an approved price record, not a paragraph
Store prices as structured records with enough context to determine whether each one applies. A sentence such as “installation starts from a certain amount” cannot establish a final charge for a specific customer.
A proposed record should contain:
record_idandversion: traceable identifiers.product_idandvariant_id: the exact item or service configuration.amount,currencyandunit: the value and what it buys.tax_display: approved wording for the tax treatment.valid_fromandvalid_to: the period during which it may be shown.customer_scopeandlocation_scope: eligibility boundaries.conditions: quantity, delivery and other approved limitations.approval_statusandowner: authority to publish and responsibility for corrections.
Use explicit timestamps and a documented time zone. Decide whether the end timestamp is inclusive or exclusive; a proposed simple rule is an inclusive start and exclusive end.
Treat a missing amount differently from zero. Treat a missing expiry differently from unlimited validity. If open-ended records are permitted, represent that permission explicitly rather than letting the application assume it.
3. Separate support retrieval from price authority
Use general documents to explain products, but use the approved record system to authorise price display. Finding a price-like sentence is not the same as finding an applicable price.
Source: OpenAI’s file search documentation describes retrieval from uploaded files using semantic and keyword search. That capability can support answers about product features or published policies. It does not, by itself, establish your business’s current pricing authority.
In this proposed workflow, a brochure may help identify a product. Its price text must not populate the customer’s price message. The chatbot should instead request a lookup against the approved record source.
Keep this boundary even when a customer uploads an old quotation or types an amount into the conversation. Their information may warrant staff review, but it is not permission to confirm that amount.
The wider customer-service agent use cases help frame where support retrieval belongs. For pricing, add a separate decision step: “May this exact amount be displayed for this exact request?” This distinction matters more than how confidently the chatbot writes.
4. Put the lookup and validation in application code
Have the application validate the lookup result before producing a price message. Do not rely on a prompt that merely tells the model to be careful.
Source: OpenAI’s function calling guide describes a flow where the model requests a tool call and the application executes the code. That gives a developer a place to implement the business’s proposed lookup and validation rules; it does not supply those rules automatically.
A proposed lookup_approved_price function would accept validated product details and return a status such as available, needs_details, missing, expired, conflict or lookup_failed. Where the application already knows the authenticated account or selected product, pass those values directly rather than asking the model to invent them.
Check approval, eligibility, validity, required conditions and uniqueness. Two applicable records should trigger a conflict unless an approved precedence rule resolves them unambiguously.
Use read-only price access. Keep record changes and approvals outside the customer conversation. Have a security reviewer assess account-specific access and permissions. The AI CRM integration glossary provides context for connecting customer records, but a connection still needs appropriate access controls.
5. Render price messages from validated fields
Use a fixed template for the amount and its conditions. Allow conversational wording around it only where that wording cannot introduce a new price, discount or promise.
Source: OpenAI’s structured outputs guide describes constraining output to a supplied schema. A schema can organise fields and permitted statuses. It is not evidence that an amount is factually correct or commercially approved.
A proposed response object should include the status, approved record reference, validated price fields, reason code and permitted next action. For unavailable statuses, the application should remove price fields and render a fallback itself. Handle model refusals, incomplete responses and parsing failures through an application fallback too.
Suggested customer messages include:
- Missing: “I don’t have an approved price for that option. Would you like staff to prepare a quote?”
- Ambiguous: “Which pack size do you need? I need that detail before checking the price.”
- Lookup failure: “I can’t check the current price right now. I can help you request a quote.”
These are proposed templates. Do not add “approximately”, a remembered amount or a guessed range to soften the refusal.
6. Give unavailable requests a usable staff route
Offer a specific next step without claiming a handover has happened before it succeeds. An unavailable message is useful only if the customer can still progress.
The proposed handover should include the requested item, confirmed configuration, missing details, lookup reason, relevant record references and a concise conversation summary. Collect only the contact information needed for the chosen follow-up, with appropriate privacy and security review.
Show “Your request has been sent” only after the receiving system confirms acceptance. If submission fails, say so and offer an existing staffed route. Do not invent a response deadline. Display a time commitment only when the team has approved it and can support it operationally.
For WhatsApp customer-service workflows, keep the unavailable message short and make the next action easy to understand. The same validation should apply across channels.
Staff should resolve the exception in the price source where appropriate, not merely type a one-off answer that the chatbot later treats as a universal price. Record who owns the correction and whether it affects other products or customers.
Reusable price-release checklist
Use this proposed checklist as the acceptance procedure for every price response. All rules below are proposed and require business approval.
| Check | Release condition | Otherwise |
|---|---|---|
| Product | Exact product, variant and unit confirmed | Ask for the missing detail |
| Authority | Record is approved for customer display | Say price unavailable |
| Eligibility | Customer and location match record scope | Route to authorised staff |
| Validity | Current time falls within the approved period | Withhold expired or future price |
| Completeness | Amount, currency, tax wording and conditions are present | Request pricing-owner review |
| Uniqueness | One applicable record, or approved precedence resolves matches | Flag conflicting records |
| Availability | Lookup completed successfully | Say current price cannot be checked |
| Rendering | Amount and conditions come only from validated fields | Block response and use fallback |
| Handover | Receiving system confirms request acceptance | Explain submission failure |
Approved-response contents: product and variant, amount and currency, unit, tax wording, validity date and relevant exclusions.
Unavailable-response contents: clear limitation, one useful clarification or staff option, and no estimated amount.
Staff task contents: request details, reason code, record references, contact preference and assigned owner. Staff must approve any new price or exception before it becomes customer-facing.
Worked walkthrough: valid, missing and conflicting prices
A hypothetical catalogue illustrates how the proposed checks would work. All amounts, identifiers and dates in this example are fictional.
A customer asks for one Standard Kit, product KIT-S, for collection from the branch covered by the record. Hypothetical record P-101 contains R480 per kit, approved wording that VAT is included, and validity from 1 October 2026 to the start of 1 November 2026. The lookup runs on 5 October 2026 and finds one applicable approved record.
The fixed message displays: “The Standard Kit is R480 per kit, including VAT, for collection. This price is valid through 31 October 2026.” It does not add a delivery charge or promise stock availability.
A second customer asks for the kit with customised fittings. No approved configuration price exists. The response says the price is unavailable and offers a staff quote. Staff review the fitting requirements and approve a quotation through the business’s normal process.
A third request finds two approved records for the same scope and period, one at a hypothetical R480 and another at a hypothetical R520. The application returns conflict, not the cheaper amount or the newest-looking row. The pricing owner checks the approval history, corrects or withdraws the conflicting record and authorises the answer.
If the customer asks only for “the kit”, the chatbot first asks which variant they mean. Clarification resolves ambiguity; it must not become a reason to select a popular variant silently.
7. Evaluate exceptions before widening the scope
Test whether each status produces the intended customer message and staff task. Evaluate the workflow’s behaviour, not just whether the model sounds helpful.
Build a proposed test set containing valid records, missing prices, expired promotions, future prices, duplicate records, unclear units, account restrictions and lookup outages. Add customers who insist that the chatbot “just estimate”, paste an old price or request a discount.
For each case, write the expected status and permitted output before running it. Check the entire delivered message, including follow-up turns. A correct unavailable message followed by a guessed amount is still a failure.
A proposed release gate is no unsupported amounts in the agreed test set, correct conditions on every released price, and successful exception routing. Passing that set does not prove that all future responses will be correct.
Track unsupported amount displays, unnecessary unavailability, clarification success, handover acceptance and staff resolution. Review failures with the pricing and support owners. This process may reduce unsupported promises, but that benefit needs evaluation.
If your business needs help defining these controls within AI automation, get in touch to discuss the approved data source, exception ownership and customer messages before expanding chatbot pricing access.
FAQs
Can the chatbot show an old price with an expiry warning?
The proposed default is to withhold expired amounts when answering a current-price question. Showing an old figure may still anchor the customer’s expectation. If historical pricing is a genuine support need, create a separate, approved historical-information route with unmistakable dates and wording. A staff member should review requests to honour an expired quotation rather than letting the chatbot decide whether the old amount applies.
What if the customer only wants a rough estimate?
Do not generate a range from memory. Either provide a separately approved estimate record with its scope, assumptions and validity, or offer staff help. The business should decide whether such estimates are appropriate and how to explain their limits. Calling a figure “rough” does not establish its accuracy or remove the need for human judgement about commercial consequences.
Should a duplicate record be resolved by choosing the latest update?
Not unless an approved precedence rule says the update is authoritative for the exact request. A recent edit could concern a different branch, customer group or future period. Under the proposed default, overlapping applicable records produce a conflict and no displayed amount. Staff should review approval history and applicability, correct the underlying records, and then rerun the lookup before releasing a price.