Who is this for?
Read this if you are an operations or marketing person looking to increase cart conversion by merchandising delivery dates.
Summary
A delivery promise is an estimated delivery date which online stores show customers before purchase. “Buy it today, get it Thursday!” Communicating a delivery date after purchase is a basic ecommerce interaction. Starting to estimate the delivery date before purchase, in real time, is much more difficult. Large ecommerce companies started to add a delivery promise, and it led to a demonstrative increase in cart conversion percentage.
Overview
Consumers expect to be told when they will receive the things they buy online.
Traditionally that is managed after an order is processed. Customers get notified of an estimated delivery date via an email during the post-order flow.
Increasingly, consumers are making purchase decisions based on knowing an estimated delivery date before they actually buy something. A recent study of consumer shopping preferences showed that 83% of shoppers agreed with the statement "An accurate delivery date (i.e. “Buy it today, get it Thursday”) is important to me when deciding whether to buy a product from a website."
Not many stores adhere to this customer preference. Visit most ecommerce sites and go to the product detail page, you will usually see something like “Usually ships within 2 days.” As a consumer, this doesn’t help. All the consumer really cares about is when they will get the product, but instead sites give an SLA for the Fulfillment Center. This is a great example of focusing on what’s easy to implement over what actually matters to the customer.
Large ecommerce businesses—like Walmart, Target, Amazon, Home Depot, and other—have invested in a delivery promise, however, and pushed this expectation over the years because they know it matters to customers. Let's take a look.
Here we have an example of Amazon showing estimated delivery dates. They went so far as to position it as a delivery promise, showing the fastest delivery time available. Recent advancements also have an "Order by..." timing mechanism down to the minute.
Once Amazon expanded to a marketplace model, they extended estimated delivery dates to sellers who use Fulfillment By Amazon (FBA). Here is an example of a seller who uses FBA which affords them the same customer experience benefit of showing a delivery promise on the product detail page.
Now if we look at Loog—who makes awesome music instruments for kids, by the way—we find the absence of that delivery promise. Instead, we see "SHIPS IN 1-2 WEEKS". For customers who want it faster, they will pick Amazon, which means Loog gives up 15% margin.
Loog is a relatively small company, though. So what about large brands with mature storefronts or fulfillment processes? A similar experience exists.
Here we have Helly/Hansen sold on the Amazon marketplace. The default option is via the reseller Backcountry, who does not use FBA, but still gives a delivery date range.
Meanwhile there is another seller, Big Weather Gear, who does use FBA and thus gets a delivery promise.
Whereas if we look at HH's site, there are no estimates at all.
Interestingly, Backcountry is itself a very large ecommerce retailer, with estimated annual online revenues over $500 million making them one of the largest 200 ecommerce sites. If we look at the same product on backcountry.com, we don't see any delivery estimates at all.
Beyond price, for customers who are looking for predictable delivery, of which there is a large cohort of people like this based on our insider knowledge over the years at Amazon, it makes sense to buy on something like Amazon.
Other ecommerce leaders have invested in this idea, too, and they deserve credit in helping shift consumer expectations.
Here we have how Walmart handles it. Simple, effective, and to the point.
Target is even more aggressive with delivery promises for fast shipping, in addition to providing basic free shipping.
And perhaps the company with the most rapid innovations lately is Home Depot, who not only display a delivery promise, but have done an excellent job of bringing in ship-from-store and curbside-pickup.
Any company who presents an estimated delivery promise will experience better conversion and loyalty. So why doesn't every store do it?
The screen real estate for displaying a simple date is small, yet the technical requirements behind the scenes are huge. A real-time, SKU-specific estimation displayed on a screen requires integration with the following systems:
- Frontend (Store, like Shopify or Magento)
- Inventory
- Fulfillment
- TMS / carrier network
- Policies
Shifting a company's internal processes towards customer delivery will require changes to metrics, data, and culture. Practically, it expands the operations team area of responsibility to measure and monitor all stages of the delivery process. In most companies this is a major change from just getting a high level monthly metric of missed SLAs in the FC.
A delivery promise provides a unique advantage in the form of merchandising your supply chain. We often find ecommerce partners actually deliver faster speeds than they advertise, missing a major opportunity. Customers that are geographically close to their fulfillment centers will receive the order in 2 days even with cheaper ground methods. Without the delivery promise you lose the opportunity to merchandise that speed. Faster delivery times can improve conversion by up to 12%.
Anchoring your processes and metrics on delivery promises also gives you the ability to optimize your processes within the overall delivery estimate. Let’s take the simple example of a subscription where you’ve established a monthly delivery date that the customer receives their product. If later on you are able to identify a cheaper delivery method that takes longer to deliver you have the ability to just ship the customer's shipment earlier and still hit the delivery estimate.
For older companies, those systems are usually managed with older fragmented software, so any innovation requiring interoperability is difficult and expensive to set up.
For newer companies, no real platform concept exists to connect all these systems, so they are left with fragmented spreadsheets instead of fragmented ERPs/WMSs.
So what should an ecommerce store do? We'll walk you through the playbook.
The Plays
First thing to know is the destination ZIP. If you have a user account system set up, you can pull the ZIP from the customer profile. If the user isn't logged in, you could check if a previous order had been made and saved to a cookie, which can pull the ZIP from that previous order. Lastly, you can assume the ZIP based on checking the user's IP address, but to ensure accuracy, you may need to request the user enter the destination ZIP on the product detail page before showing a projected date.
The next thing needed is the SKU. Your frontend store will know the SKU because the user is viewing the product detail page for that SKU, so that’s simple.
From there, the frontend makes a call and sends those two data points to the inventory management system to know how many items of that SKU are left across which fulfillment centers (FCs).
The inventory management system now knows the SKUs and the destination ZIP, but the origin ZIP is required to estimate a delivery date. It’s easier with one FC, but as soon as you have two or more FCs, the origin ZIP decision gets much harder because you must make a choice of which FC to ship from. That’s not as easy as you’d think for the following reasons:
- Inventory levels matter. Your policies and processes around rebalancing should come into play.
- Carrier methods might be different based on regions.
- And is even more pronounced if you use local carriers or last-mile partners in specific urban centers, too.
- If displaying an estimated delivery date during checkout, if an order has more than one SKU, then the problem gets exponentially harder because analysis must happen with all those SKUs simultaneously.
- Package properties (dimensions, weight) matter for shipping method and policy assessment.
Consequently, the next step is to cross-reference shipping policies and carrier contracts with SKUs and FCs. Policies are usually set monthly based on rate sheets, and thus are static. The static nature can impact the probability of precision, however, so it's best to try to move that to real-time rates analysis. A TMS which supports real-time is ideal.
Given all these inputs, the system then runs an algorithm to determine the most precise delivery date available. The result is returned back to the frontend store, which then displays the information back to the consumer.
Gotchas
Complexity
The problem is multidimensional. It gets increasingly more complex the more FCs, SKUs, carriers/methods, packaging options, and shipping policies you have within your system.
Managing Trade Offs
How do you pick an estimated date? Do you pick the cheapest date? Or the fastest? Or somewhere in between? The answer is that the date picked will always be based on trade offs, so it’s up to you and your company to decide where you land on the trade off spectrum.
In general, it’s best to optimize towards returning the fastest projected estimated delivery date, as that is a more marketable value. Customers who want things fast or by a specific date are actively looking for that when considering a purchase. Then, you can allow customers to move back down towards a cheaper or free shipping option if they value cost instead of speed.
Real-Time Results
Delivery dates need to be determined in real-time. This play doesn’t work well going off of historical or static value, e.g. always displaying a date 3 days out because your policy is “We ship everything 3-day ReadyPost” or something like that. The complexity of inputs going into the estimated date is too immense to rely on static values.
Cut-off Times
Managing the latest an order can be made on a given day is an important consideration to improve precision. For example, if today is Tuesday, don’t include Tuesday in your estimated time if the order is being made at 8pm local time to FC that is shipping the order.
Metrics
Accuracy: Log all displayed estimated dates. Connect a displayed date with an order placed, then track when the order was delivered via carrier APIs. Check if the date delivered matched the projected delivery date, and track an variance either way. Industry best practice is to be over 90% accurate.
Conversion Percentage: Log if an estimated delivery date was displayed for a given order. It’s easy to A/B test to see its effectiveness. Industry reports show conversion should increase between 6%-12%.
Trade Off Speed/Cost Balancing: When determining an estimated delivery date, it’s helpful to log all possible dates that were determined for your given policies. For example, maybe the fastest date was 2-day, but 3-day was a full $5 cheaper. You could have potentially saved the money while still leading to a conversion if the customer was fine with 3 days over 2 days.
How Shipium Does It
Adding a delivery promise is a play that Shipium was built to support.
We provide an API which customers call, sending us their product and customer information for a given SKU. We then return an estimated delivery date with precision accuracy. Customers confidently display that returned date into their storefront interfaces, such as product detail pages or cart checkout flows.
Set up is easy and only needs to happen once. Customers set up FC network information and to their shipping policies. If those ever change in the future, it’s very easy to update and adjust.
We give customers a JavaScript snippet, which is easily embeddable and has thorough documentation.
The basis of our API is the analysis of all the complex input discussed above. Fine tuning it to be precise and accurate is based on our experience building this at Amazon and Zulily.