What the documents look like
FBM fulfillment places picking, dispatch confirmation, the returns address, and tracking under the seller's own operation rather than a platform warehouse inspection. The working materials for this category are the order picking list, the dispatch confirmation, the returns address setting, and the logistics tracking sheet. These are produced, updated, and reconciled on the seller's side, and the customer service and logistics role answers buyer follow-up questions from the actual state held in the carrier system and the ERP order records. The update rhythm is per order and daily, so a single conversation may pass through picking, dispatch confirmation, and tracking-number backfill at different moments.
That sequence matters for multi-turn prompts because "picked," "dispatch confirmed," and "tracking number recorded" are three distinct facts. A prompt that treats an earlier mention of dispatch as proof that a tracking number exists will answer beyond what the materials support. The prompt needs to state the material scope, the answering task, and how to behave when evidence is absent, so the model does not write in business facts. History must be checked for the context actually carried in, and a new conversation must be distinguished from a continued one. For customer service and knowledge-base question answering, a small number of history turns is usually sufficient; a large memory setting brings in unrelated earlier content. Model and length settings should be checked against the context the model supports, and long documents combined with follow-up questions need separate testing. Reply format follows what comes next: ordinary customer service keeps the default, and choosing json_schema requires filling in the corresponding format requirement and verifying the returned structure. Retrieval is the process of obtaining material and does not constitute authorization. Forms collect values, and business verification, approval, database writes, and external synchronization each need their own stated downstream implementation.
Constraints at the multi-turn prompts step
The prompt must fix the material scope and the answering task, and it must define the handling of missing evidence. History must be inspected for what was actually carried into context. Question optimization for continuous knowledge-base conversation needs checking for reference resolution and question expansion, without assuming every short question qualifies. Model and length settings must be compared against the documented maximum context and reply configuration. Reply format is chosen by the downstream consumer. Retrieval similarity is not a category, entity, or permission filter, and a similarity setting does not exclude unrelated businesses or unauthorized records.
Hypothetical drill sample: the material text reads "Order A-1001 picking list shows picked on 2025-03-04; dispatch confirmation not yet generated; returns address setting holds the default overseas warehouse address; logistics tracking sheet has no carrier record for this order." A draft sentence awaiting judgment reads "This order has shipped and the tracking number will follow shortly." The source text supports only "picked." The dispatch confirmation is not yet generated and the tracking sheet has no record, so "has shipped" is unsupported, and "tracking number will follow shortly" is a commitment about an action that has not occurred. This sample is a paper exercise, not a record from any real order.
Configuration and implementation checks
| Configuration item | Hypothetical starting point for this exercise | Reason and comparison method |
|---|---|---|
| AI model | A model documented as supporting tool calls and a sufficient maximum context | Must hold order materials plus multi-turn follow-ups; compare the documented maximum context and tool-call capability |
| Memory turns | A small number of turns as the hypothetical starting point | Customer service question answering needs recent context; compare whether carried history introduces unrelated older-order information |
| Reply limit | A length that accommodates a complete explanation as the hypothetical starting point | Compare truncation against the need for a complete reply; a low setting truncates early |
| Temperature | A low value as the hypothetical starting point | Customer service requires stability; compare repeated answers to the same question for consistency |
| Reply format | Keep the default | Ordinary customer service needs no fixed structure; change only when a downstream step reads a fixed format |
| Thinking configuration | Keep the default | Simple follow-ups need no high thinking strength; compare reverting to default after an error |
These values are hypothetical starting points for this exercise, not official defaults.
Three common errors
- Treating "picked" as "shipped." The input is the picking list and dispatch confirmation text above; compare the shipment status in the draft sentence against the stage the material records. If the draft says "has shipped," it does not match the source.
- Treating a retrieval hit as authorization. The input is a returns address entry returned from the knowledge base; compare whether that entry contains an authorization statement for this specific order. If only the address text is matched and no authorization field is present, a returns commitment cannot rest on it.
- Treating a form submission as completed approval. The input is the returns request form values collected at the interactive node; compare whether an approval result field exists. If only form values are present and no approval record exists, the request remains pending review.
How to verify the setup
- Send one conversation turn using the hypothetical source text and draft sentence above, and compare whether the answer changes "has shipped" to "picked, dispatch confirmation not yet generated." If the answer still states the order has shipped, the condition is not met.
- Under the same
chatId, append "What is the returns address," and compare whether the answer cites only the returns address setting text. If the answer adds a returns authorization not present in the material, the condition is not met. - Submit the form values and continue the conversation, and compare whether the returned content marks the request as pending review. If it directly shows approval, the condition is not met. All three are paper checks and were not executed.
Where the source material is silent, the field remains unknown. A pending request is not an approval, an offered option is not execution, and an unsigned termination is not a completed termination.