Fulfilment SLAs and what your storefront should promise

A delivery promise is assembled from three commitments made by three organisations, and the customer only ever reads the last one.

You decide when an order is released — after fraud checks, after a payment settles, after a personalisation step, after whatever holds the order for a few hours in your particular business. This is the part nobody measures and it is frequently where the day goes.

The warehouse or 3PL commits to picking, packing and handing over by a cut-off, on defined working days, subject to the exclusions in the contract. This is the commitment with money attached.

The carrier offers a service level. Even an express service is a service level, not a guarantee, and for most economy services the published transit time is a modal outcome, not a floor.

The storefront then compresses all three into one line of text, usually written by someone in marketing with access to none of the three. That is the structural problem, and it is why “what should we promise?” is an operations question that happens to be answered in a theme file.

The most common mistake is arithmetic. A team looks at mean dispatch time, finds it comfortably inside the cut-off, and writes the comfortable number on the site. But a mean sits in the middle of a distribution: if your average order dispatches well within the promise, a substantial share still does not, and every one of those produces a customer who was told something untrue.

Use a high percentile instead — the 90th is a reasonable default. Ask “what date is true for nine orders in ten?” and put that on the page. It will read slower than the average, and it will be right far more often.

The second-order effect is the one worth arguing for internally. A promise you keep builds a customer who believes the next one. Once a customer has been let down, every subsequent date on your site is discounted, including the honest ones, and you have lost the mechanism rather than one order. We wrote about the conversion side of this in [the delivery date that changes conversion](/blog/delivery-promise-the-date-that-changes-conversion): the date converts by removing a question, and it can only do that if the answer holds.

This is also the case for promising *less* than you can do. A store that dispatches most orders same-day and promises next-day dispatch has given itself a day of slack, and delights a good share of customers by beating its own promise. Under-promising is cheap; a missed date is not.

Four things, in roughly this order of value.

The cut-off, as a countdown. “Order within 3h 12m for dispatch today.” It is the strongest element available because it is the one part of the chain you genuinely control, and it converts urgency out of a real operational fact rather than a manufactured one.

Dispatch and delivery, distinguished. Say which is which. “Leaves us today, arrives Tue–Thu” is more honest and no less persuasive than a single confident date you cannot underwrite. Customers understand that post is post.

The estimate, on the product page, not just at checkout. Shopify can show a delivery date at checkout — either automated from your shipping performance or manual from a fulfilment time and transit time you set. That is useful and it is late: the decision about whether to buy was made further up. The delivery promise APIs that would let you compute this properly are, per Shopify’s documentation, restricted to approved delivery promise partners, so a product-page estimate is usually something you build from your own inputs.

Stock reality. A date that ignores whether the item is in the right warehouse is a guess wearing a uniform. If your inventory is split across locations with different dispatch profiles, the promise has to know which location will serve the order.

And one thing not to say: anything with the word “guaranteed” attached to a carrier leg. It creates an obligation your contracts do not cover, and in several jurisdictions it creates one your legal team would rather you had asked about.

You already hold the data. Shopify records when the order was placed and when it was fulfilled; the difference is your dispatch time, order by order, against exactly the boundary Shopify defines. Carrier scan events give you the transit half.

A weekly report with three lines is enough to run this: the share of orders dispatched within the promise, the 90th percentile dispatch time, and the same two figures for whichever order types your SLA excludes. When the third line diverges from the first two, you have found the group of customers your promise is quietly wrong for.

Then put a rule around it: the storefront promise is reviewed when the report says so, not when someone remembers. The stores that keep their dates honest through peak are the ones where changing the promise is a normal operational action that takes ten minutes, not a theme deploy that needs a developer. Wiring that up — making the date a setting rather than a hard-coded string — is one of the cheapest things in this whole post, and it is usually the thing we do first on a [store management engagement](/services/support).

The honest summary: your customers are not asking for speed. They are asking for a date they can plan around. Those are different products, and the second one is much easier to deliver.

• Full Shopify store management
• Delivery promise: the date that changes conversion
• Order routing across warehouses and a 3PL