What the documents look like
Ratings maintenance handles consumer feedback after after-sales fulfillment, not the pricing decisions that belong to campaign enrollment. The working data comes from platform experience scores, marketplace service indicators, after-sales ratings, and the customer service system. Four document families recur: negative-review handling records, experience-score breakdowns, service diagnostic reports, and rectification ledgers. These update daily or weekly, and that cadence matters here because a handover can move a conversation log and a ledger entry that were last touched on different days.
The conversation-log and audit step has to tie customer service conversations back to those business records. The operator confirms which conversation is the target, reads the run detail, and checks what each returned field actually means. Experience-score movement affects search weight, campaign eligibility, and store conversion, so a handover that treats a retrieval result or a submitted form as completed authorization leaves a permission gap that surfaces later. This page covers one slice: seller ratings maintenance, operations permission and handover management, conversation logs and audit. It does not decide whether a negative review is closed, and it does not perform reconciliation, retention, or compliance work, which belong to a fuller business plan.
Constraints at the conversation logs step
Conversation identity depends on chatId to match the target conversation against the business record. Sessions that arrive through different entry points cannot be counted as one. When run detail is needed, detail must be set according to the official contract, and the module status and complete results inside responseData are then inspected. The fields the interface actually returns define the scope of what can be retained in the log; business data that is not returned cannot be assumed to have been retained in full. Identity fields may differ between test mode and a production call, so input, history, and returned content are checked separately for each. Reconciliation, retention, and compliance requirements are carried out by a complete business plan; the presence of a log does not mean a compliance audit has been completed. Operations permission and handover management must separate behavior a node already has, fields that can actually be configured, manual verification actions, and business actions that require a separate system implementation.
Hypothetical drill sample: a store operator is handing over a batch of negative-review handling records. The source material reads: "From March 1 to March 7, 2025, customer service system sessions with chatId A1001 through A1050; A1007 corresponds to the negative review for order 20250303-001, handling status is contacted consumer for supplementary evidence, and the rectification ledger has no completion time recorded." The handover request to be judged reads: "Transfer the conversation log for A1007 together with the rectification ledger to the quality inspector, and confirm that this negative review is closed." In this sample the parties are the store operator and the quality inspector, the objects are the A1007 conversation and the rectification ledger, the status is contacted but no completion time recorded, and the effective scope is the stated date range and chatId range.
Configuration and implementation checks
The table below lists official documented settings or implementation checks relevant to this feature and primary task, tied to the sample above. The values are starting points for this hypothetical drill only, with the comparison object stated.
| Configuration item | Hypothetical starting point | Verification method |
|---|---|---|
| appId and chatId correspondence | Use the appId that owns A1007 in the sample | Compare against the chatId range in the source material and confirm uniqueness under the same application |
| detail value | Set to true | Compare against module status and complete results in responseData to confirm run detail is readable |
| responseChatItemId | Assume A1007-R1 | Compare against existing response message IDs under the current chatId and confirm uniqueness |
| loadCustomFeedbacks | Set to true | Compare against the customFeedbacks field returned by the conversation list to confirm feedback is readable |
| Handover authorization status | Not stated in the material | Compare against the completion time field in the rectification ledger; an unrecorded value remains pending verification |
| Audit retention scope | Not stated in the material | Compare against fields actually returned by the interface; unreturned items are recorded as gaps |
Three common errors
- Treating every session inside the chatId range as one business record. The input is A1001 through A1050, the comparison object is the order tied to A1007, and without checking chatId against order number line by line, unrelated sessions enter the handover material.
- Treating "contacted consumer for supplementary evidence" as a closed negative review. The input is the handling status field, the comparison object is the completion time in the rectification ledger, that field is unrecorded, and the judgment is pending verification.
- Treating a retrieval result or a submitted form as executed authorization. The input is the conversation-log query result, the comparison object is the quality inspector's handover authorization record, and retrieval and collected form values do not constitute authorization, so the business action cannot proceed while the authorization record is absent.
How to verify the setup
- Input the source material text and the chatId for A1007. Compare against the uniqueness of that chatId under the same appId. The condition is met when the chatId returned by the interface matches the material and shows no duplicate.
- Input a request with detail=true. Compare against module status and complete results in responseData. The condition is met when the run detail fields are present and correspond to the conversation list record.
- Input the handover request to be judged together with the rectification ledger field. Compare against the registration state of the completion time. The ledger completion time remains empty, the judgment is not supported, and the evidence gap is retained pending a supplementary entry.