The delivery promise: set it, show it, keep it

A delivery promise is the commitment your checkout makes about when the order will arrive: an exact date, a window, or a cutoff like "order before 12, ships same day." Two things are true about it. Showing an exact date lifts conversion, because shoppers buy certainty. And an exact date is exactly breakable. I will say it plainly: operations increasingly are the customer experience. If a brand gets shoppers what they want on time, as promised, that is the new loyalty program. Every order is a promise. Keeyu keeps it. Not as a slogan, as an operating principle: the promise made at checkout is the standard every warehouse, carrier, and support decision downstream should be measured against. That is the whole logic of proactive e-commerce operations, the system of action for e-commerce.

Set it: a promise you can compute

In the US the promise is not only a marketing claim, it is a legal one: the FTC's Mail, Internet, or Telephone Order Merchandise Rule requires a seller to have a reasonable basis for the shipping time it states, and to notify the buyer when it slips. A real delivery promise is calculated, not copywritten. Three inputs, all live: inventory (is the item actually allocatable now), warehouse cutoffs (what does "today" still mean for dispatch), and carrier performance by lane (what does this carrier actually do to this postcode, not what their rate card says). SLAs stack in layers: dispatch cutoffs, carrier commitments of 24 to 48 hours or five business days, marketplace SLAs above those. A promise engine that ignores a layer produces dates your operation never had a chance to keep. If your dates come from a static shipping-settings table, you are not promising, you are guessing in the customer's direction.

Get this wrong repeatedly and it compounds into the pattern described on poor customer experience: not one bad delivery, but a brand people stop trusting with time-sensitive orders.

There is a reason this is the promise worth computing rather than any other. About half of every support queue is a version of where is my order, a share I gave on The Breakout CEO. That queue is not asking about your product or your policy. It is asking whether the date you put on the page still holds.

Shipping SLAs behind the date: dispatch, carrier, delivery

A shipping SLA (service level agreement) is a written standard for one leg of an order, such as "orders placed by 2pm ship the same day" from your 3PL or "delivered within three business days of pickup" from your carrier. The shopper sees none of them, only the date they add up to at checkout.

What a shipping SLA usually contains

Most 3PL and carrier SLAs cover the same ground, and Shipium lays out the full contract structure:

• Scope: which shipping methods the standard covers, such as economy, standard, express and overnight.
• The standard, written as a measurable rate ("95% of standard orders must arrive within 3 to 5 days"), never "as quickly as possible."
• Exclusions: weather, customs clearance and other delays that do not count as misses.
• Reporting and escalation: weekly, monthly or quarterly reviews, and the miss rate that triggers corrective action.
• Remedies: refunds for late deliveries, service credits for repeated misses, and the terms for ending the contract.
• On the warehouse side: order accuracy, split into picking, packing and shipping accuracy (ShipNetwork).

For transit, published carrier ranges are a planning band, not a date: USPS lists Ground Advantage at 2 to 5 days.

Every vendor can meet its own SLA while the shopper's date still breaks, because no single contract owns the end-to-end promise. Shipium gives the classic version: a retailer promises two-day delivery, the outsourced warehouse processes slowly, and the carrier takes the blame for a late order it never caused. That is why I start from the promise on the checkout page and work backwards through every leg, instead of grading each vendor on its own scorecard.

Contract SLA met, promise broken: a worked example

A shopper orders Monday at 1:30pm. The cutoff is 2pm, the 3PL contract says "dispatch within one business day," and Ground quotes three business days. Checkout promises Thursday.

Every vendor report is green. The shopper's date is red, and the first anyone hears of it is a "where is my order" ticket on Friday. That ticket is evidence the promise broke upstream on Monday evening, when the order missed the carrier pickup.

The three numbers to track

• On-time dispatch rate = orders with a first carrier scan on the dispatch day the promise assumed / orders due to dispatch that day
• Carrier on-time rate = orders delivered within the carrier's committed transit time from first scan / orders with a first carrier scan
• Promise-kept rate (on-time delivery measured the way the shopper sees it) = orders delivered complete by the date shown at checkout / orders whose promised date fell in the period, counting unshipped and undelivered orders as misses

Shipium names on-time delivery and first-attempt delivery success as core delivery SLA indicators, and defines on-time delivery against the promised window. Most carrier and 3PL reports measure against their own commitment instead, which is why the carrier row in the example reads green. Promise-kept rate is the version the shopper experiences, and no vendor contract covers it.

Set the buffer from measured lane transit

A workable rule: take the last 90 days of delivered orders per lane (carrier service plus destination zone), find the 90th percentile transit time, and set the promise as the dispatch day your cutoff allows plus that p90, in business days. At p90, about one order in ten on that lane still lands after the date on transit alone, and that tenth is what detection has to catch. If Ground's p90 on the lane is four days, the honest promise was Friday all along. The lane history comes from your carrier integration.

Then give the dispatch leg slack inside the promise. Set the checkout cutoff earlier than the warehouse's contracted cutoff (checkout says 1pm when the 3PL contract says 2pm), so a late pick still makes the truck. And never put "within one business day" in a contract that sits behind a same-day promise: that clause is what let the worked example above report green.

Broken-SLA alerts: one order, while the date can still hold

A broken-SLA alert flags one order the moment it falls behind its own promise, while it can still be fixed. Vendor reporting looks back: Shipium's example clause gives a carrier that repeatedly misses 95% on-time delivery a 30-day corrective period, which does nothing for today's unscanned order.

That lag is how most brands find breaches today. Someone runs the daily reports, spots the late orders and emails the warehouse, or the brand hears about it when a shopper complains or a marketplace flags it. The storefront will not do it for you either. As I put it on a call, "Shopify is not reliable to report on e-commerce or service level; it certainly doesn't report on service level breaches."

On marketplace orders, breaches hide in two gaps: from order placed to the supplier entering a waybill number, and from the seller marking an item shipped to the first carrier scan.

Off the marketplace, the commonest breach never leaves the building. In the outbound view I walk teams through, a single day shows 80 orders still unshipped. That is clearly an upstream problem, every one of them has broken its service level, and every one will become a ticket unless someone acts before the shopper writes in.

Onboarding to Keeyu starts with a brand's own service level agreements, the rules every order is checked against. If a brand sets, for example, three business days for an express order to be processed, dispatched and delivered, that order is marked broken on the fourth business day, and the at-risk orders before that are the amber ones the workflow later on this page acts on. Every order is a promise. Keeyu keeps it.

Support's own SLA, first response time, belongs in the helpdesk, and Keeyu integrates with Gorgias and Zendesk. The difference between answering fast and knowing first is on the first detection time page.

Show it: the conversion case

"Arrives by Tuesday" beats "ships in 3-5 business days" at checkout, and Baymard's checkout research points the same way: 21% of users abandoned because delivery was too slow, and its fix is to show an estimated delivery date rather than a shipping speed for each delivery option. But understand the trade you are making: you are converting uncertainty into accountability. The vague range was unfalsifiable. The date is a test your operation sits every single order. It is also what makes the aggressive checkout promise safe to run: "order before 2pm, pay express, get it tomorrow" is only a conversion weapon when every order is visibly tracking against that promise. That trade is worth making, on one condition: something downstream has to be watching every order against the date you showed. I frame bad delivery as a marketing conversation, not only an operations one. If your CAC is $80 and you lose 25% of first-time buyers to bad delivery, that is $20 per order on fire. It is the death spiral: service drops, customers churn, and you spend more on acquisition to replace them. Which brings me to the part most delivery-promise content skips.

Keep it: the machinery behind the date

Leadership teams walk into diagnostics confident they run proactive operations, and the data routinely shows them firefighting 85 percent of the time, with WISMO dominating the queue. The promise was shown at checkout, and then nobody owned it, which is exactly the reactive tax in one sentence. Keeyu was founded on the other side of this: a warehouse sale at P.E. Nation in 2020 where stock issues surfaced only after customers complained. The first thing we built inside P.E. Nation after that was a very rudimentary early warning system, light years from the product today, and it still delivered: we saw a reduction in workload, a reduction in tickets, and an increase in both customer engagement and employee engagement. I see the same thing in the teams that run Keeyu now. The customer service team gains quality of life, because they are not firefighting anymore and their day is a lot calmer. The mechanics are on the on-time delivery page: track every order against its specific promise, catch the drift early, act while there is still time to keep the date, and when it truly cannot be kept, tell the customer first with a new date. What each failure mode means is on the delivery exception page.

The promise has to be written down as data before anything can keep it. Ours reads: order before twelve, pay for express, ships same day, arrives tomorrow. Every order is then scored against it and colored blue, amber or red, and amber is where a workflow fires, because that is the last point where the fix still beats the complaint. I described the model on Add To Cart.

The promise is the product

A GP at Emergence Capital described the opportunity we spent two years grinding toward better than we had: the biggest CX AI opportunity is beyond chatbot deflection, into proactive intelligence. Deflection manages the complaint about a broken promise. Proactive intelligence keeps the date so the complaint never exists. A helpdesk can only triage a ticket after something has gone wrong. As I put it on The Breakout CEO, if we can identify the thing going wrong before it becomes the customer's problem, and automate fixing it, the ticket never exists. It is why the promise engine and the helpdesk are not competitors: one calculates the date, the other apologizes for it, and the layer in between, detect, decide, act, is the one that determines which of them matters. Keeyu gets shoppers what they want, on time, as promised. The stack view lives on the order fulfillment system page, the whole discipline on the post-purchase operations hub, and your own promise-kept rate is one demo away. Every order is a promise. Keeyu keeps it. That is the entire company in six words, and this page is the keyword it lives on.

There are two ways a promise fails and only one of them arrives in your inbox. Some shoppers call and become a ticket. The others say nothing, and they are the ones who leave, which is how I put it on The Breakout CEO. A promise-kept rate counts both. A satisfaction score can only ever count the first.

• Keeyu customer results: keeyu.com/customer-stories
• The Breakout CEO #86, The Pivot This Founder Made After an Investor Called It Impossible - one in five US shoppers not getting orders on time, and the ticket ratios behind it.
• Marketing for SMEs, Jevon Le Roux on the E-Commerce Mistake Costing Millions - the orchestration layer.
• Shipium, Mastering Service Level Agreements (SLA) in the Shipping Industry - on-time delivery and first-attempt delivery success as delivery SLA indicators; contract components (scope, measurable delivery timelines, exclusions, reporting and escalation, remedies); the outsourced-warehouse blame example; the 95% on-time delivery corrective-period contract example.
• ShipNetwork, Optimizing Order Accuracy for Ecommerce Fulfillment SLAs - order accuracy split into picking, packing and shipping accuracy.
• USPS, USPS Ground Advantage - Ground Advantage delivered in 2 to 5 days.
• Baymard Institute, How to Reduce Cart Abandonment (Data-Backed UX Strategies) - 21% of users abandoned because delivery was too slow; the recommended fix is an estimated delivery date rather than a shipping speed for each delivery option.