How the tracking page works

The tracking page is the live web page your customer opens to watch a delivery happen — a map, the current status, an ETA, and the driver and proof-of-delivery details, all under your branding. It looks like one page, but it's really two things working together: a single, org-level configuration you set up in the portal, and a per-customer public page that Nash renders from that configuration for each individual delivery. You design the page once; every customer opens their own copy of it. This article is the map of how that split works — what you actually configure, what the customer sees, and how a notification link is what connects your standing setup to one specific delivery.

One thing to hold onto before the detail: Nash dispatches the delivery, and a provider or your own fleet carries it out. The tracking page reports on that delivery to your customer — it shows the driver's location and the delivery's status as Nash surfaces them from whoever is actually delivering. The page reflecting a driver on a map doesn't make Nash the party performing the drive.

Configuration, not a per-delivery page

The most important thing to understand is where the page lives. You don't open a tracking page for a delivery and edit it. You edit one set of preferences for your whole organization — saved as standing configuration, not attached to any single order — and Nash applies that configuration to every customer page it renders from then on. Turn the map off, and the map is off on every customer's page. Change your brand color, and the next pages customers open carry the new color.

That's why the whole surface is a design tool with a live preview rather than a per-order screen. The editor shows you a phone-and-desktop mockup of the page with a phase switcher, so you can see the two moments that matter — before a driver is assigned, and during a live delivery — on both mobile and desktop, exactly as a customer would. What you're previewing is the finished product a customer will open; what you're editing is the configuration behind it.

The editor has two tabs. Delivery is the tracking page itself — branding, components, and the pre-dispatch screen. Feedback is a separate customer-facing form, whose availability varies by organization. Both are described below.

What's on the page, and what you control

The page is built from components you turn on and off, one at a time. Whatever you turn off simply doesn't appear on the customer's page. The components cover the substance of what a customer watches:

• The map and locations — a live map, the pickup and dropoff locations, and the live driver location as Nash surfaces it.
• Timing and status — the dropoff ETA, the current delivery status, and the event timeline of the delivery.
• Delivery details — proof of delivery once captured, driver info, provider info, and package or reference IDs.
• Recipient and org details — the dropoff last name and phone, and your organization's name.
• Convenience controls — a language selector, and feature-flagged extras such as letting the customer edit their address or phone, whose availability varies by organization.

Two of these are worth calling out because they expose customer-identifying information by default: the recipient's last name and phone number, and your org name, tend to show out of the box. It's worth checking what a customer actually sees before you hand the page to anyone. The field-by-field breakdown of every component is in the tracking page components reference, and the how-to for choosing them is in customize your tracking page.

Above the components sit the appearance settings: your logo, a brand color and theme, the page language, and a "Powered by Nash" toggle (which is hidden for white-label organizations, where it doesn't apply). Together with the footer's website and social handles, these are what make the page read as yours rather than as a generic Nash page. The branding how-to is in brand your tracking page.

Some richer capabilities go beyond the standard component list — a Delivery Activity feed and an embedded AI tracking assistant that answers a customer's questions on the page. These are premium extras whose availability varies by organization; they're arranged with Nash rather than switched on yourself, so reach out to Nash if you want them.

The pre-dispatch screen

By default the page comes to life once there's a delivery to show. But there's often a gap between when an order exists and when a driver is actually assigned to it, and a customer who opens their link in that window would otherwise see very little. The pre-dispatch screen fills that gap: an optional early view, with a custom message you write, shown before a driver is assigned. It's the same page, earlier in the timeline — a way to reassure a waiting customer that their order is in hand before there's a driver on the map. The setup is in show tracking before dispatch.

The feedback form

The Feedback tab is a distinct customer-facing surface that rounds out the delivery: a thumbs up/down form, with a title and a set of reason options you define, shown to the customer after the delivery is done. Where the tracking page is about watching a delivery in flight, feedback is about capturing the customer's reaction once it's over. It's its own tab because it's a different moment and a different job, but it lives here because it's part of the same customer-facing page experience. Its availability varies by organization. See collect delivery feedback for the setup.

How a customer reaches the page

A tracking page is public — there's no login. The way a customer gets to their page is through a link, and that link almost always arrives inside a notification. A notification message carries a tracking-link variable ({{job_tracking_link}}); at send time it resolves to that customer's own tracking-page URL, and tapping it opens their page. The link is what turns your one org-level configuration into a page tied to a specific delivery.

This is the seam between two objects, and it's worth keeping straight. Configuring the page — everything in this article — is separate from deciding who gets told about it and when. The messages that carry the link, the events that fire them, and the channels they go out on all live in the Customer notifications object. Build a beautiful page but never send a notification that links to it, and no customer ever finds it. In practice you set up both: the page here, and the notification that delivers its link there.

How this ties to the delivery

Everything the page shows reads off the delivery itself — the same status changes that drive the badge you watch on the Deliveries page. There aren't two timelines. There's one delivery moving through its statuses, and the tracking page reflects that status live: the customer's page updates on its own as the delivery is picked up, goes out for delivery, and completes, without anyone refreshing it or contacting you.

So the page you configure here and the delivery your team runs are the same event seen from two sides. Your side is the Deliveries page and the provider or fleet carrying the work; the customer's side is the tracking page watching it happen. For the lifecycle behind those status changes, see how deliveries work and the delivery status reference.

The tracking page never changes the delivery — it only reports on it. Nash dispatches the work, a provider or your own fleet carries it, and the page shows the driver's location and the delivery's status as Nash observes them. Configuring what the page displays decides what your customer sees; it doesn't make Nash the one performing the delivery.