Franchise fee settlement: multi-turn prompts for after-sales questions

Review multi-turn prompts for after-sales questions in Franchise fee settlement. Check input mappings, source evidence and failure handling before use.

What the documents look like

This page covers four document types in franchise fee and deposit settlement: franchise fee invoices, deposit ledgers, deduction notices, and contract payment schedules. The work belongs to order fulfilment and after-sales question answering, where a user may ask several follow-up questions about the same settlement item.

Compared with franchise filing administration, fee settlement focuses on funds and breach deductions, and does not handle government filing. The amounts, payment terms, and deduction reasons that appear in a conversation therefore come from the finance system, the franchise contract, bank statements, and store violation records. The monthly update cycle and the per-deduction update cycle mean that a ledger and a deduction notice can sit in different states across turns. A multi-turn dialogue has to carry forward fields that were already confirmed in an earlier turn rather than re-deriving them.

The four materials also differ in what they can support. A deposit ledger states a balance. A deduction notice states a reason and an amount. A contract payment schedule states an amount due and a deadline. None of these documents, on its own, confirms that a payment was received.

Constraints at the multi-turn prompts step

The prompt must state the document scope, the answering task, and how to handle missing evidence, so the model does not write business facts that the materials do not contain. History settings need checking against the context actually passed in, and a new session must be distinguished from a continued session. When the knowledge base is used across turns, check that references are resolved and that question expansion is applied only where it fits. Model and length settings need checking against the context and reply configuration, and long documents should be tested together with follow-up questions. Reply format follows the downstream consumer; when json_schema is selected, the format requirement must be filled in and the returned structure verified.

Hypothetical paper exercise: the source text reads, "Franchisee A deposit ledger for March 2025 shows a balance of 50,000 yuan; a deduction notice dated 12 March 2025 states a deduction of 8,000 yuan for a store violation, the reason being cross-region supply; the contract payment schedule states that the March 2025 franchise fee of 20,000 yuan is due by 31 March." A draft sentence reads, "A's March deposit has been deducted 8,000 yuan, leaving 42,000 yuan, and the franchise fee is settled." The point to judge: whether the franchise fee is settled has no corresponding receipt record in the materials, so that part is unsupported.

Configuration and implementation checks

Configuration itemHypothetical starting pointReason and comparison method
Memory turns4 turnsCovers the ledger, deduction, and payment schedule follow-ups; compare with 2 turns to see whether the deduction reason is lost
TemperatureLowCustomer service and rule-based scenarios need stability; compare with a higher setting for consistency on the same follow-up
Reply limitEnabled and boundedPrevents truncation of the deduction reason; compare with no limit to see whether a long follow-up stays complete
Reply formatDefaultNo downstream structured read is required; if changed to json_schema, fill in the format requirement and verify the returned structure
Multimodal recognitionOffThe materials are text fields; before enabling, confirm model capability and media input
Thinking configurationDefaultNo complex reasoning is required; after switching levels, compare whether the answer introduces facts outside the materials

These values are hypothetical starting points for this exercise, not official defaults.

Three common errors

  1. Treating the 8,000 yuan in the deduction notice as evidence of a change in the deposit balance, while ignoring that the ledger's 50,000 yuan is the pre-deduction state. Check: input the ledger source text and the deduction notice source text, compare the subject, date, and field name of the two amounts, and observe whether a post-deduction balance is stated anywhere in the materials.
  2. Treating "the franchise fee is settled" in the draft sentence as a confirmable fact. Check: input the contract payment schedule source text, compare whether a corresponding receipt record field exists, and observe whether that field is empty or not stated in the materials.
  3. Treating a form display returned by an interaction node as business execution. Check: input the interaction node configuration, compare the form fields with the actual deduction action, and observe whether any downstream write or synchronization record exists.

How to verify the setup

  1. Input the three source passages from the hypothetical exercise and the draft sentence, compare each clause of the draft sentence against the source text for the same subject, same period, and same field, and observe whether "the franchise fee is settled" is marked unsupported and whether the post-deduction balance is marked as pending verification.
  2. Input two consecutive follow-up turns under the same chatId, compare whether the second turn refers to the deduction reason from the first turn, and observe whether the reason is retained when memory turns is set to 4 and lost when set to 2.
  3. Input an empty result [] together with one unrelated query, compare the downstream handling design, and observe whether the empty handling is returned as designed, without assuming that an unrelated query must return empty.

This page addresses only franchise fee and deposit settlement, order fulfilment and after-sales question answering, and multi-turn prompts. Retrieval and form submission are not authorization; business verification, approval, database writes, and external synchronization require their stated downstream implementation.