What the documents look like
Ratings and experience-score maintenance depends on consumer feedback that arrives after fulfillment. The main sources are store experience scores, marketplace service metrics, after-sales ratings, and customer-service systems. These records update daily or weekly, and the working documents are negative-review handling records, experience-score detail sheets, service diagnostic reports, and remediation ledgers. Conversation logs and audit support this category by confirming session identity and preserving run details, giving operating reports a traceable conversational basis and helping locate responsibility during an anomaly review.
The most time-consuming steps are attributing a negative review, contacting the buyer for supporting evidence, and tracking post-remediation metrics. Each step requires aligning conversation records with business documents. A log entry that exists is not the same as a completed compliance audit; reconciliation, retention, and compliance requirements belong to a full business plan.
Constraints at the conversation logs step
Session identity relies on chatId and dataId. chatId identifies one conversation under an application, and dataId identifies one exchange under a conversation. Sessions created through different entry points stay separate in source terms: source=api retrieves only sessions created through the API and does not retrieve sessions from the page. Run details require setting detail according to the official contract; non-stream results are held in responseData, while stream results are distinguished through event. The fields an interface returns determine what the log actually contains, and business data that was not returned cannot be assumed to have been retained in full. Test-mode identity fields may differ from production calls, so inputs, history, and returned content need separate checks.
Hypothetical drill sample: a store operator wrote in a negative-review handling record dated 10 March 2026: "The buyer of Order A raised a refund request in the session, and the agent replied the same day that it would be forwarded to after-sales for verification." The same day's remediation ledger recorded: "Order A awaiting supplementary evidence, status pending review." A proposed handover request reads: "Based on the above conversation log, confirm that this negative review has completed remediation and can be used directly for an experience-score appeal." The sample materials show only forwarding and a pending-review status; they do not state completed remediation or appeal authorization.
Configuration and implementation checks
| Check item | Documented setting or implementation check | Relation to this page's sample |
|---|---|---|
| Session identity | chatId identifies a session under an application; dataId identifies an exchange under a session | Locate Order A's conversation with chatId and dataId |
| Session source | source=api retrieves only sessions created through the API | Check whether Order A's session came from the API entry |
| Run details | Set detail per contract; non-stream results appear in responseData | Retrieve node responses for Order A's exchange |
| Plugin output | Find the element with moduleType=pluginOutput and read pluginOutput | If the session contains a plugin node, locate output this way |
| Feedback fields | userGoodFeedback and userBadFeedback record likes and dislikes | Check whether Order A's exchange carries a dislike record |
| Authorization boundary | authProxy requires the team owner to enable it; the proxy identity still needs target-application and session permissions | Confirm whether the handover person holds permission for this session |
Hypothetical trial starting point: set pageSize to 20 for this paper check. The reason is that this value can cover Order A's same-day session volume, and the comparison object is the actual returned count against the ledger record count. This value is not an official default.
Three common errors
- Reading a pending-review status as completed remediation. The sample ledger states "awaiting supplementary evidence, status pending review," which is an unfinished process state and cannot serve as evidence of completed remediation. Check: input the remediation ledger text, compare the status field value against completed-type values, and observe whether mutually exclusive values exist; if only pending review appears, record the claim as unsupported.
- Treating a retrieval result as authorized execution. Retrieving a session record by chatId shows only that the record exists; it does not show that the handover person holds appeal permission. Check: input the handover request and the authProxy description, compare whether the proxy identity was enabled by the owner and holds target-application and session permissions, and observe whether permission fields are missing; a missing field is recorded as pending verification.
- Mixing test-mode identity fields with production calls. Test-mode identity fields may differ from production calls. Check: input the test and production request bodies separately, compare the value sources of appId and chatId, and observe whether the two value sets match; when they differ, the two must not be merged for calculation.
How to verify the setup
- Session identity check. Input Order A's chatId and dataId from the sample, compare the chatId and dataId in the returned records against the ledger's subject and period, and observe whether they point to the same session and the same exchange. The check is satisfied only when they point consistently.
- Run-detail check. Input Order A's dataId and set detail per contract, compare moduleName and moduleType in responseData against the node names recorded in the ledger, and observe whether the node responses correspond to the step described in the negative-review handling record. The check is satisfied only when they correspond consistently.
- Authorization-boundary check. Input the proposed handover request and the authProxy description, compare whether the handover person was enabled as a proxy by the owner and holds target-application and session permissions, and observe whether the permission description covers this session. The check is satisfied only when it is covered; when coverage is absent or unstated, keep it as an evidence gap and do not treat authorization as granted.