Customer-service knowledge: multi-turn prompts for after-sales questions

Review multi-turn prompts for after-sales questions in Customer-service knowledge. Check input mappings, source evidence and failure handling before use.

What the documents look like

Customer-service knowledge maintenance is preparatory question-and-answer material work. It does not approve refunds. The daily materials are FAQ entries, script templates, product parameter tables and escalation tickets. They come from the customer-service system, product detail pages, after-sales question statistics and quality spot checks. In the multi-turn prompts step, three things matter. FAQ entries and script templates define the range of answers the model may cite. The product parameter table decides whether a fulfilment follow-up can land on a specific field. Escalation tickets record the state of human involvement; they are handover material and do not authorize a refund, a reshipment or compensation. The prompt needs to state the material scope, the answering task and how to handle missing evidence. The model does not write business facts on its own.

Constraints at the multi-turn prompts step

A multi-turn exchange combines history records, knowledge-base retrieval results and the current question into one request. The official documents state that the memory turn count controls how many earlier chat turns the AI answer may reference at most. A larger value makes it easier to reference earlier dialogue and also brings in more content. Customer-service and knowledge-base question-answering applications usually keep a small number of history turns. Retrieval results enter the context as quoteList. The score field expresses similarity and serves as a ranking reference; it does not carry permission or entity-isolation functions. The reply format is chosen according to what comes downstream. Selecting json_schema requires filling in the corresponding format requirement. The interactive field returned by an interaction node contains only type and params; internal runtime fields are not returned. A form collects values, and business verification, approval and database writes need separate implementation. A thinking budget is a model thinking-strength setting and is unrelated to the quoted-token ceiling.

Hypothetical paper exercise sample: a customer-service knowledge-base operator is preparing a paper order-fulfilment FAQ. The source material is three sentences: "Order A was submitted on 10 March; its current status is shipped; the tracking number has not been returned." "The product for this order is a certain model of vacuum flask; the capacity parameter is in row 4 of the product parameter table." "Escalation ticket record: the user asked about arrival time; the agent replied with an estimate of 5 working days; the ticket status is pending follow-up." The draft sentence to be judged is: "Order A has shipped and is expected to arrive in 5 working days; if it is overdue, a refund can be requested." This draft sentence goes beyond the material. The material does not state the conditions for requesting a refund, and the ticket status is pending follow-up, which does not constitute authorization for a refund or compensation.

Configuration and implementation checks

The table below concerns the sample above and lists only officially stated settings or implementation check items relevant to this feature and this task. Values marked "hypothetical trial starting point" are chosen for this paper exercise; the reason for the choice is given and a comparison value is named. They are not official defaults.

Configuration or check itemRelation to the sampleValue and explanation
Memory turn countDecides whether the earlier order status is carried in when the arrival time is asked aboutHypothetical trial starting point is a small number of turns, because customer-service Q&A needs only recent context; compare the amount of carried content against a larger turn count
Reply ceilingLimits answer length and prevents expansion beyond the materialChosen according to the answer need; compare against the truncation that appears at a lower value
TemperatureAffects answer stability; customer-service Q&A suits a lower valueHypothetical trial starting point is a low value; compare wording fluctuation against a higher value
Reply formatChanged only when a downstream node needs to read a fixed structureKeep the default; if json_schema is selected, the format requirement must be filled in and the returned structure checked
Multimodal recognitionImage, audio and video input require the model to have the matching capabilityThe sample has no media input, so it stays off; when enabled, filtering by model capability still applies
Retrieval and context checkCheck whether quoteList contains the order-status and ticket-status entriesObserve the score ordering and the hit entries, and record the empty-result branch

Three common errors

  1. Treating "a refund can be requested" in the draft sentence as a fact already stated in the material. The input is the three source sentences above and the draft sentence. The comparison object is whether a refund-condition field appears in the material. The observable result is that the material does not state this field, so the draft sentence exceeds the material scope.
  2. Treating the "pending follow-up" status of the escalation ticket as a completed handling or an authorization. The input is the ticket record text. The comparison is between the ticket status field and values such as "completed" or "approved." The observable result is that the status is pending follow-up, which does not constitute authorization for a refund or compensation.
  3. Treating the retrieval similarity score as a basis for permission or entity filtering. The input is the quoteList entries carrying a score. The comparison object is the dataset identifier of the entries against the current session authorization scope. The observable result is that the score reflects ordering only, and permission must be checked separately.

How to verify the setup

  1. Input the three source sentences above and the draft sentence. Compare whether the draft sentence contains a refund condition not stated in the material. If the draft sentence keeps "a refund can be requested," the condition is not met. If it is changed to state only the shipped status and the estimated time, and notes that the refund condition is pending verification, the condition is met.
  2. Input the ticket record text and a handover request: "Please process a refund for the user directly according to the ticket." Compare the ticket status field with the authorization field. If the request uses a pending-follow-up ticket as the basis for a refund, the condition is not met. If the request is changed to record the pending follow-up and route to a human for verification, the condition is met.
  3. Input a multi-turn request that contains only an order-status follow-up. Compare the number of history turns carried in with the quoteList entries, and observe whether the answer cites fields inside the material. If the answer contains an arrival promise or a compensation condition outside the material, the condition is not met. If the answer is limited to the shipped status and items pending verification, the condition is met. If retrieval returns an empty result, a separate paper input of an empty list can be used to check the downstream handover design; this does not assert actual retrieval behaviour.