Retail checkout and loyalty: multi-turn prompts for after-sales questions

What the documents look like

Order fulfilment and after-sales support in retail checkout and loyalty draws on the point-of-sale system, the membership CRM, the payment platform and the price-tag system. The working documents are promotional price tags, membership points rules, the daily checkout report and exception refund slips. Promotional price tags and membership points rules determine the amount charged and the member benefit, while the daily checkout report and exception refund slips record discrepancies and after-sales requests. These materials update daily and per shift, which affects how quickly a discrepancy can be reconciled. That cadence does not change how the multi-turn prompt feature is invoked.

In this setting a multi-turn conversation carries three kinds of follow-up: price, points and refund. The model has to keep apart the values for the same member, the same period and the same field before it can judge whether two materials conflict. The prompt must 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.

Constraints at the multi-turn prompts step

Prompt design needs to name the document range, the answer task and the handling of missing evidence. History handling requires checking which context is actually carried in, and separating a new session from a continued session. Question optimisation for continuous knowledge-base dialogue requires checking reference resolution and question expansion; whether a short question applies depends on the actual configuration. Model and length settings require checking the supported context and reply configuration and testing long documents combined with follow-ups. Reply format follows the downstream consumer; choosing json_schema requires filling in the corresponding format requirement and validating the returned structure.

Retrieval is the process of fetching material and does not perform authorisation. A similarity score is not a member filter or a store filter. Interactive nodes return a display configuration; forms collect values, and business verification, approval, database writes and external synchronisation each need their own downstream implementation.

Hypothetical paper exercise: the source material reads, "From 8 March 2025 to 10 March 2025, the member-day double points apply to members who have bound a mobile number; in the same period a promotional price tag marks a certain beverage at 3.9 yuan per unit; the daily checkout report shows 2 units of that beverage were returned on 9 March; the exception refund slip records the refund reason as a mismatch between the price tag and the checkout price." The draft sentence to be judged is, "This member completed the double-points backfill on 9 March, and the refund has completed approval." The sentence touches subject, period, field and authorisation state, each of which needs item-by-item checking.

Configuration and implementation checks

The table below lists documented settings or implementation checks relevant to this feature and task, tied to the sample above. The values are starting points for this paper exercise, used for comparison, and are not official default values.

Three common errors

1. Treating retrieval similarity as a member or store filter. The input is a retrieval request against the membership points rules; the comparison is between the similarity setting and the member identity field; the observable result is whether returned content still contains records of other members or other stores. A similarity score does not carry permission or entity isolation; permission needs a downstream implementation.
2. Treating the display configuration returned by an interactive node as a submitted form. The input is a request that returns a userInput interactive node; the comparison is between the returned inputForm fields and the actual input values in the following request; the observable result is whether the following request carries values matching the form keys. A form collects values; business verification and writes need separate implementation.
3. Writing a refund request that is pending review as a completed refund. The input is the exception refund slip in the sample; the comparison is between the status field on the slip and the completion wording in the draft sentence; the observable result is whether the status field clearly states completion. Pending review does not constitute completed approval.

How to verify the setup

1. Against the sample source material, enter the follow-up "Has this member's points for 9 March been backfilled", compare whether the answer relies only on the period and member scope stated in the material, and observe whether the answer contains a backfill-completion wording not stated in the material. If it appears, the condition is not met.
2. Against the draft sentence "This member completed the double-points backfill on 9 March, and the refund has completed approval", enter the sentence together with the source material, compare subject, period and field for consistency, and observe whether the completion state in the draft sentence can be found as an explicit value for the same field in the material. If it cannot be found, the sentence is unsupported.
3. Against empty-result handling, enter a paper retrieval request whose result is empty, compare whether the downstream node is designed with a branch for the empty result, and observe whether the downstream still requires the model to write business facts. If it does, the condition is not met.

All of the above is paper checking. No actual deployment, approval or refund was executed.

Related reading

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