Marketplace ops
AuraScore 81/100

Last-Mile Delivery SLA Breach and Merchant Dispute Resolution Framework

Standardize dispute handling, root-cause attribution, and automated payout policies for last-mile logistics platforms.

Use this template when multi-party disputes between merchants, delivery partners, and platform ops cause friction. It establishes an objective SLA breach framework, indemnity matrix, and automated settlement rules.

Template

Role: Head of Last-Mile Marketplace Operations & Settlement Governance with deep expertise in on-demand dispatch economics.

Context

  • Logistics Platform: {{logistics_platform}}
  • Merchant Segment: {{merchant_segment}}
  • Delivery Window SLA Target: {{delivery_window_target}}
  • Merchant Dispute Grace Window: {{dispute_grace_period}}
  • Maximum Automated Claim Cap: {{claim_value_ceiling}}
  • Delivery Partner Classification: {{driver_partner_tier}}

Task

Construct a Last-Mile Delivery SLA Breach and Dispute Resolution Framework that establishes clear operational accountability, standardizes defect attribution, and automates merchant compensation protocols to protect marketplace margins and merchant retention.

Method

  1. Map out core delivery lifecycle milestones from merchant dispatch handoff to consumer proof-of-delivery (POD).
  2. Classify primary SLA breach triggers (e.g., late handoff, driver reroute, damaged cargo, failed POD) against {{delivery_window_target}}.
  3. Establish an objective fault-attribution rubric assigning liability between the merchant, {{driver_partner_tier}}, and platform infrastructure.
  4. Define tiered settlement matrices establishing penalty deductions, driver clawbacks, and merchant credit formulas.
  5. Design an automated claims adjudication pipeline for losses up to {{claim_value_ceiling}} submitted within {{dispute_grace_period}}.
  6. Structure a secondary escalation path for complex high-value disputes and merchant chargeback appeals.
  7. Establish merchant and driver quality scoring impacts stemming from chronic breach patterns.

Constraints

  • Automatic claim settlements MUST NOT exceed {{claim_value_ceiling}} without mandatory two-party supervisor review.
  • Dispute claims filed past {{dispute_grace_period}} MUST be automatically classified as ineligible for standard credit.
  • The attribution model must account for external uncontrollable factors (severe weather, geofence errors).
  • Remedies must define precise financial balances between merchant refunds and driver partner penalties.
  • All workflows must preserve platform margins while maintaining partner fairness.

Output format

Provide the complete framework structured in the following sections:

  1. SLA Definition and Lifecycle Milestone Taxonomy (max 200 words)
  2. Breach Classification & Fault-Attribution Matrix (Table: Breach Event, Primary Fault Party, Evidence Required, Settlement Rule)
  3. Tiered Compensation & Penalty Schedule (specific financial calculations for refunds, credits, and partner deductions)
  4. Automated vs. Escalated Claims Workflow (detailed process flow diagram or structured step-by-step logic)
  5. Partner Performance Thresholds & Quality Sanctions (rules for probation, suspension, and merchant fee adjustments)

Self-review

  • Are the dispute filing timelines aligned with the {{dispute_grace_period}} constraint?
  • Does the framework define explicit evidence requirements (e.g., photo POD, timestamped geofence logs)?
  • Is there a clear boundary between automated resolution under {{claim_value_ceiling}} and manual escalation?
AuraScore breakdown
81/100Provisional
Instruction clarity15/15 · Strong

Explicit role, a named task, and discrete steps the model can follow.

Context architecture12/12 · Strong

Background, inputs and variables the model needs before it starts.

Constraint engineering12/12 · Strong

Hard boundaries — what the model must and must not do.

Output specification6/14 · Thin

A named, field-level shape for the response.

Reasoning structure10/10 · Strong

Ordered work items that force analysis before an answer.

Model compatibility10/10 · Strong

Length and structure that travel across frontier models.

Token efficiency5/10 · Thin

Signal density — instruction weight without padding.

Reusability7/7 · Strong

Documented variables so the scaffold adapts to new inputs.

Robustness3/5 · Adequate

Quality bar, assumptions and behaviour when inputs are thin.

Observed performance1/5 · Thin

How much real usage the template has behind it.

ecommerce-retail
ecom-operations
transport-logistics
last-mile
sla-governance
dispute-resolution