What the documents look like
Store rating and experience-score work for platform e-commerce draws on materials produced after order fulfilment: Douyin Shop experience scores, Tmall service indicators, JD after-sales reviews, and customer-service system records. The daily documents are negative-review handling records, experience-score detail sheets, service diagnostic reports, and rectification ledgers. Compared with platform promotion registration, rating maintenance concentrates on consumer feedback after after-sales fulfilment and does not directly set campaign prices. The brief gives daily and weekly update rhythms. It does not support batch synchronisation, full synchronisation, real-time or transaction-triggered mechanisms, so this page does not assume any of them.
When these materials enter a workflow, the subject is a store or an order, the object is a negative review, an indicator, or a rectification item, and the states include awaiting attribution, awaiting supplementary evidence, awaiting rectification, and awaiting review. The three most time-consuming steps are attributing negative reviews, contacting buyers for supplementary evidence, and tracking indicators after rectification.
Constraints at the workflow routing step
The Form Input node is a user-interaction node. When it triggers, the conversation enters an interaction state and the workflow state is recorded; after the user completes the required fields and submits, the node collects the submitted form information and passes it to later nodes. The User Selection node is also a user-interaction node: it enters the interaction state, and when the user makes a choice the node evaluates that choice and executes the "yes" branch. The recorded interaction state is behaviour of the interaction nodes; there is no separate global state-recording switch. Collected information must be explicitly passed to later retrieval, judgement, or interface nodes, and outputs must be compared item by item with inputs. Order writes, document backfill, and external status synchronisation require a separate business interface or a later process; retrieval and forms do not constitute authorisation to execute.
Hypothetical paper exercise: On 10 June 2025 a store customer-service supervisor submits a negative-review handling record. The source text reads: "Order A was signed for on 3 June; the buyer submitted a negative review on 5 June describing packaging damage; customer service contacted the buyer on 6 June, the buyer provided unboxing photos, and customer service logged a reshipment request that day with the status awaiting warehouse confirmation." On the same day a handover request reads: "Based on the above record, change the rectification ledger status for Order A to completed and synchronise it to the experience-score detail sheet." In this request the reshipment request is awaiting warehouse confirmation, the rectification ledger states no basis for completion, and the experience-score detail sheet states no synchronisation field.
Configuration and implementation checks
| Configuration item | Relevant setting or implementation check on this page | Relation to the exercise |
|---|---|---|
| Form Input node | Enters the interaction state on trigger, collects required fields, passes them to later nodes after submission | Collects fields needed for negative-review attribution, such as order number, signing date, review date, evidence type |
| User Selection node | Executes the corresponding "yes" branch after the user makes a choice | Branches on "is warehouse confirmation present"; verify each branch connection |
| Output handover check | Explicitly passes collected information to later retrieval, judgement, or interface nodes | Compare form output with rectification ledger fields for consistency |
| External action separation | Order writes, document backfill, and external status synchronisation require a separate business interface or later process | Experience-score detail synchronisation is not completed inside the form node |
| Hypothetical trial starting value | This exercise sets "awaiting warehouse confirmation" as the initial value of the rectification ledger status, because that value comes from the source text; compare it with "completed" to judge whether the change condition is met | Used to verify whether the status field is altered in error |
| Interaction state check | The recorded state is behaviour of the interaction nodes; no separate global state-recording switch | Check whether the workflow continues downward after form submission |
Three common errors
- Treating the "reshipment request" collected by the form as completed rectification. The source text states the status is "awaiting warehouse confirmation"; that value and "completed" are mutually exclusive on the same field. Form submission shows only that information was collected, not that the warehouse confirmed.
- Treating "synchronise to the experience-score detail sheet" in the handover request as executed. The request only asks for synchronisation; the detail sheet states no synchronisation field, and external status synchronisation requires a separate business interface or later process. A pending review does not show that an operation permission is absent.
- Treating the "yes" branch of the User Selection node as automatic judgement. In the exercise, "is warehouse confirmation present" must be checked manually against the source text; the node executes a branch according to the user's choice and does not judge by itself whether warehouse confirmation exists.
How to verify the setup
- Input the source text "Order A was signed for on 3 June; the buyer submitted a negative review on 5 June ... status awaiting warehouse confirmation". Compare the rectification ledger status field with "completed" and observe whether the field is still "awaiting warehouse confirmation". If it still holds the original value, the form did not overwrite the status beyond its scope.
- Input the handover request "Based on the above record, change the rectification ledger status for Order A to completed and synchronise it to the experience-score detail sheet". Compare the synchronisation action in the request with the actual fields of the experience-score detail sheet and observe whether a new synchronisation record appears there. If none appears, external synchronisation was not performed by the form node and requires a separate interface.
- Input the User Selection node question "is warehouse confirmation present". Compare the user's selection with the "yes" branch connection and observe whether the branch executes according to the selection. If the selection is "no", the workflow should follow the other branch; record the actual observation without guaranteeing a first-hit match or full recall.
Retrieval checks must verify the knowledge-base identifier and the embedding model; bases using different embedding models cannot be associated together, so check identifiers first and exclude those that do not match. For empty-result handover, a clearly stated paper input of [] can be used to check the downstream design; it cannot be claimed that a fictional rule retrieval necessarily returns []. The optional paths shown in the overall document flow diagram do not mean every request executes all of them; image retrieval requires a corresponding image input and model capability, and reranking requires the model to be present and enabled according to settings.