Vora
Separate the facts by how the business controls them
Start with a small source map. Ask the client which system staff use when a customer disputes a price or booking. Identify who can change that system and which conditions affect the result.
| Customer question | Suggested source | Context to establish | What the answer may claim |
|---|---|---|---|
| What does the service include? | Approved service description | Service and location | The published scope of the service |
| What is the listed price? | Current catalogue or approved rate record | Exact item, currency, unit and applicable terms | The applicable listed amount and its conditions |
| What will my job cost? | Approved quotation process | Customer requirements and any authorized adjustments | An estimate or quote with the status the business actually issued |
| Is this item available? | Relevant inventory system | Variant, location and fulfilment method | Availability reported by that system at the lookup time |
| Can I take this appointment? | Scheduling system | Service, staff or resource, local time and duration | An offered time until the booking process confirms it |
This is a proposed mapping exercise. A client's catalogue might live in its commerce platform, billing system or a maintained internal service. Choose the actual authority with the client. If two systems disagree, resolve that through the source-authority register before designing the lookup.
Retrieve the price that applies to the request
"How much is the standard plan?" may still leave the billing interval or currency unresolved. An assistant that selects the first amount it finds can return a valid price for the wrong purchase.
Stripe provides a concrete provider example. Its documentation distinguishes products from prices and allows multiple prices for one product. A price can carry a recurrence interval and tax behavior. An integration therefore needs to select the relevant price, not assume the product name identifies one amount. Stripe's product and price guide describes those fields and relationships.
For the client's workflow, define the details required before a price lookup. Return a structured result that includes the amount, currency, charging unit and applicable conditions. Where the source distinguishes tax-inclusive and tax-exclusive amounts, preserve that distinction in the customer answer. Do not calculate missing tax or discounts from guesswork.
A custom quote needs its own status. If staff must approve the amount, the assistant can collect requirements and report that a quote has been requested. It should not present a catalogue price as the final cost of a job whose scope remains open.
Keep the source reference with the conversation record so staff can explain which price was shown. Limit retained information to what the business needs for that purpose.
Decide when a stored result expires
There is no useful universal refresh interval for all prices and availability. Set the rule with the person who owns the fact and the risk of using an old value.
A published service description might remain usable until the owner replaces it. A promotional price needs an effective period and any eligibility conditions. An available appointment may need another check after the customer changes the service or delays their decision.
For each changing fact, record:
- The source and the business time or version attached to the result.
- The maximum age allowed for this use, if storing a copy is permitted.
- Changes that invalidate a stored result, such as a different location or quantity.
- What to do when a required refresh fails.
An expiry time controls whether the assistant may reuse a result. It does not guarantee that the underlying fact remained unchanged until that time. A reservation or price guarantee needs explicit support from the business process.
Document updates can also take time to reach search. OpenAI states that file removal from a vector store is eventually consistent and removed content may remain in search results briefly. If an answer must stop using a withdrawn price immediately, design and verify an exclusion path rather than relying only on deletion finishing instantly. OpenAI's retrieval documentation records that behavior.
An availability check is not a reservation
Google Calendar illustrates the distinction at the API level. Its Freebusy query returns busy periods and may include errors for individual calendars. Creating an event uses a separate Events insert operation. Google's Freebusy reference and event-creation reference describe the two operations.
A free/busy response also does not settle every business rule. The service may require travel time, equipment, a qualified employee or approval. The application must check the rules the client uses before offering the time.
For a direct-booking workflow, use the scheduling system's supported reservation process and inspect its accepted result. A generic calendar event write should not be assumed to enforce the client's capacity or prevent overlapping bookings. Define that behavior as an integration requirement and test it.
Then make the wording match the result. "That time is currently available" describes a lookup. "Your request has been sent" describes an accepted request. "Your appointment is confirmed" belongs after the workflow meets the client's confirmation condition.
If the customer changes a detail that affects eligibility or duration, return to the relevant check. Keep the current request separate from a result retrieved for the previous version.
Preserve unknown results during an outage
A failed inventory lookup does not mean an item is unavailable. A calendar error does not mean the diary is empty. Preserve the distinction between a successful response with no matches and a request that never produced a usable answer.
The customer needs wording such as "I can't check availability at the moment" followed by the approved next step. If the business permits a last-known price as an indication, label it with its relevant date and conditions. Do not use it to confirm a purchase that requires a current amount.
When an action times out, its outcome may be uncertain. Check whether the booking or order exists before retrying. The post-call testing guide explains how to inspect the saved result and what the customer was told.
Use the agreed fallback and handoff method when the assistant cannot complete the check. Staff need to know what was requested, what was attempted and which result is still unknown.
Test a change while the conversation is open
Build a controlled test with synthetic customer details. Start with a successful price and availability lookup, then change one relevant condition before the customer accepts.
Useful cases include a withdrawn promotion, a different billing interval, a slot taken by another booking and a failed refresh. Include an inventory response for the wrong location and a calendar response containing an error. The expected behavior should state when the assistant must ask again, retrieve again or stop short of a commitment.
Inspect the source record, the retrieved result and the customer's message. If a booking or order was attempted, inspect that record too. A transcript saying the right amount cannot establish which amount reached checkout.
For an agency's first-client deliverable, price explanations and request collection may be a more supportable scope than immediate quotations and reservations. Write the agreed boundary into the acceptance criteria.
Keep one test where the customer returns after a long pause and says, "I'll take it." The next lookup and the next sentence should reflect what the business can still offer at that moment.