Ecommerce Shipping Guide

Who Owns the Delivery Promise? A RACI for Ecommerce Brands, 3PLs, Carriers, and Shipping Software

By EasyShippingX Editorial TeamPublished Updated

Every storefront shows a number: "Order by 2 PM, get it Friday." The customer reads it, clicks buy, and holds you to it. That number is a promise, and the promise belongs to the brand. Not to the 3PL that picks the order, not to the carrier that moves it, not to the software that prints the label. The customer bought from the brand, and when the package is late, the customer emails the brand. This guide gives you the one tool that makes that simple fact operational: a RACI matrix that assigns who does the work, who answers for the outcome, who gets consulted, and who just needs to know, across every leg of delivery.

Parcels bearing delivery-promise labels move along a warehouse conveyor.
The brand answers to the customer; the 3PL and carrier answer for the parcel

The Promise Is a Promise, Not a Handoff

Checkout closes the sale. What happens next is a series of handoffs: the order moves to the warehouse, the warehouse hands the parcel to a carrier, and the carrier hands it to the customer's door. Every handoff transfers work. None of them transfer the promise. The brand made a commitment to a customer, and the customer has exactly one address for that commitment: the brand's inbox, chat widget, and support line. If you run a 3PL or a carrier, the brands you serve are accountable for the promises on their storefronts, which means your job is to give them the work product and the evidence, not to absorb their accountability.

RACI gives the four players a common language. Responsible does the work. Accountable answers for the outcome, and there is exactly one A per row.[1] Consulted gives input before the decision is made. Informed gets notified after the fact. The rule that makes RACI useful for delivery is simple and worth writing on the ops wall: Accountable always stays with the brand. Responsible can be delegated to a 3PL or a carrier. Delegating the work is not delegating the relationship, and the delivery promise is part of the relationship. When a brand says "our 3PL owns fulfillment," what it can actually mean is "our 3PL owns the fulfillment work." The accountability stays in-house.

The reason this matters is economic. Blame games are expensive: the 3PL blames the carrier, the carrier blames the address, the software blames the API, and the customer waits for an answer that never comes. Every unresolved "where is my package" is a lost repeat purchase, and repeat revenue is where ecommerce margins live.[2] A signed RACI does not prevent delays. It prevents the delay from becoming a dispute, because at any moment there is exactly one party that answers for the outcome and a defined list of parties that must produce evidence.

Flowchart: brand makes the promise to the customer and answers for the outcome, brand delegates work to the 3PL, the 3PL hands off the parcel to the carrier, and the carrier delivers to the customer
Responsibility delegates down the chain; the promise answers up to the brand

The Delivery RACI Matrix

The matrix below covers the full fulfillment lifecycle, from the moment inventory becomes available to the refund that closes a return. Columns are the four players: the brand, the 3PL, the carrier, and the shipping software layer, which we define as OMS, WMS, ERP, and rate and label tools. Read it with the Section 1 rule in mind: a row can carry several R's, but exactly one A, and on every customer-facing row that A is the brand.

Fulfillment stage Brand 3PL / warehouse Carrier(s) Shipping software
Inventory availability timeARIR
Warehouse cutoffARIC
Order routing / fulfillment assignmentACIR
Carrier service & rate selectionACCR
Label generationARIR
Picking & packingARII
Carrier pickup / handoffARRI
Linehaul & last mileAIRI
Tracking eventsAIRI
EDD computation & displayACCR
Delivery attemptAIRI
Exception handlingARRR
Promise adjustmentACCR
Promise-miss review & routing updatesACCR
Returns & refundsARRR

Note the pattern: the brand holds A on every single customer-facing row, the 3PL holds R on the physical origin operations, the carrier holds R on the transit rows, and the software layer holds R on the data rows. The rows teams argue about most are inventory availability, warehouse cutoff, and EDD, because those are the ones where a number on the storefront depends on a pipeline that nobody owns end to end. The next section names an owner for every input in that pipeline. And if you also need the cost side of the matrix, packaging, carrier routing, and billing, see the companion guide on who owns shipping cost.

The Data Contract Behind the Promise

Every customer-facing number on the storefront is the output of a data pipeline: inventory feeds, cutoff clocks, carrier service tables, tracking webhooks. The matrix only works when the data feeding it is real, so each input needs a named owner and a signed expectation. Think of this section as the data contract that makes the RACI executable.

Contract 1, inventory availability time: the 3PL or WMS supplies it through an inventory feed at location level, the brand owns it as a promise input, and the OMS or checkout consumes it. If the number is wrong, the brand is accountable and the 3PL is responsible for the feed. The contract should name the feed cadence, the reconciliation window, and who is paged when the feed goes stale.

Contract 2, warehouse cutoff: the 3PL maintains and publishes it as a signed commitment. "Orders in by 2 PM ship today" is a contract, not a habit. The brand's checkout promise and the software's cutoff logic consume it. Missing the cutoff is a 3PL R-failure unless the brand routed the order in late, and the evidence for that is simple: the order timestamp versus the routing timestamp.

Contract 3, carrier service and tracking events: carriers return service types and transit estimates and emit tracking events. Shipping software such as EasyShippingX relays those events. The brand owns the customer-visible record. Scan latency and event completeness belong in the contract as SLOs, because a customer-facing tracker is only as good as the events feeding it.

Contract 4, EDD: the OMS or EDD engine computes it from inventory availability, warehouse cutoff, and carrier service. The storefront displays it, and the brand is accountable for it. The software supplies inputs and never silently recomputes the number. If an EDD is wrong, you must be able to walk it back: which input was wrong, availability, cutoff, or transit?

Contract 5, promise adjustment in peak season, weather, and capacity anomalies: the brand decides the revised promise. The 3PL and carriers provide capacity notices, the software surfaces the signal, and the brand informs the customer. The contract should include the calendar of known peak events and the trigger that moves a promise from "unlikely" to "adjusted."

Contract 6, promise-miss post-mortem and routing updates: the brand convenes the review. The 3PL brings scan evidence, the carrier brings transit events, and the software brings logs. Routing-rule updates are executed by 3PL ops and software configuration, and approved by the brand. The output of every post-mortem is a changed rule or a changed SLA, never just a note in the chat.

Six Blame Games, Decoded

Every blame game follows the same shape: two parties each hold half the evidence, and the customer holds the complaint. Decode the game by naming who is R, who is A, who is C, and where the evidence handoff point sits. Here are the six that come up in every fulfillment operation.

Two operations managers review parcel scan history on a tablet while a driver waits with a parcel.
The evidence handoff point decides which party lost the R

Blame game 1, late delivery. The carrier blames the 3PL's cutoff, the 3PL blames the carrier's transit SLA, and the package is a day late. The evidence that proves which leg failed is the pickup scan. If the pickup scan lands after the promised cutoff, the 3PL owns the R-failure. If the pickup scan is on time and the delivery still misses the promise, the carrier owns the R-failure. A stays with the brand either way, because the customer does not care which leg failed.

Blame game 2, lost package. The 3PL says it handed the parcel over, the carrier says it never received it. The handoff point is the first carrier scan: if the last scan is "label created" or the 3PL dock, the 3PL is R and the evidence is the missing pickup scan; if the last scan is a carrier facility and the parcel never moves again, the carrier is R. The brand is A and runs the claim.

Blame game 3, damaged goods. Packing quality is the 3PL's R, handling is the carrier's R, and the two are easy to confuse after the fact. The evidence is photographic: packing photos at the 3PL, delivery photos at the door. The brand opens the claim with the carrier, the 3PL produces the packing evidence, and the claim outcome decides which R failed.

Blame game 4, wrong address. Data entry at checkout is the brand's R, address validation is the software's R, and re-labeling is the 3PL's R. The handoff point is label generation: once the label prints, the address on it is the brand's record. The software should catch obvious errors before the label exists, and the 3PL should catch a mislabeled parcel before it leaves the dock. A belongs to the brand, because the customer typed the address into the brand's checkout.

Blame game 5, system and API failures. A rate is wrong, a label fails, a webhook drops. The software layer is the evidence layer, not the accountable owner. The brand holds A for the customer outcome, and the software holds R for the fix and the log: idempotent label calls, webhook retries, and timestamped audit trails are the difference between a five-minute fix and a week-long blame game.

Blame game 6, returns and refunds. The RMA flow is the software's R, the return leg is the carrier's R, receiving is the 3PL's R, and the refund is the brand's A. The customer's refund experience belongs to the brand, so the contract needs one number: refund issued within X hours of the returned parcel being scanned at the warehouse. Everything before that scan is everyone else's work.

Making It Stick: SLOs, SLAs, and Visibility

A RACI on a wiki page changes nothing. Turn it into contracts with numbers: a pick SLA (95 percent of orders picked within four hours of cutoff), a cutoff SLA (published, signed), a transit SLA (the carrier's service standard), an exception SLA (acknowledged within 24 hours), and a refund SLA (issued within 48 hours of receipt scan). Each SLA names the party that reports the metric and the party that is accountable when it misses.

Escalation needs a rehearsed path, not an improvisation. The software signals the exception, the brand triages it, the 3PL and carrier produce evidence on request, and the brand informs the customer. The same path should run whether the exception is a delay, a damage, or a loss, so that the team does not have to invent the loop at 9 PM during peak season.

Data ownership is the hidden responsibility in this matrix. Tracking data, scan events, and delivery proof belong to the brand's customer record, even when a carrier or a software vendor generates them. The contract should state who holds the data, who can export it, how long it is retained, and what happens at contract end. A 3PL that cannot return scan history to the brand on exit is holding the customer record hostage.

Sequence diagram: customer asks where the package is, brand ops pulls tracking and logs, requests origin evidence from the 3PL (pickup scan, packing photos), requests transit evidence from the carrier (scan history, claim status), then replies to the customer with a status and resolution plan
The escalation path: signal, evidence, customer notification, each in its place

When the Matrix Bends

Multi-carrier splits. Routing decisions move R around as orders shift between services, but the brand still holds A for the customer-facing promise. Every routing-rule change needs the brand's approval in the review loop, and the software needs to log which rule sent which order to which carrier, because that log is the evidence when the next promise misses.

International and DDP shipments. Customs, duties, and tax liability shift responsibility in ways the domestic matrix does not capture. The landed-cost promise belongs to the brand, because the customer paid one number at checkout. The broker or carrier is R for clearance, and the software is R for displaying the DDP fee accurately at checkout. When duties are wrong, walk it back the same way you walk back an EDD: which input was wrong?

Last-mile handoff to regional carriers. Many brands hand the parcel to a national carrier that transfers it to a regional delivery network for the final miles. The transfer point is where carrier R changes, and it is the exact moment the evidence must be captured: the handoff scan at the regional hub. If the contract does not name that scan, the two carriers will each assume the other owns the last mile.

3PL migration and warehouse switching. During cutover, the brand holds A for every promise made, the old 3PL is R for its exit window, and the new 3PL is R for its entry window. Run parallel shipments, audit the handoff scans, and make the transition-window promises visible in the checkout before you switch the routing rules. The matrix does not pause during migration; it just gets more rows.

The Ops Team and the Software Layer

For ecommerce ops and 3PL owners, the execution checklist has four items: write the RACI and sign it with every partner, attach an SLA number to every R, audit scans weekly against the matrix, and rehearse the escalation path quarterly. The teams that survive peak season are the ones that ran the loop in July, when the stakes were low.

For OMS, WMS, ERP, and SaaS product managers and developers: the software layer is never the accountable party, but it is the evidence layer that makes accountability possible. Build for it: idempotent label APIs, webhook delivery with retries and dead-letter logs, event timestamps that match carrier scans, and exportable audit trails. When a dispute lands, the party with the cleanest log wins, and you want that party to be your customer, the brand.

Honest product positioning. Because we build one of these tools. EasyShippingX lives in the carrier execution layer: rates, labels, and tracking events. It does not compute or own EDD, and it does not pretend to. A true EDD needs inventory availability, warehouse cutoff, and carrier transit data, and those live in the brand's promise stack, not in a label printer. If a tool claims to be an EDD product but cannot see your inventory or your cutoff, it is guessing, and a guessed EDD is a promise you will have to answer for.

Architecture diagram: the storefront and OMS promise stack (EDD, cutoff) sends rates, labels, and tracking to the shipping software (carrier execution layer), which calls carrier APIs, carriers return tracking events, and the software relays events back to the promise stack
The software layer relays data; the promise stack owns the promise

Contract language to copy. One sentence per leg, signed by both parties: "The 3PL is responsible for the published cutoff and for origin scans; the brand is accountable for the checkout promise." "The carrier is responsible for transit scans and the service standard; the brand is accountable for what the customer sees." "The shipping software is responsible for relaying rate, label, and tracking data faithfully; it is not accountable for the customer-facing promise." Sign those three sentences and most of the blame games in this article stop happening.

The Quick-Reference Card

Who answers to the customer: the brand, always. Every promise on the storefront, every tracker, every refund, all of it answers to the brand.

Who answers for the package: the 3PL at origin, the carrier in transit, and the 3PL or carrier on the return leg, each within their scan-defined window.

Who answers for the data: the brand owns the record. The 3PL supplies availability and cutoff, and the carrier and shipping software supply service and tracking events.

Who answers for exceptions: the brand owns the loop, the operators own the fix, and the software owns the signal.

The delivery promise lives with the brand. Everyone else is on loan: the 3PL, the carrier, the software, all of it. Give each of them a row, a letter, and an SLA, and the promise becomes something you can operate instead of something you can only apologize for.

FAQ

The brand, always. The customer bought from the brand's checkout, and when a package is late, lost, or damaged, the customer comes to the brand, not the 3PL or the carrier. In RACI terms: Accountable always stays with the brand, while Responsible (the picking, packing, and moving) can be delegated to the 3PL and carrier. Delegating the work is not delegating the relationship.
Because the promise is made to the customer, and the customer has exactly one address for it: the brand's support line and inbox. The 3PL answers for origin scans, the carrier for transit, the software for data relay, but only the brand can answer for "arrives by Friday." It is also an economic argument: every unresolved where-is-my-package is a lost repeat purchase, and repeat revenue is where ecommerce margins live.
By default it is a 3PL R-failure. "Orders in by 2 PM ship today" is a signed contract, not a habit. The only exception is the brand routing the order in late, and the evidence is simple: the order timestamp versus the routing timestamp. Late-delivery disputes work the same way: pickup scan after the promised cutoff means the 3PL loses; pickup on time but delivery still late means the carrier loses. A is always the brand.
No. The EDD is computed by the OMS or EDD engine from three inputs: inventory availability, warehouse cutoff, and carrier transit. The brand is accountable for the EDD shown to the customer, and the software only supplies inputs, never silently recomputing the number. When an EDD is wrong, walk it back: was it availability, cutoff, or transit data? If a tool claims to be an EDD product but cannot see your inventory and cutoff, it is guessing.
During cutover the brand holds A for every promise made, the old 3PL is R for its exit window, and the new 3PL is R for its entry window. Run parallel shipments, audit the handoff scans, and show the transition-window promises at checkout before switching routing rules. The matrix does not pause, it just gets more rows. Multi-carrier splits work the same way: routing moves R around, A stays with the brand, and every rule change needs brand approval plus a log.
Get Rate Comparison Use the Shipping Calculator

Want to keep every delivery promise your checkout makes?

EasyShippingX operates in the carrier execution layer (rates, labels, tracking) and turns every link of the responsibility chain into auditable evidence, so the brand, the 3PL, and the carrier each stay in their lane, and promises stop depending on luck.

Get Rate Comparison Use the Shipping Calculator