What Actually Happens to Your Package Between the Order Confirmation and the Doorstep
"The tracking status that says 'processing at facility' means the package arrived and nobody has scanned it yet. It's the logistics equivalent of being on hold."
You confirmed your order at 7pm on a Tuesday. By Thursday morning, someone rang your doorbell and left a box. What happened between those two moments is a process involving at least five distinct systems, multiple physical handoffs, and a sequence of decisions made by software that has no idea what you ordered or that you personally are waiting for it.
Understanding this process changes how you interpret the tracking page. It also, if you work in software, gives you a concrete example of how enterprise systems interact in a domain where the stakes are physical, a late package is a real-world consequence of a software decision made the previous Tuesday evening.
From Order to Pick Task
The order confirmation email was sent by the retailer's order management system within seconds of your payment clearing. Behind the scenes, that confirmation event was also published to a message queue that the warehouse management system was listening to. By the time you were reading the confirmation email, the warehouse management system had already received the order and created what's called a pick task.
A pick task is an instruction for a warehouse operative: go to this location in the warehouse, pick up this many units of this product, bring them to the packing station. At large fulfilment centres, the kind operated by major retailers and logistics providers, pick tasks are not created one at a time and handed out individually. They are batched into what's called a wave: a set of pick tasks that can be executed together efficiently because the items they require are clustered in the same zones of the warehouse, or because they're destined for the same carrier run, or because they can be processed by the same packing station without cross-contamination between orders.
Wave planning is a discrete optimization problem. The warehouse management system has to decide which orders to group into a wave, in what sequence to release waves, and how to route the picking path through the warehouse to minimize travel distance. At a warehouse that processes tens of thousands of orders per day, the difference between good and bad wave planning can be measured in hours of throughput. The routing problem is a variant of the travelling salesman problem, and warehouses spend meaningful engineering effort on the algorithm that solves it, or on the tradeoffs that make a good-enough solution run fast enough to be practical.
The Warehouse: Zones, Slots, and Scanning
Physical warehouses are divided into zones based on the characteristics of the items stored there. Fast-moving items, the top 100 or 200 products by order volume, are stored close to the packing stations to reduce travel time. Heavy items are stored low to avoid ergonomic problems. Items that require temperature control are in dedicated zones with their own environmental monitoring. Hazardous materials have their own storage and handling rules that override the standard wave logic.
Every product has a storage location in the warehouse management system, a slot identifier like A-12-3-B (aisle A, rack 12, level 3, position B). When a pick task is created for a product, the WMS looks up its current slot, confirms inventory is available at that slot, and includes the slot identifier in the pick task instruction. If the product has been moved, because the warehouse has undergone a slotting review to reoptimize positions based on recent demand patterns, the WMS needs to have the updated slot. Picking from the wrong slot results in either a missing item in the order or an inventory discrepancy that manifests at the next stock count.
Each item picked is scanned with a barcode reader. The scan serves multiple purposes: it confirms that the picker picked the right item (the barcode has to match what the pick task specified), it confirms a unit was removed from the slot (updating inventory in real time), and it creates an audit trail. If a customer later claims they didn't receive an item, the warehouse can show that item X was scanned by operative Y at time Z at slot A-12-3-B and placed into tote T-445.
Packing and Cartonisation
Packing sounds simple: put the items in a box. The operational reality is slightly more involved.
Cartonisation is the process of deciding which box size to use for a given order. Using a box that's too large wastes space in the carrier vehicle, wastes packaging material, and sometimes results in items moving around in transit and arriving damaged. Using a box that's too small doesn't work. Cartonisation algorithms attempt to determine the smallest box that will fit all the items in the order given their dimensions and fragility, accounting for the need for padding around fragile items and for items that have irregular shapes.
This is another combinatorial optimization problem, and it's complicated by the fact that item dimensions in the WMS are often wrong, the dimension data comes from product setup teams who measure items from descriptions and manufacturer specifications, and the actual dimensions of a physical product are sometimes different from what the specification says. Warehouses with high accuracy requirements invest in physical dimensioning systems that measure and weigh items automatically as they're received, updating the WMS with actual measurements rather than nominal ones.
At the packing station, the operative scans each item before placing it in the box. This is the final confirmation that the right items are in the right order. The packing scan closes out the pick task for each item and opens a new record type in the WMS: the shipment record, which will eventually link to a carrier tracking number.
The Carrier API and the Label
Once the order is packed and the box is sealed, the packing station needs to print a shipping label. The label is not generated by the warehouse, it's generated by the carrier, through an API call that the retailer's shipping system makes at this moment.
The shipping system calls the carrier's API with: the sender address (the warehouse), the recipient address (you), the weight and dimensions of the package, the service level (next-day, standard, international), and sometimes a declared value for insurance purposes. The carrier's API responds with a tracking number and a label in PDF or ZPL format. The label is printed, applied to the box, and the box moves to the carrier sortation area.
The tracking number is stored in the retailer's order management system and linked to your order. This is the number you use on the carrier's tracking website. The carrier's system knows, at this point, that a package with this tracking number was created for collection at this warehouse. It does not yet know where the package physically is, it was just labelled, not scanned.
The tracking status that says "label created" or "shipping information received" means the label exists and the tracking number has been registered. It does not mean the carrier has the package. It means the carrier knows the package exists in principle.
Collection, Sortation, and the "Processing at Facility" Update
At some point in the evening, or early morning, depending on the carrier's collection schedule, a driver arrives at the warehouse with an empty van and leaves with a full one. The packages are scanned during loading, creating the first carrier-side scan event on the tracking history. Your tracking page updates: "picked up from sender."
The van takes the packages to a carrier hub, a regional sortation facility. At the hub, packages come off the van and onto a conveyor system. Each package is scanned automatically as it moves through the facility. The scan reads the barcode, looks up the destination in the carrier's routing system, and diverts the package to the appropriate chute for its onward destination. A package going to a different region goes onto a trunk vehicle. A package going to a local area goes to the local delivery depot.
The "processing at facility" status on the tracking page means the package arrived at a hub and has been scanned at intake but hasn't yet been processed through the sortation system. It can sit in this status for several hours if the facility is busy or if the package arrived at an odd time. It is the logistics equivalent of being on hold: you are in the queue, the queue is moving, but nothing visible is happening yet from your perspective.
Last Mile and "Out for Delivery"
Last-mile delivery, the final step from the local depot to your door, is operationally the most expensive and most variable part of the delivery process. It involves a human driver making decisions in real time: traffic, parking, access codes for buildings, customers not being home, re-delivery requirements. The routing optimization that determines the sequence in which a driver visits their delivery stops is a continuous process: the depot's routing software produces an initial sequence, the driver may modify it based on local knowledge, and in some cases the route is reoptimized in real time based on GPS tracking of where the driver actually is.
The "out for delivery" status means the package has been loaded onto a delivery vehicle at the local depot and the vehicle has left. It does not mean the package will definitely arrive today. If the driver's vehicle is overloaded, or if there are too many stops, or if road conditions slow the route significantly, some packages don't make it off the van before the driver's shift ends and are returned to the depot for delivery the next day. The software marks them as "delivery attempted" even if, technically, no attempt was made, the package simply didn't reach the front of the queue.
The delivery estimate shown on the tracking page is the carrier's probabilistic prediction based on historical performance for the service level and destination. It is almost always optimistic, because it's based on average performance rather than worst-case performance, and because conditions on any given day (volume spikes, driver absences, weather) can push a delivery outside the average envelope without any system flagging it in advance.
What This Means for Engineers Working in This Space
Logistics software is an excellent domain for learning about the engineering challenges of coordinating physical and digital state. Every event in the physical world, a package being picked up, scanned, sorted, loaded, delivered, needs to produce a corresponding event in the digital tracking system, in near-real time, with enough reliability that the tracking information is trustworthy rather than decorative.
The failure modes are specific: a scan that didn't register (package moves physically but tracking doesn't update), a barcode that didn't scan cleanly (package routed to wrong chute), a carrier API that timed out (label not generated, package held at packing station), a routing update that arrived too late (driver already past the optimal sequence point). Each of these has a cost that shows up in customer experience metrics: late deliveries, incorrect tracking information, packages lost in the system between two scan events.
The systems that handle these failure modes well are the ones that have explicit, observable state at every physical handoff point, retry logic for every API call, and reconciliation processes that identify discrepancies between physical and digital state before they compound. The systems that don't handle them well produce the kind of tracking experience that everyone has had: the package that shows as "in transit" for four days with no updates, which usually means it arrived somewhere, wasn't scanned at intake, moved physically through the network, and eventually appeared at your door without the digital record having followed it at all.
Tags