Between the Order and the Doorstep, a Dozen Small Decisions

Most writing about automated logistics is aimed at companies with a warehouse management system and a carrier contract negotiated by a person whose entire job that is. This is the other version. You pack the orders yourself or you pay somebody who does, you have one or two carriers, and the question is which of the decisions in between are worth handing to software.

The answer is more of them than you would think, but not the ones the software is usually sold on. The expensive mistakes in fulfilment are concentrated in two places, the promise you make before the order and the exception you handle after it, and both are places where automation helps most by flagging rather than by deciding.

What are the decisions, exactly?

There are twelve worth naming, and they run in order from the moment a customer clicks pay. Each one has a natural failure mode, and for each one the honest question is what a wrong answer costs.

Read the right hand column as a spending plan. Rows 1, 4, 9 and 10 are close to free and remove most of the support load. Rows 2, 8, 11 and 12 are where a wrong automatic answer costs you a customer or a legal position, so they get a flag and a human.

Why is the delivery date a legal statement rather than a marketing one?

Because two separate regimes treat it as a commitment with a remedy attached. The date on your product page is not a hope, it is the thing a regulator and a court will measure you against, and tightening it to win conversions raises your exposure rather than lowering it.

In the United States the relevant text is the FTC's mail, internet or telephone order rule. Its business guide requires shipment within the time you clearly stated or, absent a stated time, within thirty days after receipt of a properly completed order, which it defines as the point where you have both payment and all the information needed to process and ship. The standard for the promise is a reasonable basis, meaning information that would satisfy a reasonable and prudent businessperson acting in good faith that the representation is true.

Miss it and the rule is specific about what happens next. You send a delay notice carrying either a definite revised shipment date or a statement that you cannot provide one, plus a way for the customer to cancel at your expense. For delays of thirty days or less, silence from the customer counts as consent. Where a refund becomes due, it goes out within seven working days of the right to refund vesting.

In the EU, Article 18 of the Consumer Rights Directive sets the same thirty day outer limit unless the parties agreed otherwise, then gives the consumer a right to call for delivery within an additional reasonable period and to terminate if that is missed. Where delivery timing was essential to the agreement, termination is immediate. On termination the trader reimburses all sums paid without undue delay.

The two regimes agree on the number and disagree on the trigger. The FTC clock starts when you have a properly completed order, which is payment plus complete information. The EU clock starts at the conclusion of the contract. That difference matters if you sell into both markets with an order flow that collects something after payment, because your American clock has not started and your European one has.

What does a delivery estimate actually depend on?

Six inputs, and only two of them belong to the carrier. Most shops treat the estimate as something the carrier supplies and then get surprised when it is wrong, because four of the six variables are theirs.

Address confidence comes first, since an address that will fail validation has no delivery date at all. Stock location decides the origin and therefore the lane. Your order cutoff time decides whether today counts. Your own pack time is the gap between the order landing and the parcel leaving, and for a solo shop packing twice a week that number dominates everything the carrier does. Carrier transit time is the published lane. Exception rate is the share of parcels on that lane that go wrong, which you can measure from your own history and the carrier will never volunteer.

The research literature on this is more useful than it looks from the titles. A 2021 paper on modelling the customer promise date in fashion commerce frames the trade off precisely: predicting a date later than the actual delivery risks lost sales, while promising earlier than the actual delivery leads to poor experience and churn. That asymmetry is why the authors reach for loss functions that penalise the two errors differently, and it is the same asymmetry a merchant feels without the vocabulary.

A more recent result puts numbers on what better estimation buys. Work on conformal predictive distributions for order fulfilment time reports machine learning point predictions outperforming an existing rule based system by up to 14% on accuracy and up to 75% on identifying late deliveries. Those two figures should be read very differently by a small shop. A 14% accuracy gain on a date needs a data team you do not have. A 75% improvement in spotting the parcels that are going to be late needs only that somebody looks at the tracking feed, and that is the version available to you.

Which single change is worth the most?

The order cutoff time, and it is not close. It is the only input in the list you control completely, it costs nothing to change, and it moves every estimate on your site by a full day in either direction.

Most small shops set a cutoff optimistically and then miss it. If you genuinely pack at four and the carrier collects at five, a two o'clock cutoff is honest and a five o'clock cutoff is a promise you break on any day something goes wrong. Setting it early and beating it is the cheapest goodwill available in retail, because the customer compares the parcel against the date you gave rather than against what was possible.

The second most valuable change is measuring your own pack time rather than assuming it. Take ninety days of orders, compute the hours between order placed and label created, and look at the ninetieth percentile rather than the average. The average describes a quiet Tuesday. The ninetieth percentile describes the days your estimate has to survive.

Is address validation worth paying for?

Yes, and it is the clearest return in the whole chain. A failed delivery costs the outbound postage, the return leg, a support conversation and usually a refund, so preventing a small number of them pays for the service several times over.

What to ask a vendor about is certification rather than accuracy. In the United States the postal service runs the Coding Accuracy Support System, which evaluates the accuracy of software that corrects and matches street addresses, and certification must be renewed annually. Since the 2007 cycle, certified software also performs delivery point validation, which verifies whether an address is actually deliverable rather than merely well formed, and checks the locatable address conversion system for addresses that have been renamed or renumbered.

That distinction between well formed and deliverable is the whole point. A validator that only standardises formatting will happily accept a house number that does not exist on a street that does. Delivery point validation is what catches it, and it is the feature worth confirming is switched on.

One practical warning. Address correction at checkout should suggest, never silently overwrite. Customers with flats, farms, business parks and newly built streets know things the reference file does not, and a validator that quietly rewrites the second address line generates the exact failure it was bought to prevent. The same principle governs route planning, where the quality of the address data does more work than the clever part, as we set out in the piece on what route optimisation really is.

Where does the money leak?

Into boxes full of air and into split shipments. Both are invisible on an invoice that reports a total rather than a breakdown, and both are fixable with a tape measure and an afternoon.

Carriers bill on whichever is greater, actual weight or a volumetric figure derived from the parcel's dimensions. The consequence for a shop selling light bulky goods is that the box size, not the product, sets the price. Measuring your twenty best sellers in their packed state and matching them to three box sizes rather than one usually removes a meaningful share of the bill, and it is the sort of exercise that pays once and keeps paying.

Split shipments leak differently. An order that draws from two locations becomes two labels, two handling events and two chances to be late, while the customer experiences one order and judges it by the slower half. If your stock sits in more than one place, the allocation rule should prefer a single origin even when that origin is slightly further away, because the second label costs more than the extra transit day.

The third leak is the one nobody budgets for, which is peak. Carrier surcharges, longer lanes and your own reduced capacity all arrive in the same six weeks, and the automation you switch on in November is the automation you have not tested. Configure it in the quiet months instead, which is the argument we made in the piece on switching automation on in August rather than November.

What should be handled by a person?

Anything where the wrong answer is expensive to reverse. That is a short list, and keeping it short is what makes the rest of the automation safe.

Customs declarations belong to you. The commodity code and the declared value on a cross border parcel are a legal statement made in your name, and a model that guesses a code because the description sounded similar has exposed you to a penalty you will hear about months later. Software can propose the code from your own catalogue history. You confirm it. We went through the mechanics of that in the piece on the customs code on your parcel as a legal statement.

Fraud decisions belong to you at the margin. Automatic scoring is fine and automatic cancellation is not, because the cost of blocking a genuine customer is a lost relationship and the cost of reviewing a flagged order is two minutes.

Goodwill decisions belong to you always. Whether to resend a parcel that a carrier marked delivered and a customer says never arrived is a judgement about a specific person's history with you, and it is precisely the decision a small shop is better at than a large one. Handing it to a rule removes the only structural advantage you have.

Returns sit in between. Approving a return that falls inside your published policy is mechanical and should be automatic, since every hour of delay there costs you a resale window on the item. Anything outside policy, damaged, past the window or unusually frequent for one customer, goes to a person. The boundary we drew in the piece on which parts of returns to automate applies unchanged here.

How do you tell if a parcel is stuck before the customer does?

By watching for the absence of scans rather than for a bad status. Carriers rarely publish a status that says this parcel is in trouble. What they publish is a sequence of scans, and a parcel in trouble simply stops producing them.

The rule that catches most of it is unglamorous. For each carrier lane, compute the normal gap between consecutive scans from your own history. Flag any parcel whose last scan is older than roughly twice that gap and which is not out for delivery. On most lanes that fires a day or two before the customer notices, which converts an angry email into a message from you, and those two situations have completely different outcomes.

The second rule catches the other common failure. Flag any parcel marked delivered where the delivery scan happened more than a short window before the promised date, since early delivery scans correlate with parcels left in unexpected places. That is a small population and a high hit rate.

Does any of this need a machine learning model?

Mostly no. Eleven of the twelve decisions are rules you write once against your own data, and the honest reason to prefer rules is that you can explain them to a customer.

The exception is the delivery estimate itself, where a model genuinely beats a rule because the inputs interact. Transit time depends on origin, destination, service, day of week and season together rather than separately, and that is exactly the shape of problem a model handles better than a lookup table. Even there, the sensible first version is empirical rather than learned: take your own last twelve months of delivered orders, group by carrier lane and destination region, and quote the ninetieth percentile transit rather than the carrier's published one.

That single change usually improves the promise more than any purchased model, because the carrier's published time describes their intent and your history describes their behaviour. And if your storefront cannot render a per product, per region delivery estimate on the product page, the limitation is the platform rather than the data, which is one of the everyday arguments for running a shop whose pages you can change yourself.

A sequence to work through

If you are starting from nothing, the order below spends the least money for the most relief. First, turn on address validation with delivery point checking and make it suggest rather than overwrite. Second, set an honest cutoff time and publish it. Third, replace the carrier's published transit time with your own ninetieth percentile, per lane. Fourth, build the missing scan alert, which is a scheduled query rather than a product. Fifth, measure your packed dimensions and buy two more box sizes.

Only after those does it make sense to look at allocation logic, automated returns approval or anything sold as an optimisation engine. The first five are a week of work in total and they remove the majority of delivery related support volume, which is the real currency here. Every parcel that arrives when you said it would is a conversation you never have.

The through line across all twelve decisions is that fulfilment rewards conservatism in the promise and aggressiveness in the detection. Be pessimistic about the date and quick about the exception, and most of the rest is arithmetic you can do in a spreadsheet.