Lazada backend health data is not a total score but three lines—fulfillment, cancellation, and disputes—that are independent yet contaminate one another: incorrect inventory settings turn into seller-fault cancellations, more cancellations slow down the shipping pace, and shipping delays directly push up disputes and refunds. When troubleshooting, look first at the line with the most severe consequences, not the one with the best-looking numbers.
Break "account health" into three metric lines that contaminate one another
Fulfillment, cancellation, and disputes may be placed on the same backend page, but their causal direction is one-way. Inventory and pricing mistakes first create seller-fault cancellations; cancellations and out-of-stock items make the warehouse prioritize problem orders, squeezing the shipping timeliness of normal orders; after shipping delays, buyers are more likely to open disputes or request refunds directly. So when disputes rise, don't just have customer service suppress refunds—trace back to which batch of SKUs or which warehouse first went wrong.
A typical sign of the three lines contaminating one another is: you optimize customer service scripts, the dispute rate drops in the short term, but two weeks later seller-fault cancellations push fulfillment delays up again. This shows the root cause is still at the inventory or pricing level, and the customer service action only delayed the outbreak.
Troubleshooting order: trace back from the line with the most severe consequences
Don't start with the metric with the lowest percentage. Rank by platform enforcement consequences and fix it into four steps:
- First check disputes, refunds, and complaints.Check whether there are pending complaints, escalated complaints, or platform intervention. These metrics are directly tied to account restrictions and penalty points; first retain chat records, logistics tracking, and buyer acceptance or rejection proof. When the logistics liability segment is unclear, according toLogistics Lost Parcel Claim Process and Key Evidence ChecklistFirst, archive the evidence along a timeline.
- Then check fulfillment delays.Look at shipping time, pickup time, and orders not shipped on time. Break orders down by warehouse and logistics provider to determine whether it is insufficient stocking, insufficient packing capacity, or carrier pickup delays.
- Then check seller-caused cancellations.Look at the distribution of cancellation reasons: out of stock, pricing errors, address abnormalities, inventory synchronization delays. If certain SKUs appear repeatedly, delist them or switch them to pre-sale first, instead of continuing to wait for restocking.
- Finally, return to inventory and pricing settings.Check safety stock, pre-sale days, and the deduction order for multi-store shared inventory. What is being changed here is the rules, not urging the warehouse to “be a bit faster.”
The location of the three metrics in the backend, their statistical periods, and the stages they point to
The same metric can have completely different numbers under different statistical periods, so align the definitions before comparing. The entry names in the table below vary by site version; the current rules page in Seller Center shall prevail.
| Metric line | Common entry points in the backend | Differences in statistical periods | Main stages involved | Same-day evidence collection actions |
|---|---|---|---|---|
| Disputes, refunds, and complaints | Orders / After-sales / Performance dashboard | Counted by order creation date or settlement date; pending complaints and closed cases are counted separately | Customer service, logistics providers, product descriptions | Export disputed order numbers, chat records, and logistics tracking |
| Fulfillment timeout (shipping timeliness) | Orders / Logistics / Performance dashboard | By shipment action date or order creation date; whether to exclude pre-sale orders | Warehouse, stocking, and carrier pickup | Export overdue orders by warehouse and carrier |
| Seller reason cancellation | Order/cancellation reason report | By cancellation request date or order creation date; whether buyer-initiated cancellations are included | Inventory, pricing, multi-store sync | Export cancellation reason distribution, flag duplicate SKUs |
Data retrieval path annotation: for the same metric, the number changes when you switch the statistical period
“Yesterday it was 2%, today it’s 5%” is usually not a sudden deterioration of the account but a switch in definition: yesterday you were looking at the settlement-date basis, today at the order-creation-date basis; or yesterday included pre-sale orders and today they were excluded. Before every screenshot, first note three fields—metric name, statistical period, export time; otherwise the numbers in the weekly meeting cannot be compared.
Weekly trend interpretation: sudden fluctuations and structural deterioration should be handled separately
A single data point cannot determine an account trend; look at at least four weeks. A one-week spike usually corresponds to a single event: one order surge, one warehouse stockout, or one logistics provider capacity overflow. The response is to review the event and add temporary capacity or switch carriers. A slow upward climb for three consecutive weeks is a process flaw and requires changing the rules—for example, the safety stock algorithm, pre-sale days, or the multi-store inventory deduction sequence.
- Blue line: Fulfillment delays
- Orange line: Seller-fault cancellations
- Red line: Dispute refunds
Multi-store and agency operations: metric definitions cannot be split by store and assigned per person
In a multi-store scenario, the three metrics must be viewed in aggregate by function: inventory—one person looks at stockouts and cancellations across all stores; customer service—grouped by platform or language to view disputes; logistics—view fulfillment delays by carrier and warehouse. If each operator manages the numbers for only one store, the same batch of SKUs could be out of stock in store A and oversold in store B, and no one could see it from single-store reports. Permissions and review cadence can refer toAccount isolation, permission segregation, and data review. The way the three streams of orders, inventory, and messages are consolidated also directly changes cancellation rates and fulfillment metrics; for the approach, seeCentralizing the processing of orders, inventory, and messages.
The most common gap during an agency operations handover is handing over only the store backend access but not the metric definitions: the incoming party doesn't know which reporting period the previous person was looking at, and misjudges account deterioration in the first week. The handover checklist should at minimum spell out the definitions of three metrics, the trends of the last four weeks, and a list of unresolved disputes.
Metrics are normal but the account is restricted: check the environment layer first
If fulfillment, cancellations, and disputes are all within the normal range, yet verification codes increase, login anomalies appear, or account restrictions occur, the troubleshooting focus should shift from operational data to the account environment layer: whether login credentials are shared, whether the network egress overlaps with other stores, whether the browser environment is isolated, and whether profile data is reused across stores. Do not assert that a single signal will necessarily lead to a restriction; the platform may make a judgment based on multiple signals, and the account notification and official policy shall prevail. For the criteria for the four-layer environment self-check, refer toMulti-store environment troubleshooting and risk self-check. If you have already received a restriction or termination notice, followAccount appeal and recovery process after a banDistinguish between restrictions and terminations, then prepare your materials.
Leave a trail for troubleshooting: the four fields to write in the record sheet
The troubleshooting log does not record “Resolved”; it records only four fields: the abnormal metric and statistical period, the suspected responsible segment, the evidence-collection actions already performed, and the date of the next recheck. When the same metric becomes abnormal again next time, you can see at a glance whether it is an isolated incident or a recurrence in the same step. Without these four fields, three troubleshooting sessions will become three fresh starts.
Frequently Asked Questions
How often is the backend health data updated?
Different metrics update at different frequencies; fulfillment and cancellation usually update faster than dispute closure. Use the current instructions in Seller Center as the standard, and do not repeatedly submit reports or contact customer service when the data has not updated.
Do I need scheduled troubleshooting if I only have a single store?
Yes. A single store can also encounter order surges, stockouts, and logistics provider warehouse overflow. Pulling data for the three metrics once a week on a fixed schedule is more cost-effective than waiting until you receive a deduction notice to check.
Can metrics from different platforms be compared directly?
No. Platforms differ in statistical definitions, cancellation responsibility allocation, and dispute closure cycles. When comparing across platforms, only look at trend direction; do not directly compare percentage values.
Where is handover most likely to break down in agency operations?
Breakdowns are most likely to occur in statistical periods and unresolved disputes. During handover, list the definitions of the three metrics, the trend over the last four weeks, and the list of unresolved disputes as mandatory handover items; this can reduce misjudgments in the first week after taking over.
