Example / Order support
Order support in chat: resolve the question before the refund.
Support conversations become expensive when people have to find an order, reconstruct its state, look up policy, and then move to a separate screen to take the next step.
Direct answer
Use chat to assemble order and policy context, explain the eligible next step, and stop for confirmation before a refund, replacement, cancellation, or address change is requested.
Reference workflow. It is deliberately not a promise that an AI host should make payments, refunds, or changes without product approval.
01 / Read first
Start with an order the customer can verify.
The first action should identify the right order and return a small, human-readable summary: status, fulfillment state, dates, and the fields needed to decide what can happen next. Do not expose unrelated customer history by default.
If the request is ambiguous, the conversation should ask for an order number, date, or another stable reference instead of guessing.
02 / Apply policy
Treat policy as product context, not model memory.
A policy rule needs a source and an owner. The product can return the current rule, the condition that matched, and the actions that are available to this user. That gives the assistant a grounded explanation and keeps policy changes outside the prompt.
A compact product response is usually safer than sending an entire policy manual to a model for every order request.
03 / Use an explicit action
Separate recommendation from execution.
The chat can recommend a replacement, a support handoff, or a refund request. The write tool should require the exact order, action, reason, and confirmation state. A successful call returns the product record, not merely a natural-language reassurance.
OpenAI’s Apps SDK documentation separates server tools, authentication, and optional UI resources. That separation is useful here: a result can be understandable without making the user trust an invisible side effect.
OpenAI Apps SDK · build an MCP server04 / Escalate well
Make the handoff an outcome, not a failure.
Some requests need a person: damaged goods, fraud signals, exceptions, or a policy that does not cover the case. The workflow should create a useful support handoff with the order context and the user’s request already attached.
That is still a finished customer task. It avoids a blank transfer while preserving the business decision for the team that owns it.