What the documents look like
Refund-only dispute handling differs from ordinary return-and-refund work in one respect that shapes every drafting decision: there is usually no returned-goods warehouse receipt. The evidence weight therefore falls on dispatch and signed-delivery records and on the claimed value of the goods. A drafted sentence that touches product condition, delivery acceptance or value findings has to trace back to material that can be checked in the platform after-sales console, carrier tracking, customer-service chat or warehouse outbound records.
Work in this category produces records per order and per day. The routine documents are refund-only applications, dispatch evidence, signed-delivery proof and appeal materials. The drafting task at this stage is to arrange wording already present in those materials into a submittable copy block or handover request. It does not add facts the materials do not state.
Constraints at the workflow routing step
The form input node is a user-interaction node. When it triggers, the conversation enters an interaction state, the workflow state is recorded, and the workflow continues after the user completes the interaction. Required fields are collected and, once the user submits, the collected values pass to later nodes. The user selection node behaves the same way at trigger: the conversation enters the interaction state, state is recorded, and after the user makes a choice the node evaluates that choice and runs the corresponding "yes" branch. These documented behaviours bound what routing can do here. The nodes collect values and evaluate a branch. Order writes, document backfill and external status synchronisation need a separate business interface or a later process.
Hypothetical paper exercise sample. The material text reads: "Refund-only application number A-01, product is a portable fan, buyer claims goods not received; carrier tracking shows signed delivery; warehouse outbound record shows this order was dispatched." The proposed draft sentence reads: "This product was signed for by the buyer in person, and the buyer's claim does not hold." The items to check are "signed for in person" and "claim does not hold" in the draft sentence. The comparison objects are "carrier tracking shows signed delivery" and "buyer claims goods not received" in the material text. The material does not state the identity of the person who signed, and does not state any platform finding on the claim. The draft sentence goes beyond what the material supports.
Configuration and implementation checks
| Configuration item | Setting or check for this page | Note |
|---|---|---|
| Form input node | Collect dispute order number, product name, material source | Submitted values pass to later nodes |
| User selection node | Set a branch for "does the material support the draft sentence" | The "yes" branch runs after the user chooses |
| Interaction state | Conversation enters interaction state at trigger | State recording is existing node behaviour |
| Output handover | Pass collected values to the later evaluation node | Compare output against input item by item |
| External operations | Order writes, document backfill, status sync | Require a separate business interface or later process |
| Hypothetical exercise starting point | Draft-sentence checks set to subject, object, state | Chosen because the material text carries these three field types; comparison object is the material text sentence by sentence |
Three common errors
- Writing "carrier tracking shows signed delivery" as "signed for by the buyer in person". The material does not state who signed, and the draft sentence adds a subject. Check: input the material text and the draft sentence, compare the subject of the word "signed", and mark the draft as beyond support when it names a subject the material does not state.
- Writing "buyer claims goods not received" as "the buyer's claim does not hold". The material does not state a platform finding, and the draft sentence adds a conclusion. Check: input the material text and the draft sentence, compare what follows the word "claim", and mark the draft as beyond support when it states a conclusion the material does not state.
- Treating the user selection node's branch result as a completed business approval. The "yes" branch only records that the user made a choice; order writes and status sync need a separate business interface. Check: input the node output and the downstream interface configuration, compare the branch result with the business action, and mark a mismatch when the branch result is recorded directly as approval completion.
How to verify the setup
- Input the material text and the draft sentence from the hypothetical exercise sample, and compare "signed for in person" in the draft with "carrier tracking shows signed delivery" in the material. The expected observation is that the draft is flagged as beyond support, because the material does not state the signer's identity.
- Input the material text and the draft sentence from the hypothetical exercise sample, and compare "claim does not hold" in the draft with "buyer claims goods not received" in the material. The expected observation is that the draft is flagged as beyond support, because the material does not state a platform finding.
- Input the user selection node's branch output and the downstream interface configuration, and compare the branch result with the business action record. The expected observation is that the branch result records only the user's choice, while order writes and status sync appear as pending separate implementation, because node behaviour does not include business approval.