How to identify the dominant metric in a mixed Amazon performance case

Mixed performance cases usually break down before the appeal is even written. The seller sees several bad signals at once, such as defects, late shipments, cancellations, or accepted orders that were never carried through, and then answers all of them with one broad promise to improve operations.

That is usually the wrong starting point. Amazon is normally reviewing one dominant performance logic at a time, even when other metrics deteriorated in the same period. The practical job before another submission is to reconstruct which metric is actually doing the enforcement work and which problems are only spillover or symptoms.

Rebuild the order set before you draft anything

A mixed case gets clearer when the affected period is rebuilt order by order. That means working from the notice, Account Health history, and the actual order outcomes rather than from the metric names alone.

• Lock the review window first so you are not mixing older noise with the period Amazon is actually reacting to.
• Pull the orders tied to A-to-z claims, chargebacks, negative feedback, late shipment confirmations, seller-side cancellations, and any accepted orders that were not fulfilled.
• Mark what happened on each order in plain operational terms: accepted, packed, dispatched, confirmed shipped, cancelled, refunded, or left unresolved.
• Note where one order created more than one symptom, because that is where sellers often mislabel the case.
• Flag low-volume distortion. In smaller accounts, a short cluster of bad orders can make the wrong metric look dominant if you only read the percentages.

Use the order facts to identify the dominant metric

The four common performance stories overlap, but in practice they are asking different operational questions. The case becomes easier once each order failure is put into the right logic bucket.

• Order Defect Rate: Start with buyer-harm outcomes such as A-to-z claims, chargebacks, and negative feedback. The real question is what defect mechanism created those outcomes, not whether the seller later apologized well.
• Late Shipment Rate: Start with the acceptance, dispatch, and confirmation timestamps. The real question is why shipment was confirmed after the expected ship date, not whether the carrier delivered slowly afterward.
• High Order Cancellation Rate: Start with seller-caused pre-fulfillment cancellations. The real question is why orders were accepted and then cancelled on the seller side, usually because stock truth, sync, supplier certainty, or acceptance rules were weaker than the listing promise.
• Unfulfilled Orders: Start with accepted orders that were not carried through to fulfillment at all. The real question is why the order was accepted without dependable fulfillment capability behind it. This can later feed ODR or sit near cancellation problems, but it should not be flattened into either one automatically.

One cluster of orders can touch more than one metric. For example, accepted orders that were never carried through may create buyer harm later, or a stock-control problem may create both cancellations and late confirmations. That still does not make the case a true "everything went wrong" appeal. It means you need to decide which metric logic Amazon is most likely reviewing first.

Why mixed performance appeals often fail

Mixed appeals usually fail because they collapse different kinds of failure into one vague root cause. Amazon then sees a response that sounds cooperative but never answers the specific operational question behind the enforcement.

• A buyer-harm metric gets answered with warehouse-speed promises but no explanation of the actual A-to-z, chargeback, or feedback events.
• A late-shipment case gets answered as if the carrier was slow, even though the real problem was late confirmation or unrealistic handling time.
• A cancellation case gets diluted with customer-cancellation language, which avoids the harder question of why the seller accepted orders it later could not fulfill.
• An accepted-but-not-fulfilled pattern gets hidden inside generic "inventory issues," which never explains why the orders were allowed through in the first place.

Separate the logic before the next submission

Once the order set is rebuilt, sort the case by the question Amazon is most likely asking. That creates cleaner routing and prevents the fixes from drifting toward the wrong mechanism.

• If the main story is buyer harm, rebuild the defect set and move into the Order Defect Rate route.
• If the main story is late confirmation against the expected ship date, rebuild the dispatch timeline and move into the Late Shipment Rate route.
• If the main story is seller-caused pre-shipment cancellation, rebuild the cancellation causes and move into the High Order Cancellation Rate route.
• If the main story is accepted orders that were never carried through, or if the case is still genuinely mixed, stay on the umbrella Performance Issues route long enough to explain the accepted-order failure honestly before narrowing further.

That routing step matters because ODR, LSR, HOCR, and accepted-but-unfulfilled orders are close enough to confuse, but different enough that the wrong appeal structure can make a recoverable case look evasive. Use this article to identify the dominant metric first. Then return to the umbrella performance page or the matching live child page so the next submission is built around the right operational story.