Delivery Dates on a Marketplace: What You Can Promise

A delivery date on a marketplace is a promise you publish, and somebody else keeps, which is why it has to be built from a seller's history rather than from their declaration.

The delivery date is the only promise you make to the buyer before they pay, and somebody else carries it out. Calculated badly, it costs you twice: first in tickets, then in trust that no discount will rebuild.

This article breaks down:

• How does a 2-day ship time become a 5-day date?
• A specific date or a range: which should you show?
• What sets the promise in a multi-seller cart?
• Declared ship time or seller history?

Key insights

• A 2-day ship time becomes a 5-day date because the cut-off hour, the weekend, and the courier's pickup day each add a day or two.
• Show a range with explicit slack and measure who overruns it, because a single date set at the median is broken half the time by definition.
• In a multi-seller cart, the slowest item sets the promise, so either promise per seller group and ship separately, or accept that one late item makes the whole order late.
• Publish the seller's measured history rather than their declared ship time, at a percentile you chose on purpose, because the field in their profile is a wish and their history is a measurement.

Who keeps the delivery date a marketplace promises?

The date on the offer page is made of three independent components, and you control none of them. The seller's time to prepare the parcel, the day the courier turns up for the pickup, and the transit itself.

The buyer does not see three parties. They see one date, in your interface, made in your voice, and they hold you responsible for all three components at once.

That is not unfair. It follows from the fact that you sell a promise under your own logo.

Public standards for describing commercial data break it down the same way: preparation time and transit time are separate values, and next to them sit the order cutoff hour and the seller's working days. More importantly, search engines expect both values as ranges rather than as numbers.

Nobody knows the exact date at the moment it has to go on the screen.

The conclusion is uncomfortable. You cannot promise a date, because you have no power over it.

You can do two things instead: turn the promise into a range with explicit slack, and measure who overruns that slack.

How does a 2-day ship time become a 5-day delivery date?

The seller declares "ships in 2 working days" and means it in good faith. Follow one order through.

The buyer clicks on Thursday at 16:40. The seller's cutoff is 14:00, so the order lands on their Friday.

Two working days of preparation are Monday and Tuesday, because the weekend does not count. The courier serves this seller on Wednesdays.

Transit takes 1 to 2 working days, so delivery falls on Thursday or Friday.

The declared "2 days" turned into 5 working days and 7 to 8 calendar days. No delay, no breakdown, no bad faith.

One public holiday in the middle of the week adds another day, and a seller in a different time zone draws the day boundary somewhere other than your server.

Count where the days went: one on the cutoff hour, two on the weekend, one on the pickup day. None of them is the seller's fault, and none of them is visible in the field they filled in for you.

That is why "how many days do you declare" is the wrong question to ask a seller, and "which day is the courier at your warehouse" is the right one.

A specific delivery date or a range: which should you show?

A specific date lifts conversion, because it removes uncertainty. In public research on cart abandonment, a delivery time that runs too long is named by roughly one abandoning shopper in five.

It also produces disputes, because it can be missed unambiguously. A range with slack does the reverse: it costs you part of your conversion and generates almost no disputes.

Take a seller with 1,000 orders a month who delivers within 3 working days in 60% of cases, within 5 days in 90%, and hands the parcel to the carrier on time in 95%.

There is one rule: promise what you deliver at a high percentile. A promise set at the median is broken in half of all cases by definition.

At the ninth decile, you break it in one case out of ten. That is a number the team you have can absorb.

The third column is a trap, because it looks cautious. Communicating ship time alone does not reduce the number of late deliveries.

It removes them from your own reports. The buyer counts the days to the parcel.

What sets the delivery promise in a multi-seller cart?

This is the real price of a multi-seller cart, and it needs saying plainly. The date for the whole order is the date of its latest item, unless you split the shipments.

A cart with three items from three sellers: 2 days, 3 days, and 6 days, because the third is waiting on stock from the manufacturer. One "with you by" window has to show 6 days.

The buyer who added a third item for €40 made their own promise four days worse and does not understand why. Split shipments give three dates and the first parcel after two days, in exchange for three labels, three sets of notifications, and three occasions to raise a ticket.

The arithmetic of the tail matters more here than any single case. If 8% of your offers carry a "long" date, one item in the cart hits such an offer 8% of the time, two items about 15% of the time, and three items more than 22%.

A growing cart degrades the promise faster than it grows the order value: one slow offer poisons the whole cart.

The same mechanism applies to delivery methods. The shared list for a cart is an intersection: if one of three sellers does not ship to pickup points, pickup points disappear for the entire cart.

The buyer's choice is limited by the weakest seller in the cart.

The money does not move by a cent because of any of this. A €1,000 cart at a 12% commission is €120 for you and €880 for the seller, regardless of the number of parcels.

What changes is the moment that €880 leaves, because confirmation of delivery gates it ("How Marketplace Seller Payouts Work: Cycles, Holds, and Reserves").

Declared ship time or seller history: which do you publish?

The seller fills the "ship time" field with what they would like to deliver. You have something better: several hundred of their orders with dates on them.

The promise per seller should be calculated from their distribution.

The seller declares 2 working days. Measurement shows that in 90% of cases they hand over the parcel in 4 days.

If the storefront shows their declaration, at 1,000 orders you have 400 late orders a month; if it shows the calculated 4 days, you have 100. The same supply and the same logistics, four times less work for support.

The only difference is whose number went onto the page.

Correcting the promise is not a punishment. It is a duty toward the buyer, and you have to say so to your sellers before they read the longer date as a demotion.

Thresholds and suspensions are in the "P2B Regulation on a Marketplace: Ranking, Terms Changes, and Suspension".

Watch out for something the panel will not tell you: the late countermeasures in your integration. Practitioners describe the same event across many implementations.

The seller shipped on time, but the tracking number never reached your system because the configuration broke at the integrator. In the report, you see a delay that never happened.

If an automatic suspension hangs on that report, you punish a good seller for somebody else's error. Before the late counter is allowed to carry consequences, it has to separate "did not ship" from "I do not know whether they shipped."

The rest is cheap. A delay you warn about costs one message.

A delay you do not warn about costs a ticket, a return, and a review. A hundred delays handled by automation are a hundred messages and zero hours of your team's time.

A hundred unannounced ones are about a hundred contacts, and at six minutes per contact, that is ten hours of support, plus the orders that come back as returns. In the consumer regimes large platforms operate under, warning the buyer is not a courtesy: a date you state is expected to rest on reasonable grounds, and when it falls through, the buyer is supposed to get a choice between accepting the delay and walking away with a refund.

Why is tracking part of the delivery promise?

A buyer who can see a status does not call. That sounds trivial until you count it on volume.

At 10,000 shipments a month and 6% disruptions (a failed delivery attempt, a hold at the sorting hub, a redirection), you have 600 events the buyer will notice. Without a visible status, each one generates a contact.

With one, roughly half fall away: 300 fewer contacts a month, and at the same six minutes each, about 30 hours of your team's time.

Almost nobody in this class of solutions supplies an intermediary between you and many carriers, meaning one point where you receive statuses from all of them.

Every operator builds it themselves. Intermediate statuses are carried by only some solutions: some have a closed set of a few states, others know only "shipped" and "delivered" and give you no way to add anything in between.

One vendor in this class moved into the gap with a separate paid tracking module, covering most carriers and speeding up payouts through automatic statuses. So at the platform selection stage this layer is still an open question.

The bar on the standards side is clear: public models for describing a shipment treat the status as a log of events appended at every stage of the journey, with separate fields for the earliest and the latest expected delivery date. Not a field but a history.

The same shape as price (price history and discount messages).

There is one more thing you will not see in a demo. Some solutions flip the status to "delivered" once a counter runs out, two or three weeks after dispatch, for instance, regardless of reality.

It looks convenient, because orders close themselves and payouts start moving. What it really does is turn an absence of information into a fact: the system claims the parcel arrived, because nobody said it did not.

The consequences run in two directions: toward the buyer, who sees "delivered" and knows better, and toward the money, because payout release hangs on that status, as does order closure from the chapter on orders and logistics.

What does the delivery promise change about the rest of your storefront?

The date promise is a calculation, so it belongs to the data schema and not to the page template. The storefront has to receive a finished date or range from one place, where the components were summed and the slack was added.

A date assembled in a template out of three fields is a date you can neither measure nor defend.

1. The date enters offer ranking, so you have to be able to measure it first

If delivery speed is going to help decide who wins the product page, it enters as a criterion measured by history rather than declared (the rule that picks the winning offer). The "delivery within two days" filter has the same precondition (search and filtering).

2. The date is part of the message at checkout, next to the information about who the seller is

Since a return runs from the moment of delivery, the quality of your "delivered" sets the windows for returns and complaints (who pays for a refund).

How do you check delivery dates on your own data?

1. Show us what the date on the offer page is made of. Which components you take, whether they can be seen separately, and where the slack sits.
2. Can the promise per seller be calculated from that seller's history? If it can, who overrides it and whether the override counts toward their statistics.
3. Cutoff hour and the calendar of non-working days: per seller or global? A shared calendar with sellers in several countries is a systematic error.
4. Show us a cart with three sellers: which date appears in the summary and which delivery methods survive on the list.
5. List every shipment state you are able to record, and tell us whether a new one can be added without changing the integration contract.
6. Where does "delivered" come from: the carrier, a seller's click, or elapsed time? If it is elapsed time, what is the counter, and what gets released with that status?

If questions 2 and 6 have no answer you can be shown on a screen, you are buying a text field.

Which mistakes do operators make about delivery dates?

1. A delivery promise copied from the seller's declaration

Consequence: several times more late orders than you need to have, and a ranking that punishes sellers for a date you displayed yourself.

2. One date for a multi-seller cart with no split shipments

Consequence: the slowest offer sets the pace for the whole order, and the buyer gets a worse promise for adding a second item to the cart.

3. "Delivered" set by a timer

Consequence: orders close themselves, payouts start moving, and the ticket arrives a week later, already outside the process.

4. Sanctions on the late counter with no separation of causes

Consequence: you suspend a good seller over a broken tracking number integration.

5. Tracking deferred as a logistics project for after launch

Consequence: "where is my parcel" questions show up in the first week and land on customer support, because nothing else was left to take them.

What do you still have to settle about your own promise?

This chapter settles nothing about shipping configuration. Zones, methods, logistics classes and rates belong to the chapter on orders and logistics, together with couriers, labels and carrier integrations.

The neighbouring decisions are led elsewhere:

• delivery cost in the cart and free shipping thresholds, in a cart with several sellers,
• the choice of method as a moment in the transaction, in checkout with several sellers,
• cash on delivery,
• returns, in who pays for a refund, and seller quality thresholds, in the rules on decisions about sellers,
• when an order counts as delivered in the accounting sense, in the chapter on orders, and what follows for payouts.

Nor does it settle the most important number in this decision: your own distribution of delivery times per seller and per method. It is not in any documentation, because it is a measurement on your own traffic. Without it, every date on the storefront is a bet.

The legal dimension we leave to specialists. The date promise and the consequences of missing it sit within the rules on consumer rights, in the part about information before the contract is concluded and about handing over the goods. Confirm with a lawyer what you have to show before payment and what you owe the buyer when the date falls through ("Marketplace Consumer Rights: Who Delivers Them?").

Our claim is narrower and independent of those answers: a platform that cannot calculate how often it hits its own date does not have a promise. It has a caption.

Summary: What can a marketplace honestly promise?

Whatever your sellers' history supports, at a percentile you chose on purpose. The date on the page is made of parts you do not control: the seller's cut-off time, their working days, the carrier's own promise, and whatever the weekend does to all three.

That is why a declared ship time is the wrong input and a measured one is the right one, and why the promise in a multi-seller cart belongs to the group rather than the cart. Decide the shape too — a single date reads as certainty and a range reads as honesty — and know which one your category forgives.

Take last quarter's orders and compare the date you showed with the date the parcel arrived. Building a marketplace where the promise comes from what sellers have done rather than what they typed?

Talk to us about the build.

Frequently asked questions on marketplace delivery dates

How should a marketplace calculate a delivery date?

A marketplace should calculate a delivery date from the seller's measured history and the carrier's own promise, at a percentile you choose. The parts are a cut-off time, the seller's working days, the handover, and the carrier's transit. A declared ship time from a profile field is a wish and belongs nowhere near the page.

Should a marketplace show a delivery date or a range?

A marketplace should show a single date where a miss is cheap and a range where it is not. A date reads as certainty and costs you when it slips; a range reads as honesty and costs a little conversion. A birthday present tolerates a range badly, a spare part tolerates it well.