Marketplace returns: multi-turn prompts for copy drafting

What the documents look like

Platform refunds and returns occur order by order, and an ordinary platform refund does not necessarily connect to a promise made in a single livestream session. The drafting team therefore checks materials that arrive from the after-sales backend, customer service chat, WMS receiving, and payment refund records, with updates per order. Four document types carry the working evidence: the refund application, the return logistics slip, the quality-inspection photo, and the refund approval. From these, staff judge return responsibility, chase the returned parcel, and approve the refund amount before deciding which promotional sentences in a product and marketing draft can stay and which need rewriting. When a draft sentence goes beyond what the materials support, the outcome can include platform intervention, a consumer complaint, or loss of the payment amount. Each turn of a multi-turn conversation must therefore separate the history that is actually carried in from the input of a new session.

Constraints at the multi-turn prompts step

The prompt needs to state the material scope, the answering task, and how to behave when evidence is missing, so the model does not write business facts on its own. For history, check the context that is actually carried in and distinguish a new session from a continued session. For question optimization, check reference resolution and question expansion when a knowledge base is used in continuous conversation, and do not assume every short question fits that treatment. For model and length, check the context and reply settings the model supports, and test long documents combined with follow-up questions. For reply format, choose the format according to what comes downstream; when json_schema is selected, fill in the corresponding format requirement and verify the returned structure. A similarity score expresses textual relatedness only and does not carry permission or entity isolation, and retrieval itself is not authorization.

Hypothetical drill sample: the material text reads "The refund application status for this order is pending review, the return logistics slip shows signed for, the quality-inspection photo records outer packaging damage, and the refund approval field is blank." The draft sentence to be judged reads "This product supports seven-day no-reason returns, and damage is refundable." The check compares the subject, object, status, and valid scope of the draft sentence against the material text. The material covers only this order's refund application, logistics signature, and quality-inspection photo. It does not state a seven-day no-reason rule or a damage-refundable promise, so the draft sentence is unsupported and must go back for additional material or be rewritten.

Configuration and implementation checks

The values above are assumed trial starting points for this page. The reason is the need for stable wording and complete output in customer service and copy drafting scenarios, and the comparison object is the actual output from the same material. They do not represent official defaults.

Three common errors

1. Treating a similarity score as a permission or entity filter. The input is a returned score together with different dataset identifiers; the comparison object is the retrieval scope the current session is entitled to access; the observable result is that a higher or lower score does not change the set of accessible records, and datasetId plus the authorization scope must be checked separately.
2. Writing a pending-review status as already approved or already refunded. The input is "the refund approval field is blank" in the material text; the comparison object is the refund promise in the draft sentence; the observable result is that a blank approval field does not support a completed refund, so wording that keeps the matter pending verification must remain.
3. Associating retrieval libraries built on different vector models. The input is two library identifiers that use different vector models; the comparison object is the model identifier field of each library; the observable result is that libraries with inconsistent identifiers cannot be associated together, so the identifiers must be checked first, non-matching libraries excluded, and the actually observed retrieval results recorded.

How to verify the setup

1. Use the hypothetical sample material text and draft sentence. The input is "The refund application status for this order is pending review, the return logistics slip shows signed for, the quality-inspection photo records outer packaging damage, and the refund approval field is blank." The comparison object is the draft sentence "This product supports seven-day no-reason returns, and damage is refundable." The observable result is that the rule and promise in the draft sentence are not stated in the material, and when that condition holds the sentence is judged unsupported while the evidence gap is preserved.
2. Use the paper input [] as an empty retrieval result. The comparison object is the downstream handling design. The observable result is that the downstream stage can handle an empty result and indicate insufficient material. This does not claim that a retrieval for an invented rule will necessarily return an empty array.
3. Use the same material for two consecutive follow-up turns. The input is the first-turn draft sentence and the second-turn follow-up question; the comparison object is the number of history turns carried in and the new question; the observable result is that the second turn does not mistake new-session input for continued-session context and that the reply format meets the downstream requirement.

Related reading

• guide/build/general/ai_settings
• openapi/chat
• FastGPT multi-turn prompts