Hope for Delivery

Logistics are hard, but there are plenty of low-hanging UX fruit with most of the popular shipping companies. Here's an example from UPS, but others do this as well: Delivery time estimates!

Back in the early days of mail order, there were no real shipping estimates – the sellers would give a general idea of how long it would usually take them to process your order, how long the postal service (appropriate singular here) would usually take to deliver a parcel, and that was that. End to end, from submitting your order via postal form or, later, fax, to receiving your order, the process would often take a week or more. And of course, there was no tracking, especially not real-time: At best, the sellers could get batched updates whether their parcels were delivered, but usually one would simply assume things arrived within an expected timeframe, or else the undeliverable parcel would arrive back at the facility.

From a consumer perspective, the modern age with instant online ordering, immediate processing, shipping confirmations, and real-time tracking is obviously much improved and much more convenient. The almost complete quantization, then digitization in parallel with ruthless optimization, of the logistics industry has made this possible (at non-negligible human and societal cost, I might add).

And yet things like this happen:

First, a shipment notification is sent. The sender passed on my delivery address and email address to the shipping company, in this case, UPS. UPS then estimates the average runtime of a parcel from the originating logistics center (in this case, in the Netherlands) to the destination (in Berlin). They probably err on the side of caution here, as overpromising and underdelivering usually is a far worse customer experience than the reverse. This estimate is performed on Friday, March 29, just before the Easter weekend.

Then, as the package physically moves from the sender through UPS' facilities and planes, trucks, or trains (I wish), UPS can update the estimated time of arrival. Unfortunately, in this case, as in many other cases including with other shipping companies, the notification comes very late. On the morning of April 3rd, at 9:00, UPS emails me to tell me the package will not arrive on Thursday afternoon, as expected and announced, but instead on Wednesday afternoon, the same day they send the email. The time window communicated goes from 12:15 to 16:15, still – so that in the worst case, there is a little more than 3 hour warning. For people who don't work from home or who aren't in the same office every working day, this already makes it nearly impossible to re-plan to receive the parcel in person if they had previously planned with an arrival one day later.

Here's the real kicker, though. At 10:01 on April 3rd, UPS emails again to inform me that the parcel is just about there. Weirdly enough, they now update the delivery window to begin 40 minutes before they sent the email:

Now, looking at the actual tracking history of the parcel is informative. The UPS website hides the details by default, but users can click through to the detailed history with timestamps. This particular package has been underway for a few days:

• 2024-03-29 01:23 Shipper created a label
• 2024-03-29 06:53 Package picked up
• 2024-03-30 04:56 Departed from Facility (NL)
• 2024-04-01 06:29 Arrived at (Forwarding) Facility (DE)
• 2024-04-02 03:56 Departed from Facility (DE)
• 2024-04-02 08:00 Arrived at (Delivery) Facility (DE, near Berlin)
• 2024-04-03 04:56 Processing at UPS Facility
• 2024-04-03 09:52 Out For Delivery

Between UPS receiving the shipping data from the sender and emailing me the first estimate for the delivery, over 18 hours pass. Part of the reason is the batching of goods: Before collecting all new deliveries on a day, UPS cannot know exactly how much space they need to forward them, or where to, or at which priority. Once they have collected sufficient data, they make first estimates and inform recipients.

Batch processing is evident in the further history of the parcel, too. Packages get collected around a departing facility, processed when they arrive, and batched for forwarding to receiving or forwarding facilities. Since this parcel crosses country borders, it goes from a central facility in the Netherlands to a central facility in Germany, from where it is forwarded to the final delivery facility near Berlin a day later, arriving only a few hours later, but it does not get processed until the next morning.

By April 2nd, around 8:00, UPS should have had enough information to update their delivery estimate: The package was scanned on arrival, so they know its intended destination, priority, and so on. It could still make sense to defer the estimation while they gather more data (in this case, the data arrives in the form of packages and shipping containers), but at this point, it was very likely the parcel would be delivered the next day.

It is not until the early hours of April 3rd that the parcel is actually "processed" in the final facility. In this case, that likely means sorting into the specific tour that passes by my delivery address. By then, it should be quite certain that the package will be delivered that day. Still, the notification does not get sent until 9:00, when most people will already have left the house to go to the office, or otherwise started their day. As the driver starts their tour at 9:52, the delivery window is narrowed down.

The final update is the worst part of this user experience journey: By 10:01, UPS informs me the parcel might be delivered by 9:20, over 30 minutes before the driver even departed the facility.

Notoriously, the delivery windows often still don't work out: Traffic, road conditions, recipients at other stops not being home, and other vagaries of life can interfere to delay delivery or, sometimes, make it early. But never have they managed to travel backwards in time, so far.

Potential Improvements

The most obvious improvement would be to update estimations sooner. As logistics is a system of systems, every transition within the system can be quantized and thus predicted. We need not even go into fully instrumented, big-data IoT territory here, merely tracking of each process step and a basic statistical model with sensible confidence intervals.

Optimizing the performance of the technical system is another important part: Are notifications sent late due to product decisions such as "we should not email people at 5:00 in the morning" or because the processing takes too long? This quickly balloons into covering the entire ecosystem: the UPS website and mobile app are not great and not easy to use for consumers, so they would not be a reliable channel for real time, pull, or push notification based updates.

An option that is unlikely to be considered would be to stick to the initial estimate and artificially delay shipments. Would customers prefer being able to reliably plan ahead, or would they rather have a package a day early? Not only does this veer into preference territory, but it comes with a host of logistical challenges: Parcels that don't move take up room and clog up the system. Doing this at scale might easily become problematic. But there might be ways to limit the scope, e.g. to consumers (versus businesses, the main customers of UPS), to estimate corrections of no more than one day, to customers who opted in, and so on. Specifically for UPS, as a consumer, it can become quite annoying if you miss the delivery driver, as your parcel could end up in a pickup location quite far from the original delivery address: UPS pickup points are much sparser compared to others here.

Finally, there are some basic sanity checks that could be implemented, such as clamping the communicated delivery estimate to reality: If the driver leaves at 9:56, don't email at 10:01 to give a delivery window starting from 9:20.

PS: The UPS van came through at 11:04, but the driver did not actually attempt delivery. Instead, UPS emailed at 11:38 that the parcel would go to a pickup point. Obviously, lying to people is the worst UX of all.