A courier product's user experience is almost entirely determined by one thing: does the tracking status on screen match reality? Customers forgive a slightly-late parcel far more readily than they forgive a status screen that's been stuck on "out for delivery" for six hours with no update.
Every parcel in Zuma Delivery moves through an explicit state machine — created, picked up, in transit, at hub, out for delivery, delivered, or an exception state with a specific reason — and every state transition is logged with a timestamp and, where relevant, the rider or hub responsible. There's no ambiguous "processing" state that just means "we don't know," because that ambiguity is what erodes trust fastest.
Designing the state machine explicitly, before writing any tracking UI, is the part teams tend to skip. It's tempting to start with the map and the notification copy and work backward into whatever states the database happens to support. Doing it in the other order — states first, defined rigorously enough that "delivered" always means the same specific, provable thing — is what makes the tracking screen trustworthy rather than decorative.