What the documents look like
Order fulfilment and after-sales answering for a TikTok Shop US store is shaped by local return windows, return grading and overseas logistics constraints, which separates it from shelf-style operations on Douyin Shop. The working material sits in four places: product listings, return and refund records, return grading evidence, and settlement bills. These update daily and per order.
Three features of this material directly affect multi-turn prompts. The return window and the return grading state define which status descriptions a reply may cite. Carrier tracking and settlement bills come from different systems, so the fee fact and the logistics fact for one order are checked separately. When an after-sales specialist and an operations colleague share one conversation, the retained history turns carry earlier commitments into later answers.
The existence of these records does not mean the system holds authorization to execute a refund, file an appeal or write to settlement. Retrieval returns material; it does not grant permission. A form collects values; business verification, approval, database writes and external synchronization each need their stated downstream implementation.
Constraints at the multi-turn prompts step
A prompt states the material scope, the answering task, and how to behave when evidence is missing, so the model does not write business facts that the records do not contain. The history setting is checked against the context actually carried in, and a new conversation is distinguished from a continued one. Question optimization is checked only in the knowledge-base continuous-conversation case, for pronoun resolution and question expansion.
Model and length settings are checked against the context and reply limits the chosen model supports. Reply format follows the downstream consumer; when json_schema is selected, the matching format requirement is filled in and the returned structure is verified. A relevance score in retrieval results is not a permission or entity filter, and retrieval is not authorization.
An interactive node returns a display configuration containing only type and params. A form collects values. Submission, approval and external synchronization are separate facts.
Hypothetical paper exercise: the source material reads "Return R-2024-0512, product A, return window closes 20 May 2024, return grading status pending review, carrier tracking shows pickup on 14 May." The draft sentence under review reads "This order has passed return grading, and the refund will complete within 3 business days." The subject, object, status and validity scope needed for the judgment are all present: subject is return R-2024-0512, object is product A, status is pending review, scope is within the return window. Pending review is unsupported as a pass; the draft writes it as passed and adds a refund timeline.
Configuration and implementation checks
| Configuration | Hypothetical starting point for this exercise | Reason and comparison method |
|---|---|---|
| Memory turns | Retain a small number of history turns | The document states that customer-service and knowledge-base applications usually keep a small number of history turns. Compare with a session that retains no history to observe whether earlier commitments are carried in incorrectly. |
| Temperature | Low | The document states that customer service and knowledge-base answering suggest a low value. Compare with a higher value to observe reply stability. |
| Reply limit | Set to the reply need | Compare with a value that is too long or too short to observe truncation or excess. |
| Reply format | Keep default | Ordinary customer-service answering keeps the default. Change to json_schema with a filled format requirement only when a downstream step reads a fixed structure. |
| Multimodal recognition | Enable by model capability | Enable only for media types the model supports. Media links in a user question are parsed only after extracting multimodal files from links is enabled. |
| Thinking configuration | Default | The document states that Default uses the model default. Compare with no-thinking or a higher thinking strength to observe reply behaviour. |
All values above are hypothetical starting points for this exercise, not official defaults.
Three common errors
- Writing a pending-review status as passed. Input is the return grading status "pending review" for return R-2024-0512; comparison is the draft sentence's "has passed return grading"; the observable result is that the two status values do not match.
- Treating retrieval results as authorization. Input is a quoteList returned by one knowledge-base retrieval; comparison is the authority to execute a refund or appeal; the observable result is that the retrieval result carries no authorization field.
- Treating an interactive node display configuration as submitted. Input is the type and params returned at event=interactive; comparison is whether the form has been submitted; the observable result is that the display configuration contains no submission result.
How to verify the setup
- For the hypothetical exercise, input the source material and the draft sentence, compare the status description in the draft against "pending review" in the source, and observe that the draft does not match the source status and must be rewritten as pending review.
- For the hypothetical exercise, input a handover request that asks to execute a refund, compare the authorization source in the request against what the session already contains, and observe that the session holds no authorization field, so the request stays pending verification.
- For the hypothetical exercise, input a short follow-up "what about this one", compare pronoun handling with question optimization enabled and disabled, and observe that the two settings carry in different context; when disabled, do not assume the pronoun has been resolved.
All three verifications are paper checks only and were not executed.