Accurate Delivery Date Estimates Are Hard.

 

#1 in our 3-post series

That's why most eCommerce sites don't do them--or don't do them right. In this post we'll take a look at why accurately estimating delivery dates is so hard, and what you actually need to do to estimate an accurate delivery date.

Why So Hard?

Explaining why it's so hard is actually easy. We (well I, who am not a designer) drew a picture:

Yeah, I know, it ain't pretty. But it'll suffice to help us walk through all the data feeds that are critical to an accurate delivery date. To wit:

• Customer Information: In just about any business scenario, the most important information to consider is going to be related to the customer. In the case of estimating delivery dates, that couldn't be more true: you have to know where the customer is physically located. You can do this by looking at a known customer's profile info, or geo-locating them based on their IP address for unknown customers. If you want to get really fancy, you can look at customer on-site behavior, purchase history, and/or loyalty status, and factor that into the shipping options displayed, e.g. giving loyal customers free expedited shipping.
• Product: You can't calculate a shipping cost without package weights and dimensions, and that information is generally stored with product data. If you're really clever, you can set up rules and a machine learning algorithm to optimize the box size used to pack a given group of items (and continuously get better at doing this). And if you are really, really clever, you can factor product profitability into the equation, e.g. providing free shipping for products with high margins.
• Inventory: In order to figure out the delivery date, you need to know not only where the package is going to, but where it's coming from. Needless to say this is REALLY important if you ship from more than one fulfillment location. And if you are an omni-channel retailer (like say Men's Wearhouse) shipping from hundreds of stores in addition to DCs--while it can get pretty hairy, with the right analytical engine you can figure it out. In fact, for the really fancy types with multiple inventory locations, you can ultimately use this process to load-balance demand across inventory locations by determining the best location to fulfill from on the fly--and presenting shipping options that comprehend this.
• Fulfillment Operations: This data is so voluminous it could spawn its own blog post, and very well might. But to summarize, calculating an accurate delivery date requires--at a minimum--the following data from each of your fulfillment locations: days and times the facility is open (and closed, e.g. holidays), carrier pick-up times for all the carriers you use, order cut off times, and available standard package sizes and capacities. If you want to get really fastidious, throw in configurable warehouse-specific lead times, in case something goes awry (e.g. weather event, carrier slow-down) and you need to add a little cushion in certain locations.
• Delivery: This data stream consists of your negotiated rates--across all the carriers and services you have access to. These are typically API-accessible and will return not only a cost but (for most services) a transit time estimate for any given source/destination and shipping parameter data you pass them. To get really fancy with this data you can build a machine learning algorithm that constantly monitors carrier performance--e.g. actual vs estimated transit times--and adjusts your delivery date estimates based on historical performance.

Doing It Right

As our (ahem) snazzy graphic above shows, if you mash all this data together--in real time--in a powerful enough analytics engine, you can get an optimized set of shipping options, delivery date estimates, and costs. To do this right you have to do it in real time: at the moment a customer looks at a product page, for example, you take their zip code, the zip code of the inventory they have selected, and the order's shipping parameters (wts/dims/packaging of each item); then feed these to the carrier APIs to get back different service level options, each with associated costs and transit times. Then factor in the time of day vs. fulfillment operational parameters (cut-off times etc), and voila! You can present as many shipping options as you want, all with accurate estimated delivery dates and costs.

Hopefully, the power--and difficulty--of this process is apparent. There's a lot of variables that have to be perfectly managed, in real time, in order to provide an accurate date (and for that matter cost) estimate to a shopper when it matters most.

But Wait! There's More! In my next post, I'll talk about how some sites try to Jedi-mind-trick their way around providing accurate delivery dates, and some of the cool ways you can use the concepts discussed above to provide a way better experience for your customers. Stay tuned for that, but in the meantime I'd love to hear your thoughts on this post in the comments!