On-demand retail fulfillment: multi-turn prompts for after-sales questions

Review multi-turn prompts for after-sales questions in On-demand retail fulfillment. Check input mappings, source evidence and failure handling before use.

What the documents look like

On-demand retail store fulfillment processes online orders by the minute rather than through periodic stock counts. The working materials are instant orders, picking lists, out-of-stock reports and delivery exception forms. Data sources include Douyin instant retail, Meituan or JD Daojia back-office records, store inventory and rider tracking. This page addresses one task inside that setting: order fulfillment and after-sales question answering, using multi-turn dialogue and prompts.

A single follow-up question can touch an order number, picking progress, a substitution plan for a missing item and a delivery status at the same time. The prompt must state the material scope, the answering task and how to behave when evidence is absent, so the model does not write business facts that the records do not contain. History is carried in according to the memory round setting, and a continued session has different inputs from a new session. Where continuous question answering over a knowledge base is used, coreference resolution and question expansion need checking; short questions do not automatically qualify. Model and length follow the maximum context and reply limit settings, and long documents combined with follow-ups need testing. Reply format follows what the downstream stage consumes; when json_schema is selected, the corresponding format requirement is filled in and the returned structure is checked.

Constraints at the multi-turn prompts step

The material scope, task statement and missing-evidence handling belong in the prompt itself. Retrieval is not authorization. A knowledge base hit does not grant permission to act, and a similarity score is not a category, entity or permission filter. An interactive form collects values; business verification, approval, database writes and external synchronization require their own downstream implementation.

Hypothetical drill sample: the source material reads "Instant order A-20240513-07, the store has completed picking, the rider collected at 14:20, the delivery exception form records that at 14:35 the rider reported the customer's address gate could not be entered, customer service called the customer at 14:40 with no answer, and the order status is in delivery." The draft sentence under review is "This order is confirmed delivered and a refund can be initiated." That sentence conflicts with the in-delivery status in the material, and neither delivery nor refund is supported.

Configuration and implementation checks

Configuration itemHypothetical starting point for this drillReason and comparison method
Memory roundsHypothetical start of 4 roundsCustomer service applications usually keep a small number of history rounds; compare whether follow-up references resolve at 2 rounds and at 4 rounds
Reply limitHypothetical start at medium lengthFulfillment answers need to list status and missing-evidence items; compare truncated output against complete output
TemperatureHypothetical start on the low sideCustomer service and rule-bound scenarios give steadier answers; compare output differences across repeated runs of the same input
Reply formatDefault textKeep the default when no downstream stage reads a fixed structure; when json_schema is selected, fill in the format requirement
Multimodal recognitionEnable image per model capabilityScreenshot-type evidence needs image recognition; when the model does not support it, the option is not shown
Hide AI outputDecide by downstream consumptionEnable when a later node rewrites the answer; compare what the user can see

Three common errors

  1. Writing "delivered" for the "in delivery" state in the material. Input: the hypothetical sample source text above. Compare the order status field. The draft sentence is non-conforming as soon as it states a delivery conclusion.
  2. Treating a retrieved order record as refund authorization. Input: the knowledge base search result. Compare whether separate refund approval material exists. With only the search result, authorization is not supported.
  3. Treating a similarity score as a permission filter. Input: a quote list carrying score. Compare record ownership against the caller's permissions. A high or low score does not change the accessibility of an unauthorized record.

How to verify the setup

  1. Input the hypothetical sample source text above together with the draft sentence "This order is confirmed delivered and a refund can be initiated." Compare the draft conclusion against the material's status field. The expected output states that in delivery and delivered disagree and that the refund is not supported.
  2. Input the hypothetical sample source text above together with the request "Please refund directly." Compare whether refund approval or authorization material exists. The expected output states that the request is pending verification and is not treated as executed.
  3. Input the paper empty result [] together with the downstream consumption design. Compare whether the downstream stage handles the missing-evidence branch. The expected output preserves the gap rather than writing in business facts.